Overview
The tool was built in Visual Studio using C++, JSON, and Google Protocol Buffers. It also incorporates lightweight tinyglTF and tinyXML libraries to read in resources.
Highlights
Command-line Interface
• Use interface to provide resources to convert
(models, fonts, or textures)
• Or run a bash script to convert resources in a batch
• Use interface to provide resources to convert
(models, fonts, or textures)
• Or run a bash script to convert resources in a batch
Accepted Resources
• Models: glTF files (.gltf or .glb)
• Textures: TGA, PNG, JPEG, BMP, and GIFs
• Fonts: XML files and corresponding image file
• Models: glTF files (.gltf or .glb)
• Textures: TGA, PNG, JPEG, BMP, and GIFs
• Fonts: XML files and corresponding image file
Exports Runtime Format
• All resources pass through tool first, guaranteeing to be
Engine readable
• Discards miscellaneous data not needed by Engine for
rendering
• Exported file is serialized using Google Protocol Buffers
• All resources pass through tool first, guaranteeing to be
Engine readable
• Discards miscellaneous data not needed by Engine for
rendering
• Exported file is serialized using Google Protocol Buffers
Post-Mortem
The glTF file format was designed with OpenGL in mind, so the data loosely corresponds to how data is stored in OpenGL. It made glTF files easier to parse for the game engine. The tricky part about glTF files is how the JSON data was nested and mapped out. It would be interesting to expand the tool to parse additional file formats such as FBX.
If I were to further develop the tool, I would add data quantization for exported animations; and add simple track compression as an option. Game animations tend to be a series of rotations with minimal translation, and they are rarely scaled. There is a lot of redundant translation and scaling data that could be dropped. If the original track further reduced 128-bit quaternions to 64 or 48-bits, the compression rate would already be roughly 30 - 40%.
Track compression is more tricky to set up as it involves concepts like sampling and curve fitting. But from my understanding, I can create a curve for each track (rotation, translation, or scale). Then depending how close certain frames are in the curve, they can be dropped, as they can be mathematically inferred. I skew towards having track compression as an option because it seems rather destructive to the animation quality.