Robert Osfield wrote:

>StateSet::setRenderingHint is merly a convenience function for setting
>the bin number and bin name it has no function beyond this.
>  
>
Just chiming in here: it seems the sort-order of a renderbin is 
determined by its name. This has always bothered me a bit, as it gives 
the impression that you can assign any name, while there are only 2 
valid ones. Would it be an option to change this to a simple "sort_mode" 
variable whose value comes from an enum { SortByState, SortByDepth, ...} ?

Paul

>On 10/4/07, Christophe Medard <[EMAIL PROTECTED]> wrote:
>  
>
>>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]                  |
>>
>>             |
>>                                                                        
>> -----------------------
>>                                                                        |
>>|
>>                                                             osg::Drawable
>>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
>>                   |
>>                   ------------------------------------------
>>                   |                         |
>>|
>>                   |              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" <[EMAIL PROTECTED]>
>>To: "OpenSceneGraph Users" <osg-users@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
>>>
>>>      
>>>
>>_______________________________________________
>>osg-users mailing list
>>osg-users@lists.openscenegraph.org
>>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>    
>>
>_______________________________________________
>osg-users mailing list
>osg-users@lists.openscenegraph.org
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>  
>

_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to