-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Martz wrote: | Hi Robert -- The bin mode parameter of setRenderBinDetails doesn't appear to | be clearly documented. Looking into it, it's somewhat confusing. I'm hoping | you can tell me what affect one should expect when setting one of | INHERIT_RENDERBIN_DETAILS (default), USE_RENDERBIN_DETAILS, or | OVERRIDE_RENDERBIN_DETAILS. | | As near as I can tell, these only have an effect on the state graph | constructed by the CullVisitor. Perhaps it'd be useful if you could | elaborate on the state graph and how these values control it? | | In my own tinkering, I've found that INHERIT_RENDERBIN_DETAILS produces a | nested processing order, as we've discussed previously on this list. Three | nodes with bin numbers 1, 2, and 3, with the Node using bin 2 having two | children, and the two children use bin number 0 and 5 (or, graphically:) | Root (bin details unspecified) Group with 3 children | NodeA (bin# 1) | NodeB (bin# 2) Group with 2 children | NodeBsub0 (bin# 0) | NodeBsub1 (bin# 4) | NodeC (bin# 3) | | With INHERIT, I get the following render order: NodeA, NodeBsub0, NodeBsub1, | NodeC. NodeBsub0 and NodeBsub1 inherit their parent's bin number for | processing relative to the parent's siblings. This makes sense, and I can | document it. If all these nodes' state sets use INHERIT, then the bin numbers have no effect on the the rendering order, as I understand it. The order you are seeing looks like what you'd get with an in-order traversal of the tree. | | If I set all nodes to USE, the render order is the same as INHERIT.
In this case, sure: the bins for NodeA, NodeB and NodeC's state sets are arranged in that order in the root render bin, with NodeBsub0 and NodeBsub1 in order in NodeB's bin. | However, I do get interesting results if I set all nodes to USE _except_ for | NodeB, which I leave as INHERIT. In this scenario, render bin numbers appear | to specify absolutely rendering order: NodeBsub0, NodeA, NodeC, NodeBsub1. That's because the bins established by the state sets with USE are all arranged, in numeric order, in the root's render bin. | | I've yet to find a use for OVERRIDE. | | Any light you can shed would be appreciated. The code is not clear. USE establishes a current render bin and gives it an order relative to other render bins and drawables in the parent render bin. The parent render bin is the previous current render bin. INHERIT doesn't change anything and has no effect on the draw order. OVERRIDE is like USE, except it disables the creation of new render bins in the nodes under state set's node. Stare hard at CullVisitor::pushStateSet :) Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhpiSeDhWHdXrDRURAo+CAKCZJffXK/PuTwD5L3CA3k673RvNiQCgp0YT JJym39EMPfVK5/sbM0u34UM= =Yshf -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
