I think it might get tricky when we get to edge cases like the next slide (where the two triangles are intersecting), but agree that we must be able to have some sort of shortcut for some of these cases.
Another question I have is, what if two triangles have the same depth. Like a case where one triangle is within another triangle and both have depth=0.5 for example. Or would we just try to avoid circumstances where this is the case?
I think the answer to two triangles having the same depth might come down to a minor implementation tweak in the case of the depth buffer algorithm described above. For example, if the comparison test in pass_depth_test() evaluated to true on <=, then the sample point from a newer triangle to be drawn would be shown at that depth. Otherwise, if the comparison test was <, then the sample point from the first triangle to be drawn at that depth would be shown, and subsequent sample points at that depth would fail the depth test.
On the same depth question, assuming rendering is a meaningful cost; would it make sense to not render a new point if depths are equal in order to save compute?
Doing some lecture review, and another question comes up on performance. In Lecture 6, Prof K. said the complexity is O(1) since there is a single lookup and does not depend on previous lookups. I thought we are looking complexity as a function of pixels here, so it would be O(n), just wondering what the right intuition is to have here.
Please log in to leave a comment.
Are there any other ways of determining whether a triangle is occluded by another in 3 dimensions? The example I'm thinking is that a triangle on the opposite side of an object will have winding in the other direction. For instance, suppose I want to render the moon. If all triangles are going in the same winding, then the triangles we can't see that are occluded by the side of the moon facing us should be in an opposite winding, right? Can we also discard these triangles right off the bat if the moon is opaque?