I created block of 3x3x3 cubes, disabled shadows, set directional lighting color to white and ambient to black. And I'm getting this:

Unity lighting problem

Any idea what is going on and how to fix it? Effect is visible when object isn't moving but with a lot less artifacts. It doesn't matter what is moving, camera or cubes. I would guess that this is precision problem but is there anything that can be done about it?


Here is a screenshot of cubes: enter image description here

Also this is how it looks after static batching (this happens because of Lightmap Static in Mesh Renderer is on):

enter image description here

  • \$\begingroup\$ What are the settings on your directional light, and can you show a screenshot of how the cubes are laid out in the scene? \$\endgroup\$
    – Ed Marty
    Jul 20, 2018 at 0:50
  • \$\begingroup\$ I've seen that sort of thing when a calculation produces a NaN. The entire fragment is killed. Have any divisions by 0 or square root of a negative number or anything like possible that in your shader? \$\endgroup\$ Jul 20, 2018 at 1:57
  • \$\begingroup\$ @EdMarty I haven't change the settings of directional light other than light color and disabling shadows. Cubes are standard Unity cubes snapped together. I will post screenshot later. \$\endgroup\$
    – user81986
    Jul 20, 2018 at 9:12
  • \$\begingroup\$ @user1118321 It is standard surface shader but artifacts stay with simple dot product between normal and light direction. \$\endgroup\$
    – user81986
    Jul 20, 2018 at 9:12

1 Answer 1


It looks like there is z-fighting between the shared edge of 2 planes. (where the cubes share an edge)

The plane facing away from the light is colored black, and the plane facing the light is colored gray, but the shared edges have the exact same 3d coordinates.

This is not a trivial problem to solve.

  1. You could update the geometry to just show the outward facing surface when cubes are connected.

  2. You could use shared vertex normals that face away from the cube center, but the color of the surface wouldn't be uniform across the surface.

  • \$\begingroup\$ This is what I thought but why batching didn't fix this? As far as I know GPU has to be consistence with edges and vertices position, otherwise there would be seams where two triangles connect. So, merging cubes into one object and removing theirs individual transforms to world space shouldn't fix the problem? After batching, all vertices will be transform by the same matrix. \$\endgroup\$
    – user81986
    Jul 20, 2018 at 20:50
  • \$\begingroup\$ Merged or not, there will always be z-fighting between coordinates of the same value in worldspace, even for triangles that belong to the same object. EDIT: I should add that the reason you don't see z-fighting between triangles that "connect" is because the color value of the overlapping edges is the same. \$\endgroup\$
    – Kyy13
    Jul 20, 2018 at 21:24
  • \$\begingroup\$ I did some more testing and changing depth buffer to 16bits fixed artifacts for this case but in more complicated scenario they still appear. But it is proof of z fighting (I think). \$\endgroup\$
    – user81986
    Jul 20, 2018 at 23:09
  • \$\begingroup\$ Also custom merging meshes helped a little, but some artifacts still appears. \$\endgroup\$
    – user81986
    Jul 21, 2018 at 11:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .