Hi Paul,

On 4/13/07, Paul Martz <[EMAIL PROTECTED]> wrote:
Hi Robert --  If I understand correctly, bin 0 is the default bin, typically
for opaque geometry, and bin 10 is typically for non-opaque geometry. Bin
numbers 1-9 are available for application-specific tasks, and RenderBins are
processed by the draw traversal in ascending order.

The bin number is an int, and an std::map<int,RenderBin> is used to
store the nested bins so you can have any int number you wish,
negative included.

I'm creating a NodeKit that requires a separate RenderBin. Ideally, this
should render before bin 10. So, for example, I could hard-code bin number 9
for my special-purpose bin. What happens if the end-user application (or
some other NodeKit) is already using bin number 9? Does the draw traversal
processing order become indeterminate?

Right now 10 is the default transparent bin.  If the bin number
matches then it'll be the same bin is used and the rest of the render
bin details will be ignored.  The first of the RenderBin details
encounterd during traversal is the one that takes precedence.

My question could be more generally phrased as: "how can separate code
modules be aware of what bin numbers are already in use to avoid these kinds
of conflicts?"

You'd have to use a custom cull callback or pre processing to do this.

The OSG does allow you to nest RenderBin's so you can actually
encapsulate the RenderBin's  entirely.

Also, it turns out I'm deriving a new class from RenderBin. I couldn't find
any example code that does this, so I'm treading new territory. Any tips you
could share on deriving new RenderBins would be appreciated. Potential
gotchas, etc.

RenderStage is a subclass from RenderBin too.   W.r.t tips, this is
hard, its so open ended, I'd really need to understand what you are
trying to achieve to advise.

Robert.
_______________________________________________
osg-users mailing list
[EMAIL PROTECTED]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to