Hello all
I am wondering what is the efficient way to handle the 
transparency/translucency in a 3D engine.
I mean: if you load a full "level", there will certainly be different 3D 
elements (meshes) in the "level" with their own translucent/transparent 
elements. So do you need a "common function", called by the different 
load functions, that inventory all the translucent/transparent triangles 
and another function called at the end of the drawing loop to sort this 
triangles and draw them from back to front?
Thanks for your help
Cathy L.

On Tue, 22 Mar 2011 14:43:30 +0100
"Cathy L." <nob@now.fr> wrote:

> Hello all
> I am wondering what is the efficient way to handle the 
> transparency/translucency in a 3D engine.
> I mean: if you load a full "level", there will certainly be different
> 3D elements (meshes) in the "level" with their own
> translucent/transparent elements. So do you need a "common function",
> called by the different load functions, that inventory all the
> translucent/transparent triangles and another function called at the
> end of the drawing loop to sort this triangles and draw them from
> back to front? Thanks for your help
> Cathy L.

Normally you'll organize all your scene's assets in a scene graph, and
use some spatial subdivision structure (Octree, Kd-Tree, BSP, ...) to
relate them in space.

Using the right spatial subdivision structure it is trivial to traverse
the scene in any direction, from any starting point and to apply coarse
cullin,like not even attempting to draw stuff that's outside of the
viewing frame (frustum culling). Some structures (like BSP) even give
you pixel accurate information about what's visible and what's not, but
the overhead to create a BSP today is easily outweight by modern GPUs
overdrawing reserves.

In a modern 3D engine you follow a strategy along this outline:

1st: A near to far early Z only pass on all opaque meshes. Occlusion
     queries on bounding volumes are used to discard hidden geometry.
     Frustum culling omits traveral of parts of the geometry tree
     outside of the viewing range.

2nd: Material and Lighting sorted opaque pass, i.e. all geometry is
     sorted by the following precendence
         shaders -> textures -> near-to-far

3rd: Translucent sorted pass. First non overlapping subsets of
     translucent geometry are generated. Each of those subsets are
     sorted far-to-near. Then those parts are binned into
     order-preserving slices of common shader/texture combinations, to
     minimize shader/texture switches while still being able to draw
     far-to-near


The 2nd stage may be further subdivided if a deferred shading scheme is
used.


Wolfgang

Hello Wolfgang

Ok I'm not that sure of what I understand here, so if you agree I'm 
gonna translate it into something accurate but understandable by my 
limited skill:


> In a modern 3D engine you follow a strategy along this outline:
>
> 1st: A near to far early Z only pass on all opaque meshes. Occlusion
>       queries on bounding volumes are used to discard hidden geometry.
>       Frustum culling omits traveral of parts of the geometry tree
>       outside of the viewing range.

So you mean:
1/ Disable blending, texturing, colour buffer writing, but enable depth 
testing then render meshes from front to back (this last thing to reduce 
as much as you can writing to depth buffer) and only for meshes whose 
bounding box passed frustum culling.
Just to be sure, when you talk about opaque geometry, you also talk 
about Alpha Test geometry?
2/ Once done, you activate occlusion query and perform it with bounding 
boxes. The problem is that I heard that there is a stall due to the fact 
that when you perform occlusion query, you're not sure that the whole 
scene has been fully rendered. How about it?

> 2nd: Material and Lighting sorted opaque pass, i.e. all geometry is
>       sorted by the following precendence
>           shaders ->  textures ->  near-to-far

3/ I understand here that changing shading state is longer than changing 
texture state which is longer that writing to buffers. But I guess you 
perform this sorting only to the triangles, parts of the meshes that 
previously passed the occlusion test.
For a mesh, do you sort its triangles according shaders/textures at load 
time or you perform all that at runtime? This all seems to be so heavy, 
even for the CPU, when the scene has so many triangles. Do you use VBOs? 
In this case do you fill them according shaders->textures->near-to-far 
at runtime?

> 3rd: Translucent sorted pass. First non overlapping subsets of
>       translucent geometry are generated. Each of those subsets are
>       sorted far-to-near. Then those parts are binned into
>       order-preserving slices of common shader/texture combinations, to
>       minimize shader/texture switches while still being able to draw
>       far-to-near

Sorry the meaning of "non overlapping subsets of geometry" is not clear 
for me. However, if I got a little idea, I can't see how to perform it.
Once again that sounds to be quite heavy pre-computations that must be 
optimized to really improve, don't they?

> The 2nd stage may be further subdivided if a deferred shading scheme is
> used.

I keep it in mind but I am far far away from this kind of high graphics 
needs.

Thanks Wolfgang, when you are not sure of what you do, advice from 
skilled people reduce dramatically the lost of time for rewriting again 
and again the same part of code.

Cathy L.

On Tue, 22 Mar 2011 17:59:15 +0100
"Cathy L." <nob@now.fr> wrote:

> So you mean:
> 1/ Disable blending, texturing, colour buffer writing, but enable
> depth testing then render meshes from front to back (this last thing
> to reduce as much as you can writing to depth buffer) and only for
> meshes whose bounding box passed frustum culling.
> Just to be sure, when you talk about opaque geometry, you also talk 
> about Alpha Test geometry?
> 2/ Once done, you activate occlusion query and perform it with
> bounding boxes. The problem is that I heard that there is a stall due
> to the fact that when you perform occlusion query, you're not sure
> that the whole scene has been fully rendered. How about it?

Occlusion query is based on the idea to test if any fragment of a
primitive would be drawn at all. So you normally interleave the
writing early Z pass with occlusion queries in which the depth write is
disabled. The occlusion queries are performed on the hierachical
bounding volumes defines by the spatial subdivision.
 
> 3/ I understand here that changing shading state is longer than
> changing texture state which is longer that writing to buffers. But I
> guess you perform this sorting only to the triangles, parts of the
> meshes that previously passed the occlusion test.
> For a mesh, do you sort its triangles according shaders/textures at
> load time or you perform all that at runtime? This all seems to be so
> heavy, even for the CPU, when the scene has so many triangles. Do you
> use VBOs? In this case do you fill them according
> shaders->textures->near-to-far at runtime?

You normally only sort the whole objects based on their bounding
volume. Of course if you're going to draw an object with transparent
parts with multiple overlapping layers, then things get really
complicated. Your usual approach then is depth peeling. Another method
is breaking the meshes into convex submeshes, sorting those
back-to-front again, then render each sub-mesh two times: One time with
front faces being culled, then with backfaces being culled (in that
case such objects get assigned their very own spatial subdivision
structure).

> Sorry the meaning of "non overlapping subsets of geometry" is not
> clear for me. However, if I got a little idea, I can't see how to
> perform it. Once again that sounds to be quite heavy pre-computations
> that must be optimized to really improve, don't they?

The trick again is to exploit a good spatial subdivision structure
which will give you such information almost for free -- at the cost that
building this structure is computationally more expensive. Luckily
those structures need to be built only one time and also can be
stored/cached. In fact most realtime 3D engines of the 1990-ies stored
map geometry not as a mesh, but by a spatial subdivision, namely a so
called BSP (Binary Space Partition) tree -- the acceleration structure
was/is the geometry there.


Wolfgang

> You normally only sort the whole objects based on their bounding
> volume. Of course if you're going to draw an object with transparent
> parts with multiple overlapping layers, then things get really
> complicated. Your usual approach then is depth peeling. Another method
> is breaking the meshes into convex submeshes, sorting those
> back-to-front again, then render each sub-mesh two times: One time with
> front faces being culled, then with backfaces being culled (in that
> case such objects get assigned their very own spatial subdivision
> structure).

It wasn't about transparent elements, what I meant was that for a single 
mesh, you may use different shaders/textures, so inside each mesh you 
may have to sort shaders an textures, no?

On Mar 22, 3:12=A0pm, "Wolfgang.Draxinger"
<Wolfgang.Draxin...@physik.uni-muenchen.de> wrote:
>
> In a modern 3D engine you follow a strategy along this outline:
>
> 1st: A near to far early Z only pass on all opaque meshes.
>
> 2nd: Material and Lighting sorted opaque pass, i.e. all geometry is
> =A0 =A0 =A0sorted by the following precendence
> =A0 =A0 =A0 =A0 =A0shaders -> textures -> near-to-far
>

I thought "1st" was to void the need for "near-to-far"...

On Wed, 23 Mar 2011 06:28:52 -0700 (PDT)
fungus <openglMYSOCKS@artlum.com> wrote:

> I thought "1st" was to void the need for "near-to-far"...

Yes of course, but due to the 1st pass one already has things sorted
front to back; the shader and texture sort stage operate on the
presorted structure, which will result in this precedence.


Wolfgang