gltf 2.0 extension for referencing other gltf files

[pixeljetstream]

Hi,
excuse me if this been discussed before. But what do you think about the possibility to let a node reference another gltf file + specify the scene/root node from that file to be used to extend the hierarchy?

[javagl]

As far as I know, there is currently no "off-the-shelf"-solution for that. Considering that this was first addressed in #37 (and when looking at all the issues that are linked - including this one now ;-)) there certainly is a demand for that....

[donmccurdy]

I have to admit I'm nervous about the complexity that comes with glTF→glTF references. There are other formats — like OGC 3D Tiles — that have had good success by creating a "wrapper" format, and using references to glTF data as a primitive building block within that.

That particular solution is meant for geospatial applications, but similar things could be done in other domains. So I think (1) this 'wrapper around glTF' approach would cover many of the same use cases as glTF→glTF references, and (2) adding references directly to glTF might make it too complex to be used as a building block in that way.

tl;dr, just my opinion, but I would encourage users/developers to experiment with creating a simple container (JSON?) for your glTF files, or using custom extensions for this purpose.

[pixeljetstream]

good points, the more I think about it, the more likely it is that any "engine" type of scenario where such scene representations with multiple files are beneficial, would always have some custom flavor anyway.
it's not that hard to roll your own, and use existing loaders, but like you said and as it was also mentioned in the other issue, putting it in the spec is a lot harder.

[javagl]

The approach of creating a "wrapper" format (like 3DTiles) certainly reduces the complexity in view of the specification.

(Either as a philosophical side note or a truism: One of the most important goals when dealing with IT systems is abstraction, meaning that at some level, it must be possible to cluelessly use something, without being concerned about its inner workings)

And I agree that it's important that each glTF is self-contained. (Sure, the JSON may refer to .PNG, but the most common way of distributing glTF is in fact as one, self-contained GLB).

But on the level of the specification, this raises questions. What about mutual references? Can one glTF refer to elements of the other glTF? What when they use different extensions? What about redundancies or things that are mutually exclusive? (Think of two environment cube maps being present...).

To put it that way: We're already running into trouble by just allowing multiple scenes in one glTF asset (see #1542 ). Combining multiple glTFs could open a far larger can of worms, and it could create a huge burden for implementors if they were required to manage the "scene graph" of multiple glTFs that way...

On the other hand, there certainly are many obvious use-cases for glTF-to-glTF-references, like an online 3D product configurator or so. The idea of glTF as a transmission format could certainly benefit from the possibility to transfer relevant parts of an asset in a more fine-grained manner. But the question about the granularity (and as a special instance of that: whether this should be part of glTF or built on top of glTF) is certainly not easy to answer.