views:

86

answers:

2

I'm building a small 3D engine for a game I'm working on. I've got my basics sorted: textured triangles with backface culling. However depth sorting is proving to be a difficult problem.

I'm calculating the face Z by averaging out the 3 points that make up the triangular face. The longer faces sometimes overlap the smaller faces since they have a larger Z value and therefore rise up in the depth sorted display list.

How do I fix this? I'm sure there are known depth sorting techniques if I can only get some practical help in programming them. I've build the render pipeline myself so I have access to all the required data - triangles, points, textures, UV coordinates, etc.

Cathedral rendered in a 3D program

alt text

Cathedral rendered in my 3D engine

alt text

+3  A: 

You choices are either to:

  1. Subdivide your meshes so that you can sort each polygon reliably (but there are still horrible edge cases that you may or may not see).

  2. Use a Z-Buffer, which is supported by all graphics hardware and is essentially free.

Justicle
+1  A: 

You need to subdivide your triangles so that they are all roughly the same size - regardless of whether you do the sorting yourself or employ a z-buffer. Unless, of course, the z-buffer algorithm also splits the long thin triangles up for you.

The problem is that if you've got some small compact triangles and some long thin ones (for example) it algorithm will miss classify the long thin ones more often than not. If you use the mid point of the triangle there will be view points where it will be regarded as "in front" of a more compact one when in fact if really is behind. Take this top down view where + represents the mid point.

            o

-+-            1
-----+------   2
         -+-   3

*

Looking from * to o the large triangle (2) could be interpreted as being in front of the small triangle (3) and hence be drawn on top of it.

If (2) was split into 3 or 4 smaller triangles then the z-buffering would work more of the time.

ChrisF
Is there any way I can bias the Z-sorting routine to take the triangle area into account, without having to split tris?
Jenko
@ChrisF Incorrect. This is exactly the problem that Z-buffering solves. Z-buffering is per pixel and is independent of polygon size (it happens to far down the pipeline to even know). The problem you describe is only applicable to polygon sorting, or if you're rendering non-opaque polygons. Precision issues are relevant to z-buffering and there's a good intro here: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
Justicle