overrideMaterial for nested scenes

[nullEuro]

It is possible to add a scene to another scene. However, setting an overrideMaterial on a nested scene has no effect. Only the overrideMaterial of the root scene is honored (and changes the material of children of nested scenes also as expected).

I expected (and am suggesting now) that it is possible to set an overrideMaterial on any scene, and that it overrides the overrideMaterial of parent scenes. Though that may be debatable. But the documentation in this regard could be improved in either case.

My use case: I have several Sub-Scenes loaded from different GLTF files in my root scene, and want to highlight specific ones under certain conditions with a special material.

Live Demo

[WestLangley]

I do not recall support for sub-scenes ever being considered in that regard...

In any event, a workaround is to use multiple render passes.

https://jsfiddle.net/d2je03mc/

[makc]

@nullEuro would this not have unexpected effects, e g when people just do someObject.add(gltfLoaderResult.scene) and then try to apply effects that set overrideMaterial on the root scene and the entire gltf is still rendered as is because its overrideMaterial is not set?

[WestLangley]

Yeah. Never liked that GLTFLoader adds a THREE.Scene as a child of THREE.Scene.

/ping @donmccurdy

[donmccurdy]

Looking at other properties on Scene objects, nesting them would be problematic... .background, .environment, .fog... I don't think we can support those properties, or .overrideMaterial, on nested scenes.

@nullEuro I believe you'll need to directly change the .material property on meshes you want to effect.

@WestLangley a THREE.Scene is the most obvious representation of a glTF Scene object. It's difficult to say universally whether a glTF file is a scene or is an object added to a scene. The following is valid:

loader.load( 'foo.glb', ( gltf ) => {
  renderer.render( gltf.scenes[0], gltf.cameras[0] );
} );

I don't mind changing the return values as shown below, though.

// before
{
  scenes: Scene[];
} 

// after
{
  scenes: Object3D[];
} 

But I'm not aware that nested scenes have ever been discussed...

[Mugen87]

Looking at other properties on Scene objects, nesting them would be problematic... .background, .environment, .fog... I don't think we can support those properties, or .overrideMaterial, on nested scenes.

Indeed, these properties assume they are only present in a "root" object.

I believe you'll need to directly change the .material property on meshes you want to effect.

That sounds like a proper workaround to me. Object3D.traverse() might help here.

A THREE.Scene is the most obvious representation of a glTF Scene object. It's difficult to say universally whether a glTF file is a scene or is an object added to a scene.

Hence, using THREE.Scene in this context is absolutely fine from my point of view.

But I'm not aware that nested scenes have ever been discussed...

No, not to my knowledge. I'm also not a fan of this idea. It seems more appropriate to me to handle such specific use cases on application layer.

[donmccurdy]

Ok, let's change the return type of GLTFLoader to {scenes: Object3D[], ...}. If we want to do something to more explicitly prevent Scenes from being nested, library-wide, I'll leave that decision to others.

[nullEuro]

Using multiple render passes is an interesting idea, though not really practical for my case.

Traversing the subscene is exactly what I did before I found overrideMaterial and thought it was a great way to simplify my code, later trying to find out why it did not work.

I did not even consider that nesting scenes is not really an intended feature. I think changing the signature of the GLTFLoader result is a good idea and helps to prevent this false assumption, since loading a model and adding it to an existing scene is probably a common use case. I don't have much experience with three.js though.

Anyway thanks for the great discussion.

[WestLangley]

@donmccurdy Can scene be a Group and scenes be a Group[]?

[donmccurdy]

I'd be fine with that too, although use of Group has created its own unplanned side effects (#15561 (comment)). For .renderOrder to be relative to the root Group for that glTF asset doesn't seem too bad...

[WestLangley]

These issues are a but conflated...

I think for the purpose of sorting, .renderOrder should be per renderable object without regard to hierarchy.

I do not think the current sorting algorithm handles sorting groups correctly -- or if it ever will. See #18176.

[donmccurdy]

I'm not sure if you're suggesting we should return Group from GLTFLoader, or that the unintuitive effects mentioned in #18176 mean Object3D would be safer?

[WestLangley]

I was suggesting :

1. GLTFLoader return Group,
2. renderOrder should not consider hierarchy.

[Mugen87]

renderOrder should not consider hierarchy.

I do not vote to revert #15484 since I know projects which successfully use it for sprite rendering. Please study the history of this PR. If this logic is removed, a replacement is necessary. E.g. a new class like SortingGroup.

[WestLangley]

I do not vote to revert #15484

But #15484 does not work correctly. See if you can help @gkjohnson in #18176. If you can figure out how to make it work, that would be great.

Otherwise, I recommend we do what I suggested above:

renderOrder should not consider hierarchy.