3

I am using the Graphics3D command in Mathematica to plot multiple 3 dimensional parallelotopes and two of them have overlapping faces. These two shapes have different colored faces, so the textures of the two seems to jump between the two colors. Is there any way to remove one or both of the textures in the overlapped area? Picture relatedIn the red circle is an example of the two colors mixing and switching from one to the other

Matt Roberts
  • 31
  • 1
  • 3
    Please provide example code so we can easily reproduce the issue. – kirma Jun 10 '20 at 14:43
  • 3
    This looks like z-fighting, see here: https://en.wikipedia.org/wiki/Z-fighting The effect is hard to avoid and is very pronounced in this example: Graphics3D[{Green, Cuboid[{0, 0, 0}, {1, 1, 1}], Red, Cuboid[{1/2, 1/2, 1/2}, {1, 1, 1}]}] – flinty Jun 10 '20 at 15:14
  • 1
    You have probably specified the surfaces so that they are exactly the same distance away from the camera. In that case it's impossible for Mathematica to know what it is you want. To resolve that, you only have to add a negligible offset to one of the surfaces to indicate to Mathematica which surface is supposed to be perceived as being closer to the camera. For example, in flinty's example you may change the second parameter of the red cube to {1, 1, 1} + 0.0001 to fix the issue. – C. E. Jun 10 '20 at 15:19
  • Related? (111945) – MarcoB Jun 10 '20 at 15:59

1 Answers1

7

As I mentioned in the comments, this is called z-fighting. It's hard to avoid and it produces ugly artifacts like in this example:

Graphics3D[{Green, Cuboid[{0, 0, 0}, {1, 1, 1}], Red, Cuboid[{1/2, 1/2, 1/2}, {1, 1, 1}]}]`

zfight

Your graphics card determines whether a triangle is occluded by another triangle using a z-buffer. If the z-buffer has too low of a precision this means the outcome will be subject to floating point rounding error and as you rotate the object you'll experience flickering and one surface popping out over another like this.

You can eliminate the z-fighting by making one face very slightly offset in a way that is visually unnoticeable but distinct enough that the depth buffer will consistently produce the occlusion of one triangle by another as you move the object:

tiny = 2^-16;
Graphics3D[{Green, Cuboid[{0, 0, 0}, {1, 1, 1}], Red, 
  Cuboid[{1/2, 1/2, 1/2}, {1 - tiny, 1 - tiny, 1 - tiny}]}]

zfight2

flinty
  • 25,147
  • 2
  • 20
  • 86
  • Very well explained. +1 – Henrik Schumacher Jun 10 '20 at 16:07
  • 2
    I was also wondering about this and Method -> {"RelieveDPZFighting" -> True} doesn't fix the problem at least for sheared cubes. A slight offset of coplanar surfaces does it. – kirma Jun 10 '20 at 18:51
  • Thanks @kirma . I hadn't heard of that option. Maybe using BSP trees instead of z-buffering works? – flinty Jun 10 '20 at 20:05
  • As @flinty points out, this is easily solved (so that the visible surface is the latter given to Graphics3D) by giving additional option BaseStyle -> RenderingOptions -> {"Graphics3DRenderingEngine" -> "BSPTree"} – Anti Earth Mar 06 '24 at 20:19