Well, the OpenGL RedBook chapter 6 "Blending, Antialiasing, Fog, and
Polygon Offset" says in sub-chapter "Three-Dimensional Blending with
the Depth Buffer" :
>> If you want to render both opaque and translucent objects in the
same scene [..] The solution is to enable depth buffering but make the
depth buffer read-only while drawing the translucent objects. First
you draw all the opaque objects, with the depth buffer in normal
operation. Then you preserve these depth values by making the depth
buffer read-only. When the translucent objects are drawn, their depth
values are still compared to the values established by the opaque
objects, so they aren't drawn if they're behind the opaque ones. If
they're closer to the viewpoint, however, they don't eliminate the
opaque objects, since the depth-buffer values can't change. Instead,
they're blended with the opaque objects. [..] <<

This sounds and is pretty logical. Still, I've got two questions. In
the following with "3d object" I mean a 3d model, like a car or so.
With "surface" I mean a triangle (polygon with 3 vertices). With first
pass I mean the above mentioned "just paint opaque objects" and with
second pass the above mentioned "paint all translucent objects."

Q1.) Some of my 3d objects have got a few opaque and a few translucent
surfaces; lets call them "mixed objects" - compared to pure opaque
objects and pure translucent objects.
So, is it neccessary to draw all the opaque surfaces of the mixed
objects in the first pass, and in the second pass draw all the
translucent surfaces of the mixed objects and also the pure
translucent objects...?
But then when I draw such a translucent object, I've to sort its
surfaces too, because their drawing order does matter...?

Q2.) How to sort the translucent (and mixed) objects in the fastest
way, in order to paint them from back to front? Maybe it's not
neccessary to calulate any projection, so that, for example, the
distance of the center of an 3d object to the camera position could do
the job?
And what's the best method to sort the surfaces of an translucent
object? Also "just" the distance to the camera position?

Thanks for any hints.

-ric

> Q1.) Some of my 3d objects have got a few opaque and a few translucent
> surfaces; lets call them "mixed objects" - compared to pure opaque
> objects and pure translucent objects.
> So, is it neccessary to draw all the opaque surfaces of the mixed
> objects in the first pass, and in the second pass draw all the
> translucent surfaces of the mixed objects and also the pure
> translucent objects...?

As a first note, nothing is really "necessary". It just won't look right
in some situations.
But anwsering to your questions : yes it's better if you split your "mixed
objects" in "opaque" and "translucent" parts.

> But then when I draw such a translucent object, I've to sort its
> surfaces too, because their drawing order does matter...?

yes of course.


> Q2.) How to sort the translucent (and mixed) objects in the fastest
> way, in order to paint them from back to front? Maybe it's not
> neccessary to calulate any projection, so that, for example, the
> distance of the center of an 3d object to the camera position could do
> the job?
> And what's the best method to sort the surfaces of an translucent
> object? Also "just" the distance to the camera position?

That's a wide discussion. There is no ideal solution. It simply depends on
the performance/quality you expect, and maybe the hardware you're at.
As to answer generally, there are 3 types of depth sorting :
1- sort by object (the translucent vase is in front of the window),
2- sort by primitive (each triangle of the vase is sorted),
3- sort by pixel (each rasterized pixel of the vase is sorted).

It is common to say that 1 is faster than 2 which is faster than 3, but 3
is better quality than 2 which is better quality than 1.

When you represent an object (or a triangle) as a point in your distance
computation, it is naturally subject to error. Hopefully, in most
situations the errors generated by such approximation is rarely noticed,
if noticed.

Anyway, it always depends on your application : do you have lots of
translucent objects, namely lots of translucent triangles ? do they
intersect each other ? does the camera look close at them ? do you look
for quality or performance (are your frames rendered in real-time ? etc.

Vincent

Richard Ivarson wrote:

> >> And what's the best method to sort the surfaces of an translucent
> >> object? Also "just" the distance to the camera position?
>
> > When you represent an object (or a triangle) as a point in your distance
> > computation, it is naturally subject to error. Hopefully, in most
> > situations the errors generated by such approximation is rarely noticed,
> > if noticed.
>
> Well, these rare errors shouldn't matter in my application (please see
> below).

Why ? I'm not sure to get the point.


> To compute the order of paint the translucent surfaces of an 3d-object
> I've to take the object's translation/rotation into account. :)

Obviously :)


> Probably it's a good idea to let OpenGL do this, for example similar
> to the frustum culling in the nice tutorial
> http://www.markmorley.com/opengl/frustumculling.html

Uh, this article explains how bypass OpenGL and do it yourself, no to "let OpenGL do this"
!
So, I'm confused again.


> Instead of the six viewing frustum planes, one (the back plane) should
> be enough for my application. Then I could test the translucent
> surface's "z-center" (average of its vertices' z-values) against that
> plane to see which surface is nearer.

Yes it will test the distance, but it's not a perfect method. In fact, it will work if you
can ensure that the objects' bounding volumes do never intersect.


> > Anyway, it always depends on your application : do you have lots of
> > translucent objects, namely lots of translucent triangles ? do they
> > intersect each other ? does the camera look close at them ? do you look
> > for quality or performance (are your frames rendered in real-time ? etc.
>
> It's an animated test application in real time; a few hundred
> 3d-objects moving around, approx 50% of them being translucent and in
> total maybe 50 000 polygons.

Ok, then the most important questions are : do the objects often overlap, and when it
happens do they overlap over a surface that is largely covered on the screen, and are those
overalpping objects subject to interesction or "near-intersection" (that is, they do not
intersect but are close to enough to let fail the sorting algorithm) ?

Vincent