An easier way to create glTF models from code

[azrogers]

With the GltfModifier added to Cesium Native, there's more reason than ever for someone to have a need to manipulate glTFs, not just read from them, using this library. Currently, creating or modifying a glTF using Cesium Native means manually creating all the buffers, buffer views, accessors, meshes, mesh primitives, etc., etc.. We can probably provide a simpler API to make this process more convenient.

One idea is some sort of ModelBuilder class. Something like this:

ModelBuilder builder;

ModelMeshBuilder meshBuilder = builder.createMesh();

ModelMeshPrimitiveBuilder primitiveBuilder = meshBuilder.createPrimitive();
primitiveBuilder.setIndices(indicesArr);
primitiveBuilder.addAttribute("POSITION", positionArr);

Model model = builder.finalize();

But there are a lot of other ways to design this, and there are plenty of other utility functions we could come up with that would be helpful for this task.

[javagl]

Creating models (from scratch) is one thing. There are some elements that may warrant their own ...Builder class. One is the mesh primitives (and the ModelMeshPrimitiveBuilder already suggested that). Another one is the materials. Animations could be another one. For the connecting structures (meshes, nodes), a few convenience functions could do the trick. Eventually, the most important part of what such builders are doing is indeed in the finalize function, where the buffers, buffer views, and accessors are created.
(I've been playing with such builders as well - example).

But... creating models is only half the rent. People will want to use such a library to also modify existing models. And that's a whole other story. Libraries like glTF-Transform therefore did not use a "builder-based" approach. Instead, the library offers a "Document" (aka "Model") that can be modified arbitrarily, and then magically written out in a valid, consistent form. This does impose some challenges. The most important one is the validity checks that have to happen internally. Imagine you have some complex model that happens to include some animation, and someone does
model.removeAccessor(theTimeAccessorOfOneAnimation);
This will require some internal magic to remove the respective animation, which in turn causes its 'values' accessors to be unused, meaning that they should also be removed (or there should a method to remove them, like prune() in glTF-Transform). And of course, this means that all buffers and buffer views have to be regenerated.

There are also quite a few degrees of freedom for the buffer/bufferView/accessor layout. In JglTF, there currently is an internal(!) class with flags like

        boolean bufferPerMeshPrimitive = false;
        boolean bufferPerMesh = false;
        boolean bufferForMeshes = false;
        boolean bufferPerAnimation = false;
        boolean bufferForAnimations = false;
        boolean bufferPerSkin = false;
        boolean bufferForSkins = false;
        boolean imagesInBufferViews = false;
        boolean bufferPerImage = false;
        boolean bufferForImages = false;
        boolean bufferForAdditionalAccessors = false;

This is not exposed on the API side, but shows some of the options here. This does not even touch the topic of interleaved-vs-non-interleaved buffers, or the fact that a GLB will usually only have one buffer.

Once such builder classes and modifiable structures exist, there are some neat things that can be done. For example, I have a (not yet published) project called jgltf-jgltfifier (inspired by BCELifier). It takes a glTF, and generates the code that generates this glTF. (I did that a while ago as gltfTransformifier, but that was only a proof-of-concept (no comments, no modules, no structures...)).