[osg-users] RenderingHint vs binNumber(RenderBinDetails)

Tim Moore timoore at redhat.com
Thu Oct 4 05:00:13 PDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Osfield wrote:
> Hi Christophe,
> 
> The definitive answer comes from the source:
...
> 
> Which shows that setting rendering bin number *and* bin name is
> equivalent, but not bin number alone.
> 
> Robert.
> 
> On 10/4/07, Christophe Medard <christophe.medard at oktal.fr> wrote:
>>
>> Hi all,
>>
>> There's something I can't get a clear vision of despite my efforts.
...
>> - there seems to be no notion of inheritance (like there is on a
>> stateattribute typically) for those renderhint or renderbindetail features :
>> if you set a rendering order (through one or the other feature) on a group
>> node, does that rendering order affect the whole subgraph (understand
>> children and children of children) ? What happens if a renderhint or
>> renderdindetail is set again on one child ?

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHBNXNeDhWHdXrDRURAt9NAJ4kiuDzr0ZFCj7iATsgs+1J0aQHjwCfUzqc
9A/Otv/kDQZCBcdR7VPozqg=
=eU+I
-----END PGP SIGNATURE-----



More information about the osg-users mailing list