If you want correct per-pixel transparent objects with a non-additive blending
function, you could use the following multipass approach:
-create a texture D for depth and C for color, each the size of the frame buffer
-for each triangle run a fragment program which compares the depth value of
the current fragment with the corresponding depth in D, and blends the color of
the current fragment over the one in C or vice versa depending on the depth
comparison.
-render the new depth and color into D and C
This obviously is going to be very slow depending on availability of MRT, etc.,
but will always give you the correct result. There are of course many
optimizations you can make to avoid 1 pass/triangle:
-find groups of primitives which are guaranteed not to overlap in screen space.
If you are dealing with convex manifolds, none of the front faces will overlap
each-other, and none of the back faces will overlap each-other. You can also
group primitives from meshes whose projected bounding volumes don't
intersect.
-determine which groups of primitives intersect and only use the robust
approach while rasterizing these primitives
-etc.
Should result in relatively few passes (about 3 in Lorenzo's example)
-Keenan
---- Original message ----
>Date: Sun, 26 Dec 2004 00:51:59 +1300
>From: Keith Bauer <email@hidden>
>Subject: Re: Transparent objects
>To: Lorenzo <email@hidden>
>Cc: Mac List <email@hidden>
>
>there is no really good solution to this.
>
>to be absolutely perfect, you must draw each transparent pixel
>individually, applying the layers in furthest to nearest order.
>Clearly, this isn't practical.
>
>as a "next best" approximation, you draw each triangle in back to front
>order, splitting triangles that have ambiguous orderings relative to
>each other into three smaller triangles, BSP-style. This is probably
>still too complex.
>
>in the "probably OK" basket is sorting all the triangles back-to-front,
>then drawing them in order. There are still cases that can cause
>problems here, and the particular way you sort may or may not cause
>additional problems, but it should generally work pretty well.
>
>in the "really weird" basket is a technique called "depth peeling",
>which is an ugly hack to get order-independent transparency. Googling
>should turn up the paper. This probably isn't practical.
>
>-Keith
>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Mac-opengl mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>http://lists.apple.com/mailman/options/mac-opengl/email@hidden
>
>This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
