[osg-users] RenderingHint vs binNumber(RenderBinDetails)

Christophe Medard christophe.medard at oktal.fr
Thu Oct 4 06:02:12 PDT 2007

To react to what says Robert, I'm under the impression that renderingHint in 
fact isn't used internally, is it ?
Why is there two informations in fact redundant (an order of draw), 
renderingHint and binNumber ?

So if I'm correct, things must only be thought of in 'binNumber' terms.
To react to what says Tim, I'm passing through stateset on group nodes 
indeed, but I'm not sure to perfecly understand well what you're saying.
Let's take a over simple example, if I have the following three, what will 
be the order of draw ?

                                         osg::Group "A" 
osg::Group "B"
                                        [binNumber = 8] 
dft, so binNumber = 0
                  |                                 | 
        osg::Geode "C"             osg::Geode "D"             osg::Geode "E"
        [binNumber = 5]           [binNumber = 1]                  |
E0         osg::Drawable E1
                                                         dft, so binNumber = 
0        [binNumber = 6]

Is it   B/E0 - D - C - A - E1 ?

Another example, closer to my current purpose test, practical to make multi 
pass drawings :

                   |                         | 
                   |              osg::Group "B"             osg::Group "C"
                   |               [binNumber = 20]        [binNumber = 30]
          osg::Geode "A"
         [binNumber = 15]

Is it A - B - C ?

I think exploring a concrete example like that clear things. Thanks

----- Original Message ----- 
From: "Tim Moore" <timoore at redhat.com>
To: "OpenSceneGraph Users" <osg-users at lists.openscenegraph.org>
Sent: Thursday, October 04, 2007 2:00 PM
Subject: Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails)

> Robert didn't answer your second question; I'll have a go because I think 
> I understand
> it.
> First of all, there aren't a fixed number of render bins. You can assign a 
> StateSet
> to any integer, positive or negative. This turns out to be quite useful.
> When you say "set a rendering order on a group node," you mean that you've 
> set the
> render bin in a state set in that node. There is an inheritance effect, 
> but it may
> not be what you expect. Render bins can contain other render bins! If the 
> children of
> your group node have state sets that also set the render bin detail, their 
> render bins
> are stored inside the group state set's render bin, and they will be 
> rendered in order
> when that render bin is traversed.
> This can give you unexpected results, when for example you assign a state 
> sets with
> TRANSPARENT_BIN or OPAQUE_BIN to nodes up and down the scene graph :) On 
> the other
> hand you can get very precise control of the ordering of drawables with 
> it. In
> FlightGear I just used this feature to order cloud layers. The layers are 
> too big for
> normal transparency sorting to work well, and you want to draw the cloud 
> layer tops
> from low altitude to high and the bottoms from high to low. I used the 
> altitudes
> of the layers as render bin numbers to get the right order:
>  // Force the cloud layers into recursive bins of bin 4.
>  osg::StateSet *rootSet = layer_root->getOrCreateStateSet();
>  rootSet->setRenderBinDetails(4, "RenderBin");
> Child 0 has the bottom layers and child 1 has the tops:
> layer_root->getChild(0)->getStateSet()->setRenderBinDetails(-(int)layer_asl,
> "RenderBin");
> layer_root->getChild(1)->getStateSet()->setRenderBinDetails((int)layer_asl,
> "RenderBin");
> I hope someone will correct me if I've gotten this all wrong!
> Tim

More information about the osg-users mailing list