Shuriken - Particle rendering using additive material affected by realtime shadows

Hi,

I am seeing a strange issue with the default additive particle shader and underlying geometry (2017.3.0p1).
When having a directional light in the scene that casts realtime shadows the particles blend nicely with each other and the underlying geometry - the soft particles factor is at work I guess.

Turning that directional light off or disabling its realtime shadows causes the particles to create visible seams where they overlap with the underlying geometry.

Having the directional light ON, realtime shadows ON and its shadow strength at ZERO causes no such effect.
Using other light sources (point lights for instance) to simulate the correct/wanted behaviour does not yield the desired results. It HAS to be a directional light with realtime shadows enabled.

What's going on here?
The particles are rendered in Forward Linear. Though it also happens on Gamma.
It looks like there is some optimization going on in the background that keeps the soft particles factor from working when no directional light source with realtime shadows is found in the scene.
That's unfortunate for this specific scene (space).

EDIT:
The directional light source also HAS to have an intensity (e.g. as low as 0.001) to get soft particles to work.

 

Ok, slapping a depthTextureMode |= DepthTextureMode.Depth onto the camera seems to get rid of the neccessity to have a directional light in the scene.

So in essence it looks like Unity is optimizing the DepthTexture away when there's no contributing directional light in the scene with realtime shadows enabled. In Forward. Deferred should not suffer from this logic since it always generates a depth texture, no?

 

I believe it also does this optimization if there are no meshes in the scene that can cast or receive shadows. This is happening because

The Soft Particles Quality setting also forces the depth texture to always be rendered, but enabling it on the camera via script is a good option too if you don't want to do that.


There's also no easy way to test to see if the depth texture will exists or not unless you are explicitly enabling it, either from script or in the shader.

You could use the SOFTPARTICLES_ON keyword from #pragma multi_compile_particles, but that is toggled by the graphics settings. You are guaranteed to have a depth texture when it's enabled, but there are of course several cases where it exists when it is disabled, and you may not want it enabled.

In the past I used to test if _CameraDepthTexture_TexelSize.z != 0, but at some point they stopped updating the _TexelSize uniform when a texture fell back to a default. So now if the depth texture has ever existed it remains set to the last value if it is for some reason disabled.

After that I switched to testing the raw depth texture value. If it was == 0.0 it meant it was the default texture as it's impossible for a depth texture to be 0.0 under normal situations. A depth of 0.0 would be clipped and not rendered, so it had to be the default texture or an uninitialized depth texture. Then they added reversed Z and 0.0 was now the proper clear value. That might have been fine still, but then they also updated the default texture to be grey, the exact value of which is basically impossible to test against.

About the only thing left is you can test if _LightColor0.rgb == half3(0.0, 0.0, 0.0) and SHADOWS_SCREEN in a forward base pass, otherwise I've not found any way to test for it in the shader. And that only works on desktop and consoles and assumes someone hasn't disabled screen space shadows.