Re: [osg-users] Scene graph structure vs. performance question
On 01/10/2012 02:06 AM, Joel Graff wrote: 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 think you're right. For your use case, I don't think a few nodes that are technically redundant will matter all that much. You can always streamline later if it becomes a problem, but I doubt you'll need to. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene graph structure vs. performance question
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" : > 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 > 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] Scene graph structure vs. performance question
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
