In the fourth row of the finished plane on the bottom right, why is the first element (5, red) rendered and not (5, blue)? I was thinking maybe it's similar to how in some games where two planes are very close to each other, they appear to clip on top of each other per frame.
Unicorn53547
Based on the algorithm in previous slide, we only update the buffer color and value if there is a strictly smaller one. So here, (5,red) will not be replaced by (5, blue)
joeyzhao123
Adding on to fyhannes observation about planes clipping onto each other, I'm curious if a similar effect where the color of an intersection of planes seem like they're flashing back and forth could be attributed to this algorithm. Maybe from a certain angle, the algorithm has a bug where it keeps replacing the pixels on the same distance with the other.
justin-shao
For situations where there are more than 2 triangles having the same z value at the same (x,y) location, I wonder if there are any meaningful heuristics to go off of as to which triangle we select. Otherwise, we are essentially picking arbitrarily (based on triangle query order).
Staffjamesfong1
@justin-shao Good question. There is no widely-accepted heuristic. For 3D applications, there usually is no special check for this edge-case. Instead we just let the code do whatever it happens to do. Even if we were to explicitly design a heuristic, we will run into problems with floating-point precision when trying to detect equal-depth triangles.
The net effect of this is a phenomenon called "Z-fighting".
In the fourth row of the finished plane on the bottom right, why is the first element (5, red) rendered and not (5, blue)? I was thinking maybe it's similar to how in some games where two planes are very close to each other, they appear to clip on top of each other per frame.
Based on the algorithm in previous slide, we only update the buffer color and value if there is a strictly smaller one. So here, (5,red) will not be replaced by (5, blue)
Adding on to fyhannes observation about planes clipping onto each other, I'm curious if a similar effect where the color of an intersection of planes seem like they're flashing back and forth could be attributed to this algorithm. Maybe from a certain angle, the algorithm has a bug where it keeps replacing the pixels on the same distance with the other.
For situations where there are more than 2 triangles having the same z value at the same (x,y) location, I wonder if there are any meaningful heuristics to go off of as to which triangle we select. Otherwise, we are essentially picking arbitrarily (based on triangle query order).
@justin-shao Good question. There is no widely-accepted heuristic. For 3D applications, there usually is no special check for this edge-case. Instead we just let the code do whatever it happens to do. Even if we were to explicitly design a heuristic, we will run into problems with floating-point precision when trying to detect equal-depth triangles.
The net effect of this is a phenomenon called "Z-fighting".