Clarification needed: why a separate format instead of an extension to glTF?

[hybridherbst]

It's not clear from the docs why a separate file format is a good idea here.

I think it would have been perfectly viable to design a regular glTF extension that allows for composition of assets and addition of interactive behaviours (in fact, we're using vendor-specific extensions that way already). A separate file format seems to overcomplicate this, but would be great to read more about the reasoning for that.

Additionally, this imposes a weird restriction: glXF files can't be self-contained anymore since they can only reference other assets and not contain any buffers etc. Not sure why this would be desired; in most cases for last-mile delivery a self-contained file is a good thing, not a bad thing. It means there always must be multiple requests to even build the simplest of experiences.

[expenses]

Personally, I'm a fan. The problem with trying to do everything via glTF extensions is that it's hard to expect what you're going to get when your engine loads a glTF off the web. Is it loading a single self-contained model or a scene of models? Etc.

Having a separate file format (with a separate extension!) avoids this problem.

It means there always must be multiple requests to even build the simplest of experiences.

I don't personally like the idea of a binary glXF format that embeds binary glTF files within itself, but mostly because it seems messy. I'm not sure what the best solution to reducing request latency here would be.

[jbehr]

We also prefer a extension to gltf and not yet another format

https://github.com/tsturm/glTF/tree/FRAUNHOFER_external_model/extensions/2.0/Vendor/FRAUNHOFER_external_model

[donmccurdy]

I've assumed (but am not in a position to say officially) that the motivation has to do with maintaining a bounded scope for the glTF file format. Various proposals on the table (nested glTF references, behavior graphs, spatial indexes, ...) dramatically increase the complexity involved in a glTF implementation. Additional complex features will likely come later. Critically — it's not obvious to me whether putting those behaviors into a glTF or even glTF-flavored file is likely to succeed at an ecosystem-level, as compared to other equally-plausible approaches. Such approaches include other formats wrapping or building on glTF files: 3D Tiles, USD, or VRM. I suspect it will be harder for glTF to remain useful as a foundation for other formats, if its own boundaries become blurrier. And that's inevitable with the proposals here, these glXF features will absolutely not make sense for some glTF clients.

The model/scene boundary is already a source of challenges, most existing file formats focus on "model" use cases, and the more we venture into scene-ish features like punctual lighting, IBL, and tone mapping, the less prior art there is to base standardization on. The goals of glXF are even more novel, and (IMHO) the chances of getting some of these choices wrong are pretty high. That's OK, but I'm empathetic to the idea of insulating glTF from this more explorative work.