As many others I am aware of the Z fighting issues in the viewport and in rendering.
Usually I do not have faces lying parallel and intersecting which solves the problem.
But when working with fast previewing of geometry produced by modifiers like solidify and array I cant always control that overlapping polygons do not appear.
I could imaging other scenarios as well.
My question is related to a term I have heard mentioned: Z bias.
As I understand it, it is an index specifying if two planes overlap which one the render should render.
I do not believe it is implemented in Blender but I might have missed something.
Is this option available somewhere?
Not sure exactly what your problem is… but what i think your describing is orthographic vs perspective? if so… mouse over your 3d viewport and hit the 5 on the keypad (the numbers on the right hand side of your keyboard… not at the top of the keys)… this will toggle between orthographic and perspective?
I think ejnaren is talking about the effect of overlapping faces causing render artifacts - an example is also found when using array modifier on a cube and using empty object for mapping - if the faces of the resulting cubes overlap at onset, when rendered you will see dark artifacts. Like he said, keeping faces from lying on same plane and intersecting prevents this render artifact. I woul dwonder if it would be possible to determine in the array modifier example what to render, or if it would be necessary to render as one face because of intersection.
@doublebishop Itis indeed the problem that @Craig Jones describes.
It is widely known as “Z-fighting” as the renderer do not know which plain to render and they “fight” to get rendered
A Z-Bias option would let one face overrule the other but I do knot know if it is as easy as that algorithm wise. (probably not ;P).
The simplest solution to z-fighting is to not use Blender Internal if you know your scene will contain overlapping faces. Lux renders overlapping faces correctly and so does Cycles and 3Delight.
z-fighting is caused by the way the GPU performs depth testing
depth is calculated from geometry using 32 bit floating point precision
but is compared against existing scene depth that has been stored in 24 bit fixed precision
The conversion from 32 bit floating to 24 bit fixed introduces rounding errors (and GPUs are free to implement different rounding schemes)
It is this rounding that causes the alternation between near and far that causes the horrible z-fighting patterns
As this behaviour is performed deep inside hardware there is no way to solve it.
I think that if GPUs were redesigned to perform the depth buffering like so:
32 bit float depth > 24 bit fixed depth > depth comparison > depth buffer
rather than:
32 bit float depth > depth comparison > 24 bit fixed depth > depth buffer
It would fix the z-fighting, but probably only for perfectly co-planar geometry
Another solution is to use a 32 bit floating point depth buffer …
Amazing @Amazing Factory.
It actually makes sense with the rounding.
Thanks for the insight.
I can also read that it is something we do not have any control over which is a bit sad of course.
How come Cycles and Lux does not have problems?
I am in no way an expert on any of this, but could it be because of how shaders work?
In my coding experience floating point values have always had an issue with precision. It is easy to asume some of the depth calculations go wrong there when blender tries to compare 2 values that are very close to eachother.
I also asume that cycles and luxrender have a different approach to rendering in general.
BI works using shaders (vertex & fragment) when rendering while cycles uses something else entirely.
Please correct me if I’m wrong (and I probably am), I want to know why this happens too.
