glTF 2.0 importer

[AlexanderDzhoganov]

This is a follow-up to #67. Previous discussion can be found there.

This PR implements a mostly spec compliant importer from glTF 2.0 to Ozz. It subclasses OzzImporter and can be used in the same way as the FBX one. It depends on tinygltf for parsing.

Changes since last time:

• Rebased on top of develop branch.
• Added ozz_build_gltf CMake option. It requires ozz_build_cpp11 to be ON.
• Cubic spline channels are sampled with respect to the sampling rate passed in the configuration.
• Step interpolated channels are supported.
• Proper handling of scenes with more than one skeleton root.
• Handle scenes with duplicate or empty joint names.
• Added several sample glTF models in media/gltf to test out different parts of the importer (e.g. cubic spline interpolation).
• Less liberal usage of auto for basic types.
• C++ header files placed in include/.
• Various small fixes and improvements.

[AlexanderDzhoganov]

This is a reply to #67 (comment).

By the way, does gltf have different node types?

In glTF each skin lists the nodes it considers its joints. The skeleton is only implicitly specified. The nodes themselves only represent transforms.

I'm wondering what's happening if buffers component types are not floats, like when reading translation, rotation or scales from buffers? Is tinygltf handling the conversion, or is this needed from the importer?

Yes, tinygltf handles the data type conversions.

Please use log::Err only for errors that can't be recovered, usualy when, function return false. "Warnings" should rather be Log or LogV I think.

Should be fixed now.

You choosed to us tinygltf. It needs c++11 so something needs to be done to activate c++11 or disable gltf importer when c++11 isn't supported. Please look at fbx importer on develop branch for an example.
CI dashboards are failing on windows and linux. I think c++11 support is the first issue, but there seems to be issues with cmake script also.

I will look into the cmake scripts and the CI build next.

You choose tinygltf, which seems easy to use. What's the motivation for choosing it? Have you considered other options?

I haven't really considered other options. It seems very well maintained and is used by several high profile projects.

Do you know if gltf supports user channels? It's like an animation channel on a node, that isn't specifically a transformation.

As of glTF 2.0 only translation, rotation and scale are supported.

Let me know if you have more feedback, I'll try to finish whatever is left to do quickly so we can get this merged.

[guillaumeblanc]

Thanks Alexander for the hard work and all the answers. I didn't managed to look at the code yet but you answered most of the questions. I'll need more time to be able to get into the code, I'll get back to you then.

Some next steps I can think of:

• Run some cmake tests case that uses gltf2ozz like done for fbx2ozz: https://github.com/guillaumeblanc/ozz-animation/blob/master/test/animation/offline/fbx/CMakeLists.txt and https://github.com/guillaumeblanc/ozz-animation/blob/master/test/animation/offline/fbx/CMakeLists.txt#L111
• Do you have the need to import gltf meshes? Have you considered implementing a gltf2mesh tool, à la fbx2mesh? fbx2mesh is not ready to be overloaded, but that's something I could prepare.

One last thing: Are the gltf data you added compatible with MIT license? Can they be redistributed?

Thanks again,
Guillaume

[AlexanderDzhoganov]

I'll need more time to be able to get into the code, I'll get back to you then.

No hurry. I might do some more improvements in the meantime.

• Run some cmake tests case that uses gltf2ozz like done for fbx2ozz: https://github.com/guillaumeblanc/ozz-animation/blob/master/test/animation/offline/fbx/CMakeLists.txt and https://github.com/guillaumeblanc/ozz-animation/blob/master/test/animation/offline/fbx/CMakeLists.txt#L111

Sounds good, I'll look into that soon.

• Do you have the need to import gltf meshes? Have you considered implementing a gltf2mesh tool, à la fbx2mesh? fbx2mesh is not ready to be overloaded, but that's something I could prepare.

glTF meshes are trivial to import as they are basically OpenGL vertex and index buffers, I'm not sure if there's a need for such functionality in Ozz.

One last thing: Are the gltf data you added compatible with MIT license? Can they be redistributed?

The models are my own, I release them into the public domain.

Thanks for the quick response, I look forward to more feedback on the code.

[guillaumeblanc]

Sorry it's taking me a long time to get the next release out. But this is not forgotten no worries!

Have you checked this resources: https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0 ? I thought that could be great to use some for unit testing. What do you think?

Talk soon, Guillaume

[guillaumeblanc]

Hi Alexander,

I created a gltf branch and integrated your PR. Thanks again for the hard work.

Here's a list of some of the changes I made:

• Move tiny_gltf and json headers to source directory (instead of include), as they are not part off ozz public sdk.
• Do a clang format and coding style pass.
• Fixes warning. They weren't appearing on the CI because build was disable due to "if ozz_build_cpp11". It allowed me to rethink ozz c++11 management overall.
• Improved constness
  -...

At the moment the skeleton to import is taken from the root of the skin. I'm wondering if there's a way to import skeleton without skins, like ozz fbx importer is working (using node types). This allows to animate anything (like http://guillaumeblanc.github.io/ozz-animation/samples/baked/), share a skeleton for many skins, ... This is quite usual in production afaik.

The next important step is to add unit tests, for all failing and succeeding cases. I'd recommend to use resources from https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0 to have a good gltf spec coverage.

Any progress or new thing on your side?

Cheers,
Guillaume

[pgruenbacher]

commenting because this would be super useful as well.

[guillaumeblanc]

Hi,

any feedback about gltf branch status ? It loads your gltf asset according to my tests, and has fixes for a few issues with node naming and spline sampling for example.

Can you see a way to implement node filtering, as needed for skeleton import ?

Looking forward to hearing from you.

Guillaume

[pgruenbacher]

my fork has some commits in it that fix some issues I had with the gltf branch. https://github.com/pgruenbacher/ozz-animation/commits/master
those fixes were probably meant to handle gltf samples with specific conditions.
but otherwise works great.

[pgruenbacher]

@guillaumeblanc I also noticed that gltf2ozz pads the joints with no animation channel with bind pose transforms... which is fine... but it makes me wonder if it's a flaw that ozz animation file format doesn't allow for empty joint tracks. Likewise wouldn't it make sense for empty joint tracks to allow for automatic partial blending. I.e. if I export upper body animation and lower body animation and then run a blend job with the two, i'd expect them to animate properly without having to manually set the joint weights explicitly... however currently the animations blend improperly e.g. lower body animation only animates partially since its blending the lower joints with the bind pose transforms of the upper body animation.

[pgruenbacher]

i.e. I'd have expected to export only affected tracks, and then the sampler job would have a bind pose option when sampling the tracks to write out the bind pose for joints with no assigned tracks. Or maybe just write out the bind pose to the local transforms as default before sampling.

[guillaumeblanc]

Hi @pgruenbacher

• it makes me wonder if it's a flaw that ozz animation file format doesn't allow for empty joint tracks

Empty animation tracks are actually considered as default tracks during sampling: zero for translation, identity quaternion for rotations, one for scales. If the skeleton was provided to the sampling job, it could get bind pose from there indeed (#78).
One flaw with current gltf importer related to your question is that all gltf nodes of the skeleton hierarchy are considered as joints. fbx importer filters which node is considered a joint, allowing to skip irrelevant joints. It misses from gltf importer, as from my understanding nore aren't type, so I don't know how to filter them. Any idea?

• Likewise wouldn't it make sense for empty joint tracks to allow for automatic partial blending.

I'm sure you saw partial blending sample, which allows to do what you're describing.
That being said, I agree importer tool could be extended to strip some tracks/joints that you would never use if animation is partially used (#79).

Thanks for the feeback.
Cheers,
Guillaume

[guillaumeblanc]

Hi @AlexanderDzhoganov, any feedback about current branch status and remaning questions? Did you managed to try it?

Cheers,
Guillaume

[guillaumeblanc]

I'm planning to bring that branch to develop.
Big thanks to @AlexanderDzhoganov for the PR!

Guillaume