Light passing through mesh at seams

Hallur90 · Mar 8, 2019

I bought these cliff sides off the asset store.
It seems that light passes through the mesh at the seams or sharp angles.

I adjusted the Normal bias in the shadow settings of the directional light and they disappear. That introduces some other artifact elsewhere though.

Before I contact the seller I just want to ask if there are some light settings I should be looking into.

Edit: Might have posted this in the wrong subforum, sorry.

Jason210 · Mar 8, 2019

I have this problem a lot, and it doesn't seem to have anything to do with the geometry of the model. The only way I can fix it is to set resolution to "Very High Resolution" for the directional light, and then set bias and normal bias to zero.

Hallur90 · Mar 8, 2019

Thanks for the response Jason.
Have you tried any hacky methods like putting geometry inside of the models?

Jason210 · Mar 9, 2019

Not yet . Actually I would strongly recommend that you avoid that.

It seems to be the edge of the shadow map that causes it, so fixing the quality and shadow map fixes it. I just found another way to prevent it. Edit > Project Settings > Quality > Ultra. And if you want even more, you can edit Ultra by altering some of the shadow parameters. For example, if you set "Shadow Projection" to "Close Fit", the problem disappears and you can keep your lower quality settings.

I'm not experience with lighting so I'm not sure which is the best way to approach this or what performance implications any of these settings will have later.

Hallur90 · Mar 9, 2019

Thanks again, I tried your advice just now and the gaps do appear smaller but they are not gone completely.
Only way to make them fully go away is the normal bias. Problem is it makes my surrounding terrain look weird

Jason210 · Mar 9, 2019

I read how setting Bias to 0 can cause artefacts called "Shadow Acne". I guess you have to find a compromise. I was able to set the bias to 0.03 without seeing in cracks in the shadows. 0.04 made a very small crack; noticeable but acceptable. So try that, with high quality settings, high resolution settings and "close fit" and see if it fixes it. Other than that i don't know, because I don't get the acne problem. Let us know if you find a solution.

kristijonas_unity · Mar 12, 2019

The simplest solution to this problem would be to select the mesh, and in the Cast Shadows dropdown, enable Double Sided shadows. The issue should then go away.

Hallur90 · Mar 13, 2019

kristijonas_unity said: ↑

The simplest solution to this problem would be to select the mesh, and in the Cast Shadows dropdown, enable Double Sided shadows. The issue should then go away.
Click to expand...

Thank you! It werks

Out of curiosity, is there a significant performance hit by using two sided shadows?

kristijonas_unity · Mar 13, 2019

Hallur90 said: ↑

Thank you! It werks

Out of curiosity, is there a significant performance hit by using two sided shadows?
Click to expand...

The performance hit should be negligible, as all shadowmap calculations are done on the GPU.

gryph · Mar 24, 2020

Bit of a necro-post, but figured this was as relevant a place to ask as any:
What if turning on Two-Sided shadows reduces, but does not completely eliminate the issue?
Has anyone else experienced this issue, and hopefully found a resolution to it?

LaireonGames · Jan 14, 2021

I'm currently talking to someone in QA (who is passing questions to a developer) who says that I should place shells around my meshes to avoid light leaks. This is just a horrible hack that is not acceptable for our project.

I've tried things like adding extra geometry to the meshes back faces, double sided casting and other such things, no good results so far.

Even things like NGSS on the asset store are no better

UnityMaru · Jan 14, 2021

LaireonGames said: ↑

I'm currently talking to someone in QA (who is passing questions to a developer) who says that I should place shells around my meshes to avoid light leaks. This is just a horrible hack that is not acceptable for our project.

I've tried things like adding extra geometry to the meshes back faces, double sided casting and other such things, no good results so far.

Even things like NGSS on the asset store are no better
Click to expand...

Do you have the issue number of your case? I'd like to bring this up internally

LaireonGames · Jan 14, 2021

Would love it if you could! Case 1300992

UnityMaru · Jan 14, 2021

Thanks! I can't promise an exact ETA but I will get the Graphics team to look at this and get me some feedback to share with you.

Honorsoft · Jan 31, 2021

I had similar problems with light passing through meshes, and even illuminating objects through other meshes, I found that a combination of adjusting the light's "Near Plane" and adjusting the "Bias" got rid of the leaks and helped the light look more natural.
For example, I had a point light on one side of a mesh, and I noticed that objects behind the mesh were being illuminated, like the light was just passing through the character. I also had a horse mesh that had lighting and shadow issues, and found that adjusting the Near Plane and Bias helped. I know not all my problems were light leaks, but for those I found that adjusting the light's Near Plane and Bias helped fix that too, but required fine tuning. Hope that info is helpful and relevant.
-The picture with the big "light hole" in the shadow is the before picture.

LaireonGames · Jan 21, 2021

The QA I was speaking to eventually gave up with me with the conclusion that this is a limitation of Unity (which they stressed earlier is the same in all engines) and that they are confident I can find a solution.

I disagree cause a solution would be within Unity. However if I invest a significant amount of time to solve a problem Unity has yet to solve I might be able to come up with a complex workaround. Chances are though eventually a situation will come up that the workaround wont cover so I will then have to throw it away in favour of a proper fix such as writing my own shadows/lighting specific to our needs.

Why am I using Unity again?

If this is such a known limitation for so long, why is the documentations only coverage of it to turn on two sided shadow casting?

This feels like such a broad topic, to not address it at all is maddening. Even if its just linking out to a wiki page on the topic is better than nothing cause it at least shows that this page has been deemed applicable to Unity. This for example is a great high level explanation of the problem:

https://gamedev.stackexchange.com/questions/173037/why-do-some-games-show-lights-shine-through-walls

Granted its too high level to match the high level question but this is the sort of overview I would want from Unity. This is the problem, this is why its a problem. This setting helps overcome it in this situation. This workaround such as shells works well in this situation and works best with a low bias or a distance less than X times your shadow distance. Shadow cascades over X distance struggle with it the most in X situations. Etc etc etc.

I don't expect them to cover all situations, but to not cover any leaves me with no clues as to where to start.

Edit: for context, we are working on a game similar to Minecraft. Things like sticking a box around a room are easier said than done

Anyway, rant over. I'm told as a result of our long email chains of trying various things that the documentation will be updated.

uy3d · Jan 21, 2021

Some background information about what you are seeing there:
The artifact from the original post is caused by how Unity handles shadowmap biasing in builtin (HDRP handles this in a different way, URP possibly as well).
Generally speaking, whenever you do shadowmapping and your shadowmap doesn't have subpixel resolution on the screen, you get artifacts caused by incorrect self occlusion. There are various ways on how to deal with this, but one standard approach is to mess a bit with the depths. We also distinguish between caster bias and receiver bias. The difference is that with caster bias, we mess with what we render into the shadowmap. The surface shader then takes the depth value as is from the shadowmap and does shadow calculations. The advantage of doing this is that the shadowmap pass is usually bottlenecked by the rasterizer, so doing a bit more work in the shader won't cause much harm. In fact there's been hardware support for adding depth biases during rasterization for a very long time (depth bias and slope scale depth bias) so you don't even need to do this in the shader. This is the fatest way of modifying depth.
The other way is receiver biasing. In this case we render objects into the shadowmap as is, but when doing the shadow calculations later we mess with the screen pixel position before comparing it to the depth value from the shadowmap. The main disadvantage here is that it makes the lighting shader more expensive, as we do additional calculations in the pixel shader. The advantage is that we have information about the object that's being rendered and can do some smarter biasing.

Builtin does caster biasing, so it modifies the meshes while they're being rendered into the shadowmap. There are two controls for biasing - bias and normal bias. The first will simply push the surface a bit further away from the light. When the lighting shader evaluates an object that is supposed to be lit, the object will still "see" itself in the shadowmap, as it's the closest surface. By pushing the object a bit further away in the shadowmap, we make sure that no erroneous self occlusion is detected which usually shows up as what's called "shadow acne". This works well for surfaces facing the light in a perpendicular way, but the more slanted the surface gets the larger shadow bias you need to combat the artifact. The hardware's slope scale depth bias tries to take this into account when modifying the depth value. If the bias is too little, you still get the artifact. If it's too large, you start getting light leaks, because you've now pushed the shadow caster so far away from the light, that another surface, which should be in shadow, is not in shadow anymore. This is NOT what you're seeing in the first post.
The second way of fixing artifacts is to not only change the depth value in the shadowmap, but change the vertex positions of a triangle before drawing it into the shadowmap. Bultin is using the surface normal for this, so we're not only pushing the triangle away from the light, but nudge it in the direction of the normal. You have to distinguish two types of meshes now. Meshes that are supposed to resemble a smooth surface naturally have edges in the mesh due to limited triangle counts. However, the normals of shared vertices will point in the same direction to get smooth shading over the surface. For such a mesh, when we do normal biasing, adjacent triangles will have their vertices pushed in the same direction, so the resulting mesh is still tight. The second type of mesh actually wants to have an edge, so shared vertices will have two normals, pointing in different directions. When we normal bias these in the shadow caster pass (we push the vertices along the negative normal), we're actually breaking up the mesh. You can see this everytime you have two faces creating a corner that points away from the light. In this case the mesh will be broken up, and you will be able to see a gap in the shadowmap. This gap then becomes visible in the form of light leaks from the first post. Setting the normal bias to 0 will close the gaps, so you will have to deal with the remaining artifacts only by using the remaining bias parameter.

The reason double sided helps is because we won't do any culling on the faces anymore. The gaps caused by the normal biasing algorithm in the front faces are still there, but the backfaces may now be able to fill those gaps. Backfaces on the other hand suffer from the same problem, only with corners facing the light (the inverse of the front faces). If you line up the mesh and the light in a way that the gaps from the front faces and the gaps from the back faces align in the shadowmap, you again get light leaks, which is why this is not a silver bullet.
Adding low poly blocker geometry into the mesh for the sole purpose of fixing these leaks can be more helpful than making the object doublesided. The blocker mesh should be set up so it only renders into the shadowmap and nothing else to save performance. The blocker mesh should also be authored in a way that inward facing corners of the outer mesh face flat surface in the blocker mesh.

This will help you fix light leaks occuring within a mesh. However, you can also create the problematic case with separate adjacent meshes, e.g. building a stair case out of cubes. Even though the cube itself as a convex hull doesn't suffer leaks, the level created has many concavities from the light's point of view. You can either add blocker geometry for such cases to the level, not use normal biasing (and potentially write your own receiver biasing code in your shaders), or try the new SRPs and see whether their biasing approach works better for you.

LaireonGames · Jan 21, 2021

Thanks uy3d this is genuinely helpful and the sort of information I would have liked to have seen in the docs.

Its a lot to take in so I wont try to comment on anything specific now since I have a busy day.

However the final comment around SRP's, its not as easy as that. URP doesn't have the features we need (deferred rendering, spot light shadows) and still seeing too many threads like this for HDRP:

https://forum.unity.com/threads/hd-rp-vs-built-in-pipeline-performance-comparison.526509/page-6

The problem is I don't have confidence that swapping to HDRP will fix our issues, and to test that is a HUGE undertaking to rewrite all of our shaders, learn HDRP specific settings/setup and start fiddling with everything. If it supported surface shaders or at least had a foundation to do most of the legwork converting from surface to shader graph so we could run comparisons without having to invest weeks of time, then I might consider trying it out.

LaireonGames · Jan 22, 2021

Ok so this is starting to make sense and I think I have the start of a solution for our project based on this information. Thanks again for sharing that.

We already have a custom 'lighting' system. How it works is when I generate a world I effectively do a flood fill of empty blocks to spread a light value that is sort of in a 0-1 range. This is baked into a UV channel of the mesh to then be read by our custom shaders to make things like caves dark (by fiddling with both diffuse and emission depending on time of day etc).

Its very separate from normal lighting etc and doesn't interfere. I had to make it so things were bright with ambient light disabled whilst still being dark looking into a long stretch of cave.

Am I right in saying then that in our mesh shaders if we do a custom shadow pass and read this lighting value, I could use it to artificially increase the depth of the mesh in the shadow map. If so, how would I begin to go about doing that?

We use deferred rendering, guessing I would need to modify its shader for shadows.

I have already tried things like modifying the vertex shader of the meshes to push every vert towards the main directional light but it failed to give reliable results. Clipping was also a major issue.

As a note, this is still going to be a mess for us even if this is correct because all this does is ensures shadows cast properly for the main directional light. I would still have to treat shadows differently for each spot light effecting the mesh (such as with a carried torch) and undo the modification to depth.

uy3d · Jan 22, 2021

So first of all, does setting the "normal bias" to 0 on the light fix the light leaks in your use case? If it does not, then your issue is something else possible on top of the normal bias issue. If it does fix the leaks, and you see self shadowing artifacts that you cannot fix using the "bias" setting on the light, then you may have to implement your own receiver bias in your custom shaders.

A few things to keep in mind:
- By default we only render front faces into the shadowmap from the light's point of view. This means that the mesh needs to be closed. If for example you make a scene with a room that the player never sees from the outside, you might think that the walls can be simple quads instead of boxes. This will work for the player, as the player will never be able to see the room from the outside. The light however does, and as it only sees the backfaces of the walls, they all get culled in the shadow pass and the sun shines right into the room as if there were no walls. For this reason, such occluders must either be a proper closed mesh (boxes vs. quads) or the quad must be set to double sided so it doesn't get culled.
- The main directional light in Unity builtin gets special treatment. After the shadowmaps are rendered and an initial depth prepass, the directional light (with its shadow cascades) is evaluated in a fullscreen pass shader. This creates a screen aligned 2d texture which only contains the shadows for the dir light. We do this so the subsequent lighting shaders can be lighter in execution, as they only need to do one texture fetch for soft shadows. This screenspacee shadow shader can be overridden by the user if desired.

As for your question:
- You can push the verts in a custom shader, I'm not sure what effect you are trying to achieve. Manipulating the depth written into the shadowmap only affects visibility, so it's a lit/unlit thing. Gradually changing the depth of those vertices won't result in gradual darkening of the shadows.

LaireonGames · Jan 22, 2021

Nope, setting the bias to 0 doesn't fix our light leaks.

The initial issue was that indeed our walls are paper thin with no back faces. Turning on two sided helped but still leaked badly.

As per a suggestion from support, I added shells. However the max thickness I can make with them is < 1m otherwise it starts to clip into other blocks and even with that, light was still leaking through. As a note, I added them quickly as a test so I only added new backfaces, I didn't properly seal the mesh with top and bottom faces (and then the test was to shine light directly onto the faces to minimise the need for them). Light still leaked. I explained what I did and never got a comment on this so I assumed this quick test was sufficient.

In regards to your last paragraph: seems like I misunderstood then. I thought manipulating the depth sent to the shadow map would effectively let me add/remove shadows.

I've started to make my peace with a shell workaround were I have a mesh that covers the entire world and moves with the player. Its not ideal since it needs rebuilt each time the player moves to a new chunk and will produce bugs like the following image:

Assume the red arrow is a long connected cave system that leads to the surface and has direct line of sight. Blue line is the outer bounds of the shadows mesh. If the player is at the bottom of the cave and looks out, they will see shadow when they should see light. To avoid this, I'm going to need to make a Really big mesh to cover max draw distance. Sure I burst compile and build meshes on a job, but still a lot of mesh memory/processing that could be spent elsewhere.

Edit: realised I forgot to explain. This shell mesh has to match the terrains height exactly to avoid bugs. So its not just a box. A test shell I made has 5.5k faces but granted I've not tried to greedy mesh it yet which should get the number down (but again, more processing time)

Marc-Saubion · Jan 24, 2021

In my experience this is caused by non hermetic meshes. By that I mean that when you have two polygons, they should share a common edge. If they are just superposed, light can get through and that's why there is a leak.

Test you lighting with unity's cube and sphere. If they don't leak, you mesh needs to be fixed.

LaireonGames · Jan 24, 2021

I don't think that's our issue but again something I would have liked to see information on in the docs.

Quoting Unity:
"When we normal bias these in the shadow caster pass (we push the vertices along the negative normal), we're actually breaking up the mesh"

Sounds like even if they did share verts it would, technically, be broken up anyway in the shadows pass based on the face normals. At least if you have a normal bias as anything above 0, and possibly for 0 itself to avoid a branch on the GPU.

For the record though, our meshes don't share verts since it causes problems with the custom data we store per vert/face. However, fairly confident its not a problem because we work in chunks and the places where the chunks join each other don't behave any differently (was actually one of the first things I checked/worried about) in regards to light leaking.

Maybe the issues you saw were caused by meshes made by an artist in external software and they didn't notice some verts needing welded. That I can see causing light leaks

uy3d · Feb 5, 2021

For your specific case it's hard to say what the issue is without knowing more about the scene setup. If you have a terrain, this should already act as an occluder, so there shouldn't be a need for a shell mesh. I'm also not sure what you mean by not expecting to see shadows when at the bottom of that cave. Unless the sun is directly shining into the cave, you will not receive any direct lighting in there, so everything will be in shadow. You need indirect lighting (lightmaps, lightprobes) to get some sky lighting in there.

LaireonGames · Feb 5, 2021

I probably didn't explain well. Here is a small section from an example world. The white mesh is the shadow shell (with rendering turned on for this screenshot). This shell is generated depending on where the player is standing and the loaded worlds shape etc etc.

Now imagine a long shallow cave that starts from the surface and cuts into the world at a 15 degree angle. If light is shining directly down the cave at the right time of day, the cave should be fully lit.

However, there will be a point if the cave is long enough that the light will now be artificially blocked by this shadow shell. The shell can't cover the entire world (explained below).

To get around this, I could make the shell bigger but it can only be as big as the max shadows distance (currently already 700) but it will always have a hard cap to look decent. Our world is infinite, shadows obviously can't match that and fit into a map nicely!

It feels like 'real' solutions would be things like ray traced shadows, but as the market currently stands that would cut our potential audience pool drastically.

Also, not using terrain but procedurally built meshes since its a game like Minecraft and thus the world is constantly changing.

uy3d · Feb 5, 2021

And how do you build those caves? As long as the walls forming the cave below the terrain are double sided, so they get rendered into the shadowmap, there should be no need for that shadow shell.

LaireonGames · Feb 5, 2021

Tried that Currently they are paper thin but I did try adding a more local shell, went into more details above:

"As per a suggestion from support, I added shells. However the max thickness I can make with them is < 1m otherwise it starts to clip into other blocks and even with that, light was still leaking through. As a note, I added them quickly as a test so I only added new backfaces, I didn't properly seal the mesh with top and bottom faces (and then the test was to shine light directly onto the faces to minimise the need for them). Light still leaked. I explained what I did and never got a comment on this so I assumed this quick test was sufficient."

This is how they look currently (without the hack for shells described above) with the world shadow shell turned off.

From the perspective of this image, light was coming from roughly the top left. Bias and normal bias set to 0, resulting in the horrible acne on the roof (not the easiest to see from this angle though). I had 2 sided shadow casting on which should be getting those left and top faces into the shadow map but no joy.

uy3d · Feb 5, 2021

That's odd though, if the light came from the top left, the roof and left wall should be facing away from it. Without an ambient term they should be dark as well. Are you sure the normals are pointing inwards, and the triangle index order has the correct winding for the walls?

LaireonGames · Feb 5, 2021

My thinking as well!

I don't know what order the triangles would need to be in to be correct for the shadows but since it renders the correct way I assume its correct.

This is a simplified and annotated summary of how I would make 2 triangles to make up a face of the roof:

Code (CSharp):

currentVerticesList[0] = new Vector3(x, y, z);//bottom left

currentVerticesList[1] = new Vector3(x + 1, y, z);//bottom right

currentVerticesList[2] = new Vector3(x + 1, y, z + 1);//top right

currentVerticesList[3] = new Vector3(x, y, z + 1);//top left

faceList.Add((ushort)(count + 0));//bottom left

faceList.Add((ushort)(count + 1));//bottom right

faceList.Add((ushort)(count + 3));//top left

faceList.Add((ushort)(count + 1));//bottom right

faceList.Add((ushort)(count + 2));//top right

faceList.Add((ushort)(count + 3));//top left

count += 4;

Normals also seem to be correct. The roof vertices all have a normal of (0,-1,0)

uy3d · Feb 5, 2021

The code seems fine. Have you checked what's being rendered into the shadowmap? You can use the Frame Debugger for that, under Window -> Analysis -> Frame Debugger. If you enable it and navigate to the shader caster pass, you can use the Game View to see the contents of the depth buffer.

For your particular use case, you may have to custom code the shadow pass, though. Even if you remove all biasing (the in engine shadow caster pass will slightly offset regardless, you have no control over this), you still have the fundamental problem that due to limited resolution of the shadowmap, you'll get these glowing lines along the edges of your bricks. When you use soft shadows this will be even more visible due to the filter size that's essentially sampling the shadowmap outside of your world (beyond the walls of your cave, the world is supposed to be solid, but for Unity it's empty, so there's light everywhere - the PCF filter picks up the light, causing the glowing outlines). There may be an easier way to "close" the world in the shadowmap. The algorithm would be something like this, but needs to be custom coded:
- disable culling (=double sided)
- use a depth stencil format for the shadowmap
- depth test as usual
- setup the stencil test in a way that stencil always passes, and if the depth test passes you write e.g. 0 into the stencil buffer for front faces, 1 for back faces (there are two separate controls for stencil for front and back faces, e.g. PassFront and PassBack). For front faces StencilPass can be Zero, for back faces Replace using the reference value. The idea here is that after the shadowmap has been rendered, you have the depths in there, and the stencil buffer encodes for each pixel whether this depth comes from a front face or a back face.
- draw the scene into the shadowmap
- disable depth tests but enable depth writes
- set the stencil pass condition to equal, using the same stencil reference value as before
- draw a fullscreen quad into the shadowmap on the nearplane of the light. The stencil test will fail for front faces in the shadowmap. For backfaces, the depth value will be overwritten with znear, essentially pulling those surfaces right up to the light. After this, the shadowmap should be ready for the remaining passes in the engine, no further custom code required.
Be aware that doing this will prevent you from using actual double sided geomery (often used for flags waving in the wind for example), unless you distinguish between legitimate double sided geometry and your procedural bricks filling the world.

LaireonGames · Feb 12, 2021

Thanks again for the detailed reply!

Forgot/didn't think to check the frame debugger, that's a good shout. I think of it as a performance tool and forget it really is a debugger.

The custom shadow pass sounds much more along the lines of what I was originally hoping for as a solution, but I felt at a loss for information on how to even start making one (felt like I was going to have to make shadows from scratch).

I think with this information I can take a stab at it. I've not made a stencil shader before but the concept makes sense and seems simple enough. Might be a few days (edit: weeks at this rate!) before I can find a block of time to dedicate to trying this out and learning all this but will post results when I have them

Search Unity

Unity ID

Useful Searches

Light passing through mesh at seams

Unity Technologies

Unity Technologies

Community Engagement Manager PSM

Community Engagement Manager PSM

Attached Files:

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies