• Unity

  • Screen-Space Shadows and URP

    英语
Related Discussions
...

Hi! I wanted to try out the URP render feature for Screen-Space Shadows, and see what performance gain I get because my game is entirely large open out-door spaces stretching into the distance, and I'm currently using a set of shadow cascades to manage the performance of that.

For the most part, I think it works as expected, but the shadows overlay my Spine characters:

On the left: you can see the shadow of the monster, and the shadows of the fences behind the monster, clipping onto the monster itself.

On the right: setting the render queue to -2500 moves the character from 'AlphaTest' to 'Geometry'. (I'm writing the character to the depth buffer, with Depth Alpha Cutoff, receiving shadows and fog as well.)

From the docs:

This Renderer Feature uses a depth texture and invokes a depth prepass before it draws opaque objects. It calculates the shadows in screen space before the DrawOpaqueObjects render pass. URP doesn't calculate or apply screen-space shadows for transparent objects; it uses shadow maps for transparent objects instead.

A cursory inspection seems like this render queue modification removes the shadow order artifact, while introducing no other issues. Is there anything I'm missing? Anything I should test and confirm still looks okay?

I'm prepared to go through and change the render queue offset value 100 Spine materials but thought I'd sanity check here first :p

Cranktrain ：

URP doesn't calculate or apply screen-space shadows for transparent objects; it uses shadow maps for transparent objects instead.

Hm, then the behaviour that you've observed is indeed a bit strange, that Unity counts AlphaTest geometry as transparent and excluded from shadows. It would be expected to count AlphaTest as normal opaque geometry here. GeometryLast, which follows after AlphaTest, even has the comment Last render queue that is considered "opaque" listed on the RenderQueue documentation page.

It might potentially have something to do with the render passes contained in the shader, but Universal Render Pipeline/Spine/Sprite actually provides a DepthOnly pass. You could have a quick test whether any other official Unity URP shader (any cutout shader) that by default uses render queue AlphaTest behaves in the same way, not casting and receiving screen space shadows.

If that's not rendering correctly either, then it could be considered a bug that AlphaTest geometry is not counted as opaque here, it could be reported to Unity. On the other hand you might just decide to use a render queue offset of -2500 (or create a copy of the same shader with just the render queue modified), but be sure to use the highest possible render queue value to make sure any alpha-blended (and alpha tested) pixels are blended with opaque geometry behind it (i.e. rendering opaque render queue Geometry objects first). You could theoretically decrease the Render Queue value of any render queue Geometry objects (leave it higher than Background however) if you encounter any ordering problems.

Thanks Harald.

Harald ：

You could have a quick test whether any other official Unity URP shader (any cutout shader) that by default uses render queue AlphaTest behaves in the same way, not casting and receiving screen space shadows.

Hmm, so my test was creating a quad with the standard URP particle shader (ParticleLit.shader), with alpha clipping turned on - that should be a AlphaTest-by-default cutout shader, right?

That big flat circle is the Particle shadered quad, and it looks okay to me, so I'm not sure this is a Unity bug?

Cranktrain ：

Hmm, so my test was creating a quad with the standard URP particle shader (ParticleLit.shader), with alpha clipping turned on - that should be a AlphaTest-by-default cutout shader, right?

Hm, at least when setting up the particles shader with Alpha Clipping enabled I also see Render Queue set to 2450 (AlphaCutout) when switching the Inspector to Debug mode, which would mean it's in the same queue. Could you perhaps send us a minimal Unity project that still shows this issue? You can send it as a zip package to contact@esotericsoftware.com (briefly mentioning this forum thread URL so that we know the context). Then we can have a look at what's going wrong.

Welp, I try to recreate this issue in a little project with Unity 2021.2, SpineBoy example assets and the latest 4.1 runtime available from the download page, and I can't isolate the issue. Then I go back to my game and the issue still lives on there.

My project is still in Spine 4.0, I don't suppose there are any changes between 4 and 4.1 in the URP shader that could lead to this?

Perhaps more likely - are there are any global settings in Unity or in one of the many URP settings assets that could inadvertently have this knock-on effect on the draw order of everything? I've checked everything I can think of and I'm out of ideas.

Wait!

I spoke too soon, I tried one last thing and was able to recreate. I won't bother sending the project file in an email because it's so easy to reproduce, it's all about whether you have the Decal renderer feature added to the list:

What's going on with that?

Cranktrain ：

I won't bother sending the project file in an email because it's so easy to reproduce, it's all about whether you have the Decal renderer feature added to the list:

Please still send the project, it would save us the setup time and prevents any potential differences in package versions, project and scene setup.

What's going on with that?

In general any changes to the render pipeline might effect any render passes and cross-interaction between scene elements. Some render features require more than just a single isolated screenbuffer processing pass.