koobas.hobune.stream
Shadows being received by non-shadow collectors that are depth culled by a shadow collector.
Hey all,
we've been having a bit of a problem with shadows and I've been wondering if anyone has had anything like this happen before. I have also started a thread about this on the forum, with more screenshots and a test project but there have been no replies, maybe there is a slightly different audience here!
Let's assume you have a project with:
A ground plane that z-writes but that does not accept shadows at Geometry-1 (actually several flat geometries in the game itself).
A global shadow collector plane that does not z-write and accepts shadows at Geometry+1, just above the ground. This uses a stripped down surface shader with a custom lighting function that does nothing but add the shadow.
Several opaque objects above and below the ground, all of which z-write, some of which are shadow casters and none of which are shadow receivers. The underground objects can be pulled through the ground and cannot be occlusion culled by the ground due to reasons beyond the scope of this bug.
When the objects are under the shadow collector plane, they always seem to be receiving and rendering shadows, regardless of whether "Receive Shadows" is enabled on their renderer and whether the objects themselves are actually z-tested away.
These objects also end up self-shadowing. If the shadow collector shader's addshadow surface pragma is removed, the shadow plane does not render shadows but the objects do. If the objects are not under the shadow collector plane, these odd shadows do not appear.
Here is a project that reproduces this problem:
Even more oddly, altering anything in the project, such as saving the scene, recompiling any shader or changing the drawing order of any object in the debug inspector can toggle this. If the problem does not appear, pressing control-s a few times makes it appear again and vice-versa.
This has been happening all the way through 4.3 to 4.5.
I shall test in 4.2, as I honestly can't remember whether I developed this bit before or after the 4.3 release.
I can now verify that this has been the case since at least 4.2.1f4. through all 4.3 releases and 4.5.
I have submitted this as bug 611333. I haven't had a response yet but I am wondering if anyone else has seen anything like it before.
Edit: I replaced the first screenshot attachment with the test project. The remaining screenshot shows the problem pretty clearly and the rest of the screenshots are still on the forum thread anyway.
Edit: I can confirm that this still happens on 4.5.2.
Hi AlkisFortuneFish
Just fyi by "shadow collector" I think you mean "shadow receiver"
You strike me as a seasoned, intelligent game developer. If you're new to Unity, shadows and lighting are a mess. Depending on the rendering mode, DirectX target, quality level, and emulation target, just about everything can change for no reason. Even the shader variables themselves can change.
About your bug. It looks like what you're seeing is the actual shadow collector, which is a screen-space texture that stores shadow values. This is a class of bug that I'm dealing with right now. With this bug you get X-RAY looking shadows. It may look like you have shadows underground (your screenshot).
What's actually happening is that objects are not contributing to the shadow collector but sampling from it later. This is actually exactly how you set up decal rendering, but that's not what Unity is doing. Unity is just buggy.
Here's a screenshot of my own. If a pixel shader 3.0 shader falls back to a pixel shader 2.0 shader then it stops casting shadows, stops contributing to the shadow collector (seems to be gone from the pre-pass entirely) but Unity still thinks it can sample shadows later so it taps the shadow collector and thus lifts all the shadows "behind it".
TL;DR: Unity shadow code is buggy, run if you can. Or keep banging away at random stuff like setting a different fallback shader, this solves a lot of Unity nonsense.
Hi psontaki,
I somehow missed the notification for your answer. This seems to be the case indeed. I have more information about all the tests I did and the incredibly odd results over in a forum thread. Unity has now confirmed this as a bug, I will update the question to reflect that.
About running away, yeah... Pretty much had to in the end. Since the nature of our game allows for it, we ended up using projected shadows ins$$anonymous$$d, which work on unsupported hardware and batch a lot more predictably as well.
Glad it worked out! Clever idea projected shadows, fast and portable
