Introducing vsgXchange::gltf loader for loading glTF 2.0 databases

[vsg-dev]

I like many others in the graphics sector have been gravitating towards glTF being not only an data exchange format, but one that's good enough to use for real-time data storage. It's never going to be as efficient as native file formats like .vsgb but for many applications it will provide good enough speed and control and avoid the need for creating native file formats for their real-time databases. The 3D Tiles initiative is very much part of this movement to utilize glTF for real-time work.

The importance of glTF has made implementation of a native glTF loader a natural fit for the VulkanSceneGraph project, we've been able to load .gltf and .glb files using assimp's glTF support via our vsgXchange::assimp loader, but this adds an external dependency and looses out on the ability to have a closer mapping between glTF data structures and the scene graph. Extensions to glTF that are awkward to implement in a general purpose loader library like assimp can be much more straightforward when we can parse the extensions and map them to require scene graph/shaders ourselves. As we'll see below even at this early stage the new glTF loader can handle some gltf datasets better than vsgXchange::assimp, thanks to the ability to easily implement glTF extgensions.

Another benefit of going native is we can avoid converting much of the data between intermediate data structures - we can read vertex arrays and texture data directly into VSG objects and assign them to the scene graph. Along with more efficient parsing the new loaders can be significantly faster, especially as the new vsgXchange::gltf can utilize vsg::OperationThreads to load texture images and decode data multi-threaded.

A final crucial element to why it was advantageous to have our own native gltf loader is being able to extend it to work seamlessly as part of a native 3D Tiles loader. More details on this can be found on the Introducing vsgXchange::Tiles3D for loading 3DTiles 1.0 database thread.

The new vsgXchange::gltf loader is able to load most of the official glTF-Sample-Assets data set, and using vsgdynamicload it can even load most of them at once, all multi-threaded:

cd glTF-Sample-Assets/Models
find . -name "*.gltf" | xargs vsgdynamicload

The new gltTF loader already supports KHR_draco_mesh_compression compression, but you'll need draco installed and compile vsgXchange against it to be able to load files with draco compression.

vsgviewer ./WaterBottle/glTF-Draco/WaterBottle.gltf

I have also implemented EXT_mesh_gpu_instancing, something missing from the old vsgXchange::assimp path:

vsgviewer SimpleInstancing/glTF/SimpleInstancing.gltf

The KHR_texture_transform extension is also implemented, again it's not something old loader supported:

vsgviewer TextureTransformTest/glTF/TextureTransformTest.gltf

There are a few other extensions already supported, but there are lots of glTF extensions so it'll be a case of finding models that folks need to load correctly and then implementing these. Support form the community will be really helpful in this.

One thing to be aware of is to support these extensions properly I have update the VSG's built in flat, PBR and Phong ShaderSets to have some new optionally compiled arrays and code, with the naming of some of the arrays changing to fit to keep things coherent. This could mean your own custom shaders might need updating to keep things working.

Not everything is yet complete to the level of the vsgXchange::assimp loader - currently the vsgXchange::gltf loader parsing the glTF animation data structures but doesn't have any code in the vsgXchange::gltf::SceneGraphBuilder to map them across to the appropriate animation classes in the VSG. So for now BrainStem.gltf will load but just stand there looking stupid, no crazy dancing quite yet:

Next week I'll tackle animation, and once that's complete we should be good for going for point releases of the VulkanSceneGraph, vsgXchange and vsgExamples.