0
\$\begingroup\$

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?

//EDIT

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

\$\endgroup\$
  • \$\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 '18 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\$ – user1118321 Jul 20 '18 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\$ – Derag Jul 20 '18 at 9:12
  • \$\begingroup\$ @user1118321 It is standard surface shader but artifacts stay with simple dot product between normal and light direction. \$\endgroup\$ – Derag Jul 20 '18 at 9:12
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\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\$ – Derag Jul 20 '18 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 '18 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\$ – Derag Jul 20 '18 at 23:09
  • \$\begingroup\$ Also custom merging meshes helped a little, but some artifacts still appears. \$\endgroup\$ – Derag Jul 21 '18 at 11:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.