Object sorting ignores Scene.overrideMaterial

[gergely-ferenczy]

Description

I noticed that the algorithm that sorts objects before each render seems to ignore Scene.overrideMaterial, so even though the overrideMaterial is transparent, objects that have opaque original materials still get in the opaque render list.

I created a small CodeSandbox to illustrate: https://codesandbox.io/p/sandbox/transparent-override-material-xltngw

As you can see, if only overrideMaterial is set to transparent, the cubes are rendered transparent, but they still occlude each other, because they are ordered front to back. To me, this behaviour is really counter-intuitive, but as it turns out, this can be desirable for example for shadow mapping and probably for other applications too. I think however, that the current documentation is misleading, or not at least not complete.

Solution

Introduce a new Scene.overwriteMaterialTransparency property that would make the renderer use the transparency property of the overrideMaterial instead of the original.

Update the documentation with the new flag and also describe the current default behaviour in a bit more detail.

Alternatives

I can't really come up with any other practical solutions, but I am very much open to any idea that would solve this.

Additional context

I’m wokring on a post processing effect that needs to render the scene with a custom material to work. I thought Scene.overrideMaterial would be perfect for this. The issue is, this custom material needs to be transparent for the effect to work properly. With the current behaviour of overrideMaterial, I cannot use it for what I need, because opaque objects will still be sorted separately and in the wrong order, so I would have to traverse the scene and replace the materials of every object during my custom pass, and I would really like to avoid that.

[Mugen87]

Um, this is in some sense a general issue. When render objects are pushed into the render list, properties from an override material are completely ignored. Scene.overrideMaterial is evaluated after that when the render lists are actually going to be rendered.

Now I wonder if this should be different. I understand the intended behavior is use case specific so a property could indeed make sense.

You could potentially workaround this by managing override materials on app level but that seems to be a tedious setup.

[biru-codeastromer]

Hey, I was thinking how would it be if we handled this directly inside WebGLRenderLists.js, with a scene-level flag like scene.overrideMaterialTransparency, similar to your approach here?

That way, the transparency logic would live exactly where the render list categorization happens (push() / unshift()), instead of in WebGLRenderer.js. It would also make it easier to keep consistent behavior for opaque, transmissive, and transparent lists, while keeping the change opt-in through a scene property.

We could then just pass the scene reference when pushing items to the render list, check if scene.overrideMaterialTransparency is enabled, and switch to the override material’s transparency when sorting.

It feels a bit cleaner and aligns with how other scene-level flags are handled (fog, background, etc.), while still maintaining backward compatibility. What do you think of this direction?