Timeline for Rasterization: How does hardware disambiguate identical Z values at silhouette edges?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 11, 2021 at 15:56 | comment | added | pmw1234 | I think this is the wording of this question, which is starting to become circular. There are the edges of triangles and the process drawing that edge such that no fragments are drawn twice, and two triangles that are essentially coplanar whose fragments effectively overlap. Your response answers the second case, my response answers the edge case, in either case the original question has been answered. | |
| Mar 11, 2021 at 15:40 | comment | added | Nicol Bolas | @pmw1234: Think of the letter V. Imagine that represents looking down at two triangles sharing an edge at the point of the "V". If you look from the right, one face faces towards you and the other away. Both triangles at the tip of the "V" rasterize the same samples (relative to the camera). That is, both triangles own the same "top-left" parts of each pixel, so they rasterize on top of each other. The samples from the tip can be arbitrarily close to each other in depth space. | |
| Mar 11, 2021 at 15:25 | comment | added | pmw1234 | Rasterization rules do in fact cover this situation, I suggest you look at it more closely, Z fighting doesn't occur on triangles that share an edge because they the edges do not overlap when implemented correctly. | |
| Mar 11, 2021 at 15:20 | comment | added | geometrian | This is correct as far as it goes, but does not address the problem. Raster rules (and so, sample coverage) is already correctly implemented. | |
| Mar 11, 2021 at 13:14 | history | answered | pmw1234 | CC BY-SA 4.0 |