> From: [EMAIL PROTECTED] [mailto:osg-users-
> Sent: Wednesday, August 01, 2007 7:49 PM
> To: [email protected]
> Subject: [osg-users] Controlling render order in subgraph
>
> Hey Everyone,
>
> I saw a recent post on these boards asking how to control render order
for huds using render bins,
> and I was curious if the same can be done for general subgraphs in a
larger scene.
>
> I'm placing a sign into my scene using a Billboard with some
drawables. The sign should behave
> like it's a 2D desktop that I can organize flat drawables on. Right
now I'm changing depth values
> for each drawable to control which one is drawn first. For instance,
I set the text one unit
> closer to the eye than the backboard. This works alright, but there
is z-fighting when the sign
> is far away.
>
> Could I achieve the same prioritization using render bins? My
intuition says that render bins
> won't help because all graphics objects are treated equally once
pushed down the GL pipeline.
> However, I'm not positive, and I thought asking might help, or perhaps
there is an even better way
> to handle this :-)
>
> Thanks for any advice,
>
> Chase
>
I'm afraid I don't have OSG code for this, but
here's something I've done in the past that
worked pretty well.
You need a group node for all of the 2D objects.
On this node you add a Depth attribute with the
WriteMask set to false, but leave the Function
at your default. You also add a Stencil attribute,
setting Function to ALWAYS, the operation to REPLACE,
and the FunctionRef to 1. Now draw the 2D items.
After this, you need one more object that draws
a big quad in the same plane. For this one, you
add a Depth attribute with the WriteMask set to
true and the Function set to ALWAYS. You also
add a Stencil attribute with the Function set
to EQUAL and the FunctionRef at 1. Finally, on
this node you add a ColorMask set to false,
false, false, false.
There's probably a typo in there somewhere,
but here's what happens. When we draw the
2D nodes that are parented to that group,
they will honor the Z values that earlier
nodes have written, but they won't modify
the zbuffer. Instead they'll set a bit in
the stencil plane. Next we'll draw the
quad. This will write Z values but no
colors, and it will only do it where that
stencil bit was set. This will leave the
zbuffer as it would have been if the 2D
nodes had been writing Z's.
The problem I've had with this in practice
is that a few cards/drivers have problems with
the colormask=false,false,false,false step.
To really get every card in the world to
stop writing colors you often need to do a
belt-and-suspenders (what's that in English-
English? Is belt-and-braces a real expression?)
thing and also set LogicOp to NOOP, and
everything else you can think of to get the
card to listen to you. But this will probably
knock you out of the fastpath. The good news
is that cards with these problems seem to have
gotten pretty obscure at this point. If you
don't need to worry about them, then this
technique works pretty well.
-MPG-
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
