Any thoughts on these criticisms from this Wikipedia article? https://en.wikipedia.org/wiki/GlTF#Criticism
(I'm not agreeing or disagreeing with them, I'm genuinely curious to hear from someone working with the format at the implementation level)
(I'm not agreeing or disagreeing with them, I'm genuinely curious to hear from someone working with the format at the implementation level)
You can get 80-90% there but miss quite a bit of fine detail needed as a interchange format (which is why this is a transmission format I guess). Extensions seem to be basic and I question how well they work in 3d editors but not really sure how that works and is probably editor specific. I've had a lot of issues trying to have a single file like collada be properly supported in multiple editors unless it was fairly basic model. That leads to a lot of wasted time for modelers trying to get the edited model back into the game and working correctly.
Back to GITF, collision seems to be missing. They admit that they dont have vertex compression implemented or animation for things like material colors or animation metadata (timelines, looping, ...) . Is there a way to describe a partial surface sort of like skinning for other reasons (for example Fallout 4 needs to tag certain surfaces/vertices as to say that they are part of the head or arm for decapitation in game). Anyway looks like a nice start as its all JSON (or binary) unlike GEX,obj,3ds,... which seems to need its own parsers to read and they did only claim to be an transmission format. Again only did cursory read of the format so I might have missed things.
Scene structure in v2 offers everything Creo View offers and pretty closely matches what is available in the Unity3D hierarchy, from what I've seen. You assign one or more meshes to a node element (rinse and repeat) and you arrange them in parent & child configurations. Transform matrices of parents pass down to children, and so on. If a child node has its own matrix specified, it is multiplied with the computed parent matrix, resulting in the final transform applied to whatever mesh(es) defined in that node. Exactly the same as what Unity or Unreal do.
So the scene structure criticism doesn't hold water for me.
Same for materials. GlTF v2 supports PBR materials with or without texture maps, normal maps, occlusion maps, and emissive maps. All of those are optional and you can set things like color and normals, opacity, and emissivity all without textures if you want.
Most glTF tools out there, including a lot of open source things like blender importers and exporters, assume that there will always be textures to define those material properties, and completely ignore non-texture material parameters like BaseColorFactor, which is incredibly annoying because NONE of the models at my work use textures for anything.
Things like lettering on placards is modeled, not textured, and no UV maps exist for anything. This will be an interesting/infuriating problem when it comes time to view these models in a game engine in a production setting. Optimization in game engines relies on things like textures and UV maps.
To that end I have a to-do item on my list to simply generate small map images for these things and set give each material one pixel on the maps and make all UV coords for a mesh with a given material point to that pixel. That will probably work, and it will probably appease the half-implemented open source stuff I've come across. Runtime lightmaps will not work this way, however.
I can't speak to the animation features of glTF, since I'm dealing with CAD data. Our models are individual parts assembled into whole assemblies or vehicles at runtime, and not stored as whole models.
I think for lettering and similar things (high-complexity but essentially flat) you're right. You could probably use quads here to give you easy UV mapping and script the creation of textures.
What else have you modelled which would ideally be done via textures in a real-time engine?
A full fidelity CAD model for something like a bolt can easily be two million polygons if the draftsman isn't careful.