I was wandering how I could render all the semi-transparent triangles "in back-to-front order". The easiest way I could come up with is sorting all these semi-transparent triangles by depth and then rendering them. Is there any better way? And what is the most common algorithm used in real industry?
Max
There are a variety of techniques for rendering transparent triangles. I'd say the most common is, as you suggest, just sorting your transparent primitives by depth and rendering them after the opaque ones. However, this doesn't handle the case of intersecting transparent triangles, which needs a more advanced (and slow) option like keeping and sorting a list of all samples for each pixel. There are also approximations like weighted-blended order-independent transparency that just weight the sample contribution by its depth & alpha instead of doing it in the correct order.
heethesh
Isn't back-to-front order slightly slower as one of the slides previously mentioned more read/write ops are involved compared to the front-to-back order, which should be faster I think.
Max
That's true - many modern game engines render mostly front-to-back to take advantage of early Z culling (if your fragment is behind the current depth, you can get rid of it without having to compute its color).
That doesn't really help with transparent primitives, though, because you still have to sort them for the UNDER (in this case) operation to make sense. Still, if you have already rendered all of your opaque primitives, you will get a lot of the early-Z benefit anyway.
I was wandering how I could render all the semi-transparent triangles "in back-to-front order". The easiest way I could come up with is sorting all these semi-transparent triangles by depth and then rendering them. Is there any better way? And what is the most common algorithm used in real industry?
There are a variety of techniques for rendering transparent triangles. I'd say the most common is, as you suggest, just sorting your transparent primitives by depth and rendering them after the opaque ones. However, this doesn't handle the case of intersecting transparent triangles, which needs a more advanced (and slow) option like keeping and sorting a list of all samples for each pixel. There are also approximations like weighted-blended order-independent transparency that just weight the sample contribution by its depth & alpha instead of doing it in the correct order.
Isn't back-to-front order slightly slower as one of the slides previously mentioned more read/write ops are involved compared to the front-to-back order, which should be faster I think.
That's true - many modern game engines render mostly front-to-back to take advantage of early Z culling (if your fragment is behind the current depth, you can get rid of it without having to compute its color).
That doesn't really help with transparent primitives, though, because you still have to sort them for the UNDER (in this case) operation to make sense. Still, if you have already rendered all of your opaque primitives, you will get a lot of the early-Z benefit anyway.