Alpha transparency problems

Hi,
This is quite a common problem. Solutions are as follows:

1) Draw solid objects first ( fornt to back order usually, but not required )
2) Draw all objects with alpha texture/verts in back to fromt order.

3) You may want to disable z writes to stop intersecting polys from blocking each other. ie 2 panes of glass intersecting.
4) Some objects that need self sorting need z write enabled. To stop "Frizzy Edges", try enabling alpha test and increasing the alpha reference value ( SetRenderState(...) ), this will set the Z writes cutoff point for a given alphs value. The result will be a "Sharper" edge to you leaf, you will have to play around with the alpha ref to get a result you desire.

5) Or sort the polys for a mesh into back to front order and draw them. This may cause a performance hit, depending how you send the sorted triangles to DX. ( search for dynamic buffer locking and perfomrnace etc )


I personally use 1-4, and an alpha ref of 1, and 180 for things that I want to have a sharp edge with.

Ouch. There goes my performance!

Man does this alpha thing suck.

6) Break the troublesome object into multiple convex sections and sort those sections with respect to the view vector.


7) It''s actually very uncommon you''ll really need to go down to per-poly level provided what you render is convex and doesn''t intersect any other translucent objects.


8) You can also do some nice **approximations** which are passable in almost all cases. For example:

a. have multiple sets of index buffers for each object, say 6

b. as an offline/load process, sort those index buffers in perfect Z order from 6 different directions, say the directions of the each of the faces of an axis aligned cube

c. when you come to render, quantize the view direction vector to find which of the 6 directions it''s most similar to (remember that the directions become faces of an OBB oriented in the same way as the model).

d. Simply use the index buffer representing that direction.


9) If 6 directions isn''t enough, use more on a per model basis.


10) Remember that cameras usually move over quite a few frames, so do objects. The Z sort order on frame N+10 is quite likely to be very *similar* to the Z sort order on frame N.
If you know what the camera is going to be doing or if it will be constrained in any way you can use that to your advantage for example (method off the top of my head):

a. if the the camera (true) up direction were always very close to 0,1,0, you could pre-sort the indices into a cylindrical pattern where the top and bottom circles of the cylinder were in the XZ plane. Faces of the object would go into the cylinder in slices/segments so that the higher indices of a particular segment were on the outside of the (imaginary) cylinder and the lower indices were on the inside (going towards the centre).

b. then you use a single *dynamic* index buffer and keep a list of the start index of each segment of the cylinder (imagine the cylinder were like a cake which had been sliced).

c. to fill the dynamic index buffer you find which slice of your cake faces the view vector, then since you know where each segment/slice starts, you can copy the indices out in *sorted* order.

d. voila - Z sorting for the cost of a few memory copies.




--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

OK, that makes it a lot faster, but also a lot more complex. How could you, for instance, handle a situation where a mesh is placed inside another mesh that has a semi-transparent surface?

At the moment I am sorting my meshes according to their center point, which is very fast. For something like that I would have to sort according to their BB, which is a lot slower because I now have to deal with 4 co-ordinates (minimum).

And even for very simple quads that display a grass texture with semi-transparent bits... Ideally I''d like to be able to just paint the grass wherever in the map editor, but when there are intersections, the whole thing gets snafu''d. So now I''ve effectively got to either train the map creators to not draw overlaps, OR I''ve got to build additional collision detection logic that disallows it completely.

This is very frustrating. I can''t imagine it being particularly difficult to include an "I am Transparent" bit in the rendering pipeline so that subsequent renders to deeper z positions still show up. Maybe in some future release of DirectX, eh?

Oh well, thanks for all the help. I''m off to write huge chunks of code... :-)