Unified GSplat rendering artifacts when castShadows differs

[nancywan1004]

Hi there,

When using unified GSplat with multiple placements in the scene, and some have the castShadows = true while others have castShadows = false, the engine appears to create separate forward/shadow GSplat managers, thus leading to the blue and green-ish rendering artifacts (in the photo attached). I wanted to set up the scene this way mainly because I wanted the gsplat assets in the scene to cast shadows but not the main gsplat scene.

Would appreciate any help with this!

[mvaligursky]

I tried to reproduce it, and it works fine in my case, so I would need a repro case here.

I modified this example https://playcanvas.vercel.app/#/gaussian-splatting/simple by adding additional gsplat that does not cast shadow (in addition to the one that does), and all renders as I would expect:

[nancywan1004]

Hi Martin,

Thanks a lot for the fast response and indeed I was also not able to reproduce it in a standalone example. But looks like there's no need for a shadow-apply and shadow-catcher script for this one anymore?

I developed an editor where I could place new objects and support shadows and all that (I referred to a shadow-apply script from one of your examples initially). So after some more investigations, I found out that it only occurred when I tried to place a new gsplat object in the scene while I had the shadow-apply pipeline active. I asked GPT and it told me that it was because gsplat was not in the stable forward render state yet before it got into the shadow-apply pipeline, thus leading to the artifacts. The problem wouldn't happen if I place the object first and then turn on the shadow-apply pipeline.

This is what GPT told me originally:
**_The root cause is a timing issue between Gaussian splat loading / first stable unified render and the shadow pipeline.

When shadow.enabled is already true, a newly placed Gaussian can enter the shadow-related render paths too early, before its unified gsplat state has fully stabilized. That means it may be added to shadow casting / extra render passes while PlayCanvas is still preparing the unified gsplat work buffer, material variants, sorting, or LOD resources.

In this unstable window, the Gaussian can be rendered through shadow or mask cameras before its normal forward render path has settled. That is likely what produces the blue-green corrupted pixels: the unified gsplat renderer is using incomplete or mismatched buffer/material state._**

Right now I have a temp solution myself to suspend the shadow pipeline for a few frames and re-activate it, which is not ideal but could suffice at the moment.

[mvaligursky]

I don't believe we have an 'unstable window' really, it should all work at any time, internally things are delayed as needed (unless bugs of course, it's complex system).
If you have some time, perhaps try to create some minimal repro to showcase this issue for me to investigate, otherwise it's hard to advise what the problem could be.