Alpha depth sorting, triangles and culling
Author
I am rendering a box (cube, but half the height) that
a) is semi-transparent (blend function (alpha, 1-alpha), based on texture)
b) is triangulated (each quad is split in two triangles)
c) has culling turned off
I have z-sorting implemented based on distance to camera, but if I play around with the camera enough, I always hit a situation where some of the triangles get missorted. I know there are situations where a z-sort fails, but I was always under the impression that there was no problem with simple convex shapes like a cube.
This should be easy to work out mathematically, but it is Sunday afternoon and my head feels like it's made of concrete, so I decided to pitch it into the community instead: should the situation as sketched above just work (meaning this is just a bug in my code I need to solve), or is it not possible at all to do this correctly?
What point on the triangle is used for the z-sort? It is possible for a vertex of a farther triangle to be closer than a vertex of a nearer triangle.
Author
Thus far, I tried polygon center, nearest vertice and furthest vertice. They all yield different, but equally bad, results.
I just realized using the center of the bounding box of each individual triangle will probably lead to better results, as it will assign the same distance to both triangles forming a quad (something the other methods fail at, leading to half-quads popping in/out).
"It is possible for a vertex of a farther triangle to be closer than a vertex of a nearer triangle."
Even when both triangles are part of the same convex shape (my box)?
I just realized using the center of the bounding box of each individual triangle will probably lead to better results, as it will assign the same distance to both triangles forming a quad (something the other methods fail at, leading to half-quads popping in/out).
"It is possible for a vertex of a farther triangle to be closer than a vertex of a nearer triangle."
Even when both triangles are part of the same convex shape (my box)?
Author
And to answer my own question: yes, with a box-shape problems do occur, even when rendering quads.
Imagine a cube, but half the height. Now, position the camera above the box. The top face of the cube should be drawn last. However, as the camera moves towards a side,
1. The center of the side gets closer than the center of the top face (as the sides or only half the height).
2. The closest vertice of the side is the same as the closest vertice of the top face.
3. The furthest vertice of the side is closer than the furthest center of the top face (again, as the side is only half the height).
Imagine a cube, but half the height. Now, position the camera above the box. The top face of the cube should be drawn last. However, as the camera moves towards a side,
1. The center of the side gets closer than the center of the top face (as the sides or only half the height).
2. The closest vertice of the side is the same as the closest vertice of the top face.
3. The furthest vertice of the side is closer than the furthest center of the top face (again, as the side is only half the height).
To sort robustly by depth I'd venture that you're gonna have to use some form of basic ray intersection with the polygons. Assuming that they don't intersect one another (in which case you'd have to tesellate them manually, per-frame... ouch), you need to check which is closer on a ray from the eye to each of the polygons. Technically you'll need to find a ray that passes through the eye AND both polygons... perhaps nontrivial (ie. solve for their occlusion in screen space). That said some approximation will likely do the trick in most cases. Once said ray is found, do a ray->plane intersection with each of the polygon planes (trivial) and check which intersection point is closer to the eye.
Author
First of all, thanks for the pointers!
"Technically you'll need to find a ray that passes through the eye AND both polygons... perhaps nontrivial (ie. solve for their occlusion in screen space). "
Ah, that sounds horribly expensive to do in realtime with any non-trivial amount of transparent faces, but perhaps I am wrong. I think it would come down to building an occlusion bounding volume for every transparent face, and checking every other transparent face to see if it is (partially or completely) within the volume. If even one of the vertices of a face is within the occlusion volume, that face is occluded by the current face. No need to do an additional ray-intersection test then.
Does that make sense? Are people actually using such algorithms for depth-sorting their transparent faces?
"Technically you'll need to find a ray that passes through the eye AND both polygons... perhaps nontrivial (ie. solve for their occlusion in screen space). "
Ah, that sounds horribly expensive to do in realtime with any non-trivial amount of transparent faces, but perhaps I am wrong. I think it would come down to building an occlusion bounding volume for every transparent face, and checking every other transparent face to see if it is (partially or completely) within the volume. If even one of the vertices of a face is within the occlusion volume, that face is occluded by the current face. No need to do an additional ray-intersection test then.
Does that make sense? Are people actually using such algorithms for depth-sorting their transparent faces?
Yeah it comes down to solving the exact occlusion problem, or more generally HSR. See the related discussion in this recent thread:
http://www.gamedev.net/community/forums/topic.asp?topic_id=359418
I seriously doubt that anyone is doing anything that complicated... I suspect that most engines just make sure that transparent objects never interact in any sort of complex manner (ie. for example their bounding volumes never intersect, they are always convex, etc), and use some sort of approximation algorithm (which may or may not be exact in the constrained case). As I mentioned in the other thread, alpha blending to get transluscency really is a hack and you should remember that it is such to keep it in perspective :)
http://www.gamedev.net/community/forums/topic.asp?topic_id=359418
I seriously doubt that anyone is doing anything that complicated... I suspect that most engines just make sure that transparent objects never interact in any sort of complex manner (ie. for example their bounding volumes never intersect, they are always convex, etc), and use some sort of approximation algorithm (which may or may not be exact in the constrained case). As I mentioned in the other thread, alpha blending to get transluscency really is a hack and you should remember that it is such to keep it in perspective :)
Erm, if its just a box (or any convex shape), why dont you just:
pass1: draw backfaces only
pass2: draw frontfaces only
No sorting needed.
pass1: draw backfaces only
pass2: draw frontfaces only
No sorting needed.
Sure that'll work in the case where you only have a single transluscent convex shape AND you want it to be two-sided. I interpretted the original post as a more general question (how to build robust transluscent sorting logic) with that as the example. Sorry if I misinterpretted :)
Author
Thanks for the response, but I actually was talking the generic case. I am dealing with polygon soup from a 3D modeler here :)
It's just that I was a bit confused about why even in this particular (almost trivial) case my simple sorting algorithms didn't work.
Luckily, the most common use of alpha belding is for modeling single-polygon (or two polygons when culling is off) windows and such. In that case, any simple depth sort does the trick.
It's just that I was a bit confused about why even in this particular (almost trivial) case my simple sorting algorithms didn't work.
Luckily, the most common use of alpha belding is for modeling single-polygon (or two polygons when culling is off) windows and such. In that case, any simple depth sort does the trick.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
