Shadow bleed-through

[FunFetched]

http://playground.babylonjs.com/indexstable#XUS5AG#1

In the example above, the sphere is located directly above the torus. As you can see, the shadow that it casts bleeds through the top of the torus and on to the lower portion. Is there any way to prevent this behavior? I have a game where the maps are generated as a single SPS that receives shadows, but objects on upper floors cast shadows that bleed through onto any part of the mesh that's under them, such as lower floors.

In my attempts to get around this, I created a custom shader that fades the shadow according to the difference between the shadow map depth and the depth of the caster. While it "works" on the shadow from the object on the floor above (sans the aliasing), you can see where it cuts in to the shadow at the bottom of the attached image. The shadow at the bottom is being cast by an object on a lower level, one that's further from the shadow's light source.

[GameMonetize]

What do you mean by bleed? The result seems correct to me (as the torus is not casting shadows)

[FunFetched]

2 minutes ago, Deltakosh said:

What do you mean by bleed? The result seems correct to me (as the torus is not casting shadows)

It's "correct" in that it's behaving as expected. Since the sphere is between the light source and the torus, any part of the torus that can't "see" the light is indeed in shadow.

However, the lower part of the torus can't "see" the sphere, either, so technically, it's not the sphere that should be shadowing the lower part of the torus. The torus would instead be shadowing itself, at least if I had self-shadowing activated. Obviously, it's not a bug, just a behavioral issue that just so happens to be interfering with a special circumstance of my own creation.

Check out the image below to see what I mean. Notice the ammo crate at the top, and the shadow it casts on the surface immediately below it. At the bottom of the screen, you can see that the same shadow is also visible on the floor below. This is because my map is a single mesh (an SPS).

I have a work-around in place now that isn't perfect, but it's "good enough for who it's for". I'm fading the shadow in my custom shader according to the difference in depth between the shadow buffer and the fragment depth, so the shadow at the bottom "disappears". Of course, it's not actually gone, as you can see in the image in my previous post. I'm getting around that now by placing the light right above the player, so the shadow generator will ignore any meshes that are above it.

There are some special cases where it still doesn't work quite right. For example, if there were an ammo crate directly below in the following image, the "faded shadow" from the crate above would actually blot out the shadow from the crate below. I initially thought I could fix this by changing the depth buffer calculation for the shadow map to GL_GREATER, so that only the objects furthest from the light would be considered. However, I ended up with no shadow at all, and couldn't figure out how to make it work, so I eventually settled for what I have right now.

 

[GameMonetize]

Hey! in this case the best option is to make the ground (or the torus in your PG) as shadow caster, but then you will deal with self-shadowing issues

[FunFetched]

Let me illustrate what I'm talking about.

Does that help? Now, to fix the behavior that is illustrated in the far-right pane, I was thinking that I could change the depth calculation to GL_GREATER, so that the sphere at the bottom (and thus, farthest from the light), would get the last say as to the shadow buffer depth values at that location, but instead, I got no shadows at all. I tried futzing with a number of things, but couldn't figure out how to make it work.

[FunFetched]

Just now, Deltakosh said:

Hey! in this case the best option is to make the ground (or the torus in your PG) as shadow caster, but then you will deal with self-shadowing issues

Well yeah, that's just it.  I tried that, and got some pretty wonky results, though I haven't spent much time trying to fix them yet. Plus, I then have the issue of what to do with shadows disappearing at a distance. I can fade them gracefully, and that might be okay. I'll tinker with it some more. Ideally, I was hoping to save some cycles and leave the map out of the shadow-casting calculations and just "bake" some shading in there at some point.

[FunFetched]

Anyway, thanks for your input! I just wanted to make sure I wasn't missing something obvious.

[GameMonetize]

You were not:)

 

One trick that may be worth the try: did you play with light.range to limit the range of the light it self? (hence limiting the range of the shadow)

[FunFetched]

1 minute ago, Deltakosh said:

You were not:)

 

One trick that may be worth the try: did you play with light.range to limit the range of the light it self? (hence limiting the range of the shadow)

Yeah, that's the "solution" I'm rolling with right now. If my player is on the first floor, for instance, the light follows him just above his head, below the second floor, so the object on the floor above doesn't get taken into account during shadow calculations. There are still some issues when you're looking at both floors at the same time from an elevated position at a distance, but it's not a big deal.

[Wingnut]

Hi guys.  Just for fun, I want to remind about .included*/.excluded* properties on the shadowGen's (or any other...) light.  At times, mesh.material.emissiveColor can cover the lighting (in case that mesh has been pushed into light.excludedMeshes).  .emissveColor can't cast shadows, though.  Ok, impertinent Wingnut... out.    (I'm a bit curious as-to what causes the bright circle, pointed-to by the red arrow)