Description
The topic is as broad and generic as the title suggests. Right now, there is not really support for any extensions on the level of the jgltf-model classes. There is support for some extensions on the level of the ...impl classes, which generally contain the plain old Java structures that are auto-generated from the respective JSON schemas (and the infrastructure for this is already in place). But these extensions can now, at best, be passed through via the untyped extensions in the model classes.
Proper support for extensions on the level of 'model' classes raises a whole bunch of engineering challenges.
The lowest level is in establishing the connection between the 'impl' and 'model' classes. In any cases, this means, very roughly speaking, to replace indices with objects. Instead of
gltf.extensions["KHR_lights_punctual"].lights = /* let there be lights */;
node.extensions["KHR_lights_punctual"].light = 4; // The index
the model classes should allow something like
Light light = new ...;
gltfModel.getExtension(KHR_lights_punctual.class).addLight(light);
nodeModel.getExtension(KHR_lights_punctual.class).setLight(light); // The object
Parts of that are pretty straightforward. But that pseudocode involving KHR_lights_punctual.class already hides the difficult parts: There has to be some sort of "plugin concept" for extensions, so that the model classes can be used when the respective model classes JAR is found on the classpath.
The next level is that of how the extensions affect other parts of the code.
This may includ
563C
e seemingly trivial things. For example, the auto-generated impl classes currently enforce the contraints that are defined in the JSON schema. For example, when trying to do accessor.setByteoffset(-123), then this will throw an IllegalArgumentException. Now... there might be some OBSCURE_accessor_negative_byte_offset extension that allows negative byte offsets. How to handle something like that is all but clear.
Far more tricky is the question of how the presence of extensions affects reading, writing, and processing the model. I assume that adding support for extensions will involve many "breaking changes", insofar that there will very likely be some doSomethingForExtensions(...) methods that have to be added in interfaces or classes, to offer some form of "hooks" or "callbacks" that allow certain forms of pre- and post-processing.
I'll probably start some experiments with the most simple extensions (like KHR_lights_punctual or some of the PBR material extensions that just add some textures or floating point values). But extending the support for extensions will likely be an iterative process that spans over several versions/releases.
All this is still independent of some of the really difficult questions for specific extensions. Good luck with trying to find any support for Draco or MeshOpt in the Java world.
(There is some hope for KTX, at least - via KhronosGroup/KTX-Software#886 . But ... my spare time is limited, and at the end of the month, I have to pay my rent...)