Consider removing support for multiple scenes in a single asset

[donmccurdy]

Although GLTF technically allows multiple scenes, it isn't a common intention, and frankly I've never seen it used that way. In every known case, the file will contain a single scene — or perhaps none at all, e.g. for a material library — and loaders can consider that scene object a "top-level node" for application use.

The fact that glTF allows more than one scene seems to confuse or surprise users, who generally think of "scene formats" and "model formats", and multi-scene formats aren't a meaningful concept. Unless there's a strong need for the feature, I think we could consider disallowing use of multiple scenes in some future version of the spec, and/or discouraging it now.

[lexaknyazev]

Keep in mind that we have IBL extension that is defined on scene.

[stevenvergenz]

For our use case, we treat a scene loaded from a glTF as equivalent to a Unity prefab. So being able to pack multiple variations of a prefab that use the same assets is useful. Admittedly, multi-scene export isn't common, but that might change.

[vpenades]

Actually, my intention was to use multiple scenes support as a cheap way of having LOD levels, where each scene is a LOD

[donmccurdy]

Actually, my intention was to use multiple scenes support as a cheap way of having LOD levels, where each scene is a LOD...

I'd be fully supportive of having an official LOD extension at some point. Microsoft uses one internally, and there's some discussion of bringing that in: #1045.

[zellski]

I’m on the fence about this. It’s worthwhile to reduce complexity, and it’s meaningful to look at what people are actually doing — I agree in the vast majority of cases, the concept of “scenes” is more bewildering than helpful.

And yet the concept of being able to embed distinct scene graph roots in one GLB that can take advantage of glTF’s powerful reference mechanic to minimise duplication is really powerful — especially, as we’ve seen here, in conjunction with other extensions.

Some use cases, like LOD, can almost certainly work better at node or mesh levels. But nodes are extremely general (and already bound up in complexity such as skeletons). A simple extension that is only meaningful at the root is forced to target nodes, because we’ve removed scenes, would need to somewhat awkwardly communicate this constraints in English in the extension specification, and the constraint can’t be expressed in a schema.

Perhaps this is too artificial a concern; maybe no great amount of such use cases will ever materialise. But if we think they will, would we consider simply renaming the field? Scene is semantically confusing when the intended use has nothing to do with scenes.

[lexaknyazev]

But if we think they will, would we consider simply renaming the field? Scene is semantically confusing when the intended use has nothing to do with scenes.

Maybe layers?

[vpenades]

the point is that, multiple scenes allow for different use cases:

• They can represent LODs
• They can represent skin variations (as in, choose your player's color)
• They can represent layers
• they can even represent different context, like having on scene for rendering and another for physics mesh

About complexity, I don't see it adds a lot of complexity, if you want a single scene, you'll always have the scenes collection with just one element, and engines expecting just one scene can rely on the defaultScene.

[snagy]

the point is that, multiple scenes allow for different use cases:

• They can represent LODs
• They can represent skin variations (as in, choose your player's color)
• They can represent layers
• they can even represent different context, like having on scene for rendering and another for physics mesh

About complexity, I don't see it adds a lot of complexity, if you want a single scene, you'll always have the scenes collection with just one element, and engines expecting just one scene can rely on the defaultScene.

The flexibility of what different scenes can represent is exactly why it shouldn't be in the core spec; all of the things listed here should be explicitly described with extensions.

[donmccurdy]

^This is my concern, too. When a scene could mean anything, that makes it hard to have consistent implementations. What if there are no scenes at all, just nodes? (donmccurdy/three-gltf-viewer#132) LODs and variants are features that probably should be in the glTF spec or extensions at some point; in fact I think LODs are pretty important. On (3) and (4) I don't have an opinion but if they are needed, I would prefer to see an extension proposed so that the implementation is fully specified.

On the other hand, there isn't anything to do here in the 2.X lifecycle. I don't mind waiting it out and seeing how things look down the road. If multiple scenes can be used in different ways but aren't causing complexity/inconsistency that might be fine.

[vpenades]

@snagy In terms of compatibility towards displaying a gltf model.... what's the difference between having additional scenes where its meaning is only known by the producer, or having custom extensions that only the producer knows?

To some degree, gltf is designed so if a vendor/developer requires a certaing feature, it can do so with extensions, most probably breaking compatibility with the rest of the world along the way. If a vendor chooses to use additional scenes for whatever purposes sees fit, I don't see why it's different than choosing extensions.

I think the difference here is whether the gltf file is going to be used for interchange, where compatibility is a must, or for internal consumption, where you can do whatever you want with the format.

@donmccurdy I agree with you, LODs are important enough to be part of the main spec.