Feedback/Suggestion: the exclusion of mesh data in ozz tooling makes the library less confortable to use

[Gaspard--]

Hello, I've been starting to integrate this library to a small game project, and everything went astonishly well (clean cmake, clear classes and documentation) until I hit a snag with vertex data. While I don't think it will be hard to circumvent, I still wanted to point out how the exclusion of ozz tooling to handle mesh data in the main library makes it less confortable to use.

In the documentation there's this part that seems to point towrads OZZ replacing your model files:

ozz-animation provides full support for major Digital Content Creation formats, including glTF, Fbx, Collada… Those formats are heavily used by the animation industry and supported by all major DCC tools (Maya, Max, MotionBuilder, Blender…). ozz-animation offline pipeline aims to convert from these DCC offline formats (or any proprietary format) to ozz internal runtime optimized format, as illustrated below:

Followed by an image seemingly illustrating the idea that OZZ will insert itself between your code and the original animation files.

However, from what I've read and understood, there's no "ozz mesh" format in the library and it's on purpose, as it's considered out of scope for this library.
I completly understand that keeping the scope of the library small enough raises the quality a lot (and the quality is pretty high so far), but this makes integrating ozz into a project less smooth.

If you already have an animation pipeline, and load let's say .gltfs, and you integrate OZZ, and want to get rid of the original animation files, you'll bump your head with the fact that you can't replace the mesh data.

There are 2 solutions to this problem:

• keep the .gltf, and have gltf code that should not exist in your codebase, plus duplicated data between the .gltf and .ozz files
• add your own tool to do the conversion, which means you'll have gltf code that should not exist in your tooling

In both cases you're also indirectly choosing to depend on the gltf format, making switching formats harder, breaking the idea of being format agnostic.
I think this could be avoided by maybe using assimp or something similar, so this second point is maybe not that big a deal.

Back to the main point: the exclusion of a mesh format creates a gap which is solved in the sample code by providing additional types and tooling.
I feel like it would make sens to move this into the main library, ommiting anything that isn't necessary to handle the creation and loading of these .ozz files.

Have an excellent day!