Hi, Joel This would not make any difference unless you have thousands of such nodes in graph.
Cheers. 10.01.2012, 11:06, "Joel Graff" <[email protected]>: > Hello, > > I've run into a little issue which could use some expert advice. I admit, I > may be over-thinking it... > > Anyway, in my OSG application, I've chosen to represent an application-level > "node" as several OSG nodes. At a minimum, an application node would consist > of an osg::Switch followed by an osg::Transform. Thus, the application > node's parents are the parents of the osg:Switch, and it's children are > children of the osg::Transform. > > To draw a picture: > > Application Node = osg::Switch ---> osg::Transform > > Really, what I'm doing is encapsulating the features of switches and > transforms into one node, so as to simplify the way it's represented in the > application. Essentially, I'm seeing the application node as an abstract > node with certain "modifiers" applied to it (e.g., a transform modifier, a > switch modifier, etc.) The modifiers are intended only to alter the state of > the application node's children. But that raises performance questions. For > example, if my application node consisted of a Switch / Transform pair, then > even if no transformations are ever applied to that node, the transform > node's matrix is (theoretically) still being multiplied into the frame's MVM > during the appropriate traversal. > > To rectify that, I had considered extending my application node structure > such that two osg::Group nodes would act as "book-ends" to my modifier nodes > - all nodes being linked in serial fashion, of course. That way, if the > application node is "enabled" and no transformations are applied, I can > remove my osg::Switch and osg::Transform nodes, reducing my application node > to two directly-linked osg::Groups. > > Another picture: > > Application node = osg::Group ---> osg::Switch ---> [other osg > state-modifying nodes] --- >osg::Transform ---> osg::Group > > This gives additional advantages, in that it becomes easier to manage several > different types of modifiers, should I wish to dynamically apply them, as > well as enabling multiple paths to the node's children. For example, suppose > I wish to render the node's children both with and without it's modifiers > (perhaps to compare an effect). > > The application isn't designed to create particularly large scene graphs, but > it is a shader development tool. I can't really guess at the effect of a > bloated structure, but I have the funny feeling it won't really matter. I > also don't really know how flexible I may want my application node to be, but > I see significant advantages to using the latter method and letting profiling > after the fact bear out the bottlenecks. > > I apologize if all of this is confusing, but are there any obvious caveats > I've overlooked in what I've proposed? > > Thanks, > > Joel > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=44723#44723 > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
