Can multiple scenes share the same nodes?

[donmccurdy]

Related to #1358, but not fully specified – can two scenes reference the same 'root' nodes? For example:

{
  scenes: [
    {nodes: [0]},
    {nodes: [0]}
  ]
}

We specify that a node cannot be a child of two different nodes, but this case is unclear.

[scurest]

I think its very clear that they can, there's zero language forbidding it. Currently a scene is just a named label or tag that can be attached to certain trees in the forest. They don't participate in parent/child relationships at all. The only things the spec says about their purpose is that they are "the set of visual objects to render", and there's no reason that two sets of things you might want rendered together should be non-overlapping.

[donmccurdy]

I'm hoping the spec can add language either explicitly allowing or forbidding this.

Currently a scene is just a named label or tag that can be attached to certain trees in the forest. They don't participate in parent/child relationships at all.

I agree the spec isn't specific now, but in most tools with a scene graph the concept of the scene is pretty well established as the parent of a subtree of nodes, and nodes typically do not have multiple parents. If glTF scenes are not meant to be interpreted in that way, then how?

For example, Blender or three.js will have to duplicate nodes to preserve their presence in multiple Collections or Scenes. If tagging were the goal I think we'd want a more intentional Layer or Collection system instead.

[lexaknyazev]

I've run into this as well while defining constraints around skinning (and this is why skinning validation isn't ready yet, btw). The latest spec language is:

When a skin is referenced by a node within a scene, the common root must belong to the same scene.

This doesn't clearly say whether the set of scenes the node belongs to must be exactly the same as the set of scenes the common root belongs to. We should be more precise here and agree on one of:

• the sets must be the same;
• the first set can be a subset of the second set, i.e., the common root can optionally belong to a scene that doesn't contain the node with a skinned mesh but not vice-versa.

Also we can further restrict this by saying that the node with a skinned mesh cannot belong to more than one scene.

/cc @bghgary

[rainclaws]

If the answer to this question were to be established as "no", then there is no difference in requirements between these two cases,

• a scene and its nodes
• a node with its children

Which I think is the issue #889 (#1527) in essence.

Since, in such a case, both would have to conform to the same rules. That is, direct graphs, no multiple parents, etc., resulting in two different ways of having children nodes with basically no semantic difference.

This,

    "scenes": [
        {
            "name": "Scene",
            "nodes": [
                0
            ]
        }
    ],
    "nodes": [
        {
            "mesh": 0,
            ...
        }
    ],

Could be,

    "scenes": [
        {
            "name": "Scene"
        }
    ],
    "nodes": [
        {
            "scene": 0,
            "children": [1]
        },
        {
            "mesh": 0,
            ...
        }
    ],

Because then what is the point of having the nodes property in scenes, when so many others use the children property of the node instead?