I think that it doesn't matter if the triangles are processed in different order since the results would be the same values. But if some triangles are the same depth, then the order does matter since the first processed ones will show up while the others of same depth won't.
Sybil
Agree with the top comment. The order won't matter since it's trying to find the smallest depth out of a bunch depths given, which should be the same no matter the order it's passed in (unless there are duplicates)
peanut
Order doesn't matter + 1. We only pick minimum(depth at that point). How do we deal with same depth?
keenan
Great answers. Right, order doesn't matter---though good catch on the case where primitives appear at exactly the same depth. In this case, you probably get Z-fighting since the depth values won't be computed with perfect accuracy! But you could specify this behavior very carefully for certain use cases, e.g., a sample passes if it has strictly smaller depth, or if it has depth less than or equal to the depth buffer. In fact, many possible depth comparison functions are supported in hardware.
graphicstar11
I'm a little confused on why order doesn't matter... then what determines the depth of the triangles?
ecdeo
The order doesn't matter because at each point in the z-buffer, we are essentially taking the minimum value of the depth. Since the min function is commutative, i.e., for x, y, min(x, y) = min(y, x), even if we feed in the objects in different order, the final result is the same. The value in z-buffer also correspond to the object that has that depth, so the color buffer would record the corresponding color value of the object (except for the case of z-fighting)
keenan
@ecdeo has it right!
FeiFeiFei
Agreed. For example, if we have overlapping triangle A and B, A is deeper and B is shallower. Suppose, A comes first, B comes next, B will override A since its shadllower. Or, B comes first and A comes next. A is deeper so won't change anything.
bcagan
I thought you were specifically asking about z-fighting, so I was going to say it does matter solely in the case of z fighting, but I guess that that would occur in any order.
Sherwin
The order doesn't matter because the z-buffer is a max() function of all the depth values of the primitives. The max function does not care about the order
nouyang
So the z-buffer always keeps track of the nearest depth for each sample thus the order doesn't matter since we're looking at it not as a primitive but per sample.
oadrian96
Although the order doesn't matter from an algorithmic perspective the Z-buffer becomes a shared resource that could be updated by many threads at a time so there must be some lock either at the hardware level or software level to address this concurrency no?
keenan
@oadrian96 Depends on how you parallelize rasterization. One common approach is that you only have a single triangle "in flight," and each thread is responsible for rendering a "tile" of the image (i.e., an NxN block of pixels). Since these tiles don't overlap, you don't get any conflicts with Z-buffer read/writes.
I think that it doesn't matter if the triangles are processed in different order since the results would be the same values. But if some triangles are the same depth, then the order does matter since the first processed ones will show up while the others of same depth won't.
Agree with the top comment. The order won't matter since it's trying to find the smallest depth out of a bunch depths given, which should be the same no matter the order it's passed in (unless there are duplicates)
Order doesn't matter + 1. We only pick minimum(depth at that point). How do we deal with same depth?
Great answers. Right, order doesn't matter---though good catch on the case where primitives appear at exactly the same depth. In this case, you probably get Z-fighting since the depth values won't be computed with perfect accuracy! But you could specify this behavior very carefully for certain use cases, e.g., a sample passes if it has strictly smaller depth, or if it has depth less than or equal to the depth buffer. In fact, many possible depth comparison functions are supported in hardware.
I'm a little confused on why order doesn't matter... then what determines the depth of the triangles?
The order doesn't matter because at each point in the z-buffer, we are essentially taking the minimum value of the depth. Since the min function is commutative, i.e., for x, y, min(x, y) = min(y, x), even if we feed in the objects in different order, the final result is the same. The value in z-buffer also correspond to the object that has that depth, so the color buffer would record the corresponding color value of the object (except for the case of z-fighting)
@ecdeo has it right!
Agreed. For example, if we have overlapping triangle A and B, A is deeper and B is shallower. Suppose, A comes first, B comes next, B will override A since its shadllower. Or, B comes first and A comes next. A is deeper so won't change anything.
I thought you were specifically asking about z-fighting, so I was going to say it does matter solely in the case of z fighting, but I guess that that would occur in any order.
The order doesn't matter because the z-buffer is a max() function of all the depth values of the primitives. The max function does not care about the order
So the z-buffer always keeps track of the nearest depth for each sample thus the order doesn't matter since we're looking at it not as a primitive but per sample.
Although the order doesn't matter from an algorithmic perspective the Z-buffer becomes a shared resource that could be updated by many threads at a time so there must be some lock either at the hardware level or software level to address this concurrency no?
@oadrian96 Depends on how you parallelize rasterization. One common approach is that you only have a single triangle "in flight," and each thread is responsible for rendering a "tile" of the image (i.e., an NxN block of pixels). Since these tiles don't overlap, you don't get any conflicts with Z-buffer read/writes.