Announcing JSON parsing, native glTF loader and 3D Tiles 1.0 loaders

[vsg-dev]

Over the past 2 months I have been busy writing native VSG code for parsing JSON files, then implementing a glTF 2.0 and finally native 3D Tiles 1.0 loaders. Where it's made sense I've done this work without depending upon 3rd party libraries, writing the required C++ code myself, with aim of keeping dependencies for these key features like these to a minimum. All the functionality is now merged with VulkanSceneGraph, vsgXchange and vsgExamples master and will be rolled in respective point releases next week.

I have created three Discussion threads for folks to get more information & discuss the individual topics in more details, these threads will start of pretty minimal but I'll flesh them out more today and coming week, and I'm sure they'll also be place that other folks will chip in. The threads are:

• Introducing vsg::JSONParser for parsing JSON files
• Introducing vsgXchange::gltf loader for loading glTF 2.0 databases
• Introducing vsgXchange::Tiles3D for loading 3DTiles 1.0 databases

There are very capable third party libraries for doing JSON parsing, glTF loading and 3D Tiles, and for now the new native implementations will be less capable, so why undertake all this work to provide native implementations?

1. Minimize the 3rd party dependencies required widely used features, lower the barrier to entry and maintenance burden.
2. Keep the code base that users will be exposed to to a minimum, keeping the naming conventions, coding styles, class hierarchy all in one coherent body of code rather than disparate 3rd party projects that all have their own conventions.
3. Keep the code base to a minimum that users might have to dive into when debugging, optimizing performance or doing security hardening of their software.
4. Load data as close to the form used in the scene graph as possible, lowering CPU and memory overheads.
5. Implement extensions we require that aren't supported by 3rd party libraries.
6. Implement the loaders efficiently - skills honed writing efficient scene graph code is also useful when writing efficient parsers/loaders.
7. Simpler and more coherent scene graph integration, no more complicated set up and application exit code as native scene graph functionality is used for loading and paging.

Avoiding large 3rd party dependencies isn't a small impact, the binary size of vsgCs's worldviewer is twice the size of vsgviewer. Adding cesium-native to your application dependencies pulls in a number of large dependencies, together much code in them as the whole of the VSG, vsgXchange and their 3rd party dependencies. All that code is potential security target as well as consuming more memory and CPU cache.

Short term there will be places where 3rd party libraries like cesium-native/vsgCs have more features that you need, for instance 3DTiles 1.1 support, so it might be that you won't be able to just use the new vsgXchange::Tiles3D loader until 1.1 is supported or there are 1.0 extension that you rely upon that are implemented. Same applies to glTF, there is still a few areas when the new loader lags the original loader.

I'll go into various feature development, what's implemented, what's left to do, in the topic specific discussion threads, so please reply to these if there are items of interest to you.

This development work has been made possible by client funding which I greatly appreciate. This functionality isn't going to stop at this point even if this phase of funded work is complete, but there are limits on what I can do just for free as I have to pay for the roof over my head. If there are areas that haven't been tackled so far and you'd really like to see them happen then please consider funding this further development - just email me to explore possibilities, or rolling your sleeves up yourself and contributing in coding kind.

I look forward to seeing how all these lovely new functionality will unfold over the coming weeks, months and years. See you on the individual threads for follow up :-)