Re: [osg-users] Best Practices and Switches
Hi David, On Tue, 30 Apr 2019 at 20:52, David Heitbrink wrote: > In general my CPU load is pretty good, what I am really concerned about is > reducing the number of OpenGL calls/driver overhead. If I have 200 signs all > under there own switch, each sign is only 4-64 triangles each, and all the > signs share the same texture mosaic. Having 200 unique drawls can get > expensive, especially for such a low poly objects. Ideally the 200 street > signs would get combined in the same draw object. My assumption was this > cannot happen with each sign being under its own switch. Yes, you can't combine geometries and have primitives within them controlled by a switch node. > My second question is 2 part, if I remove the switches, would I want to then > export the result to a file and reload the file run, then run the optimizer. > Or would the performance of the optimizer be all the same if I ran it on a > graph that I had just programmatically removed the switches from. I am > basically concerned with running into "nodeWeCannotRemove". > > Also, the second part is..what criteria does the MERGE_GEOMETRY option > use to merge geometry. It's long enough ago that I worked on this area that I can't recall off the top of my head. The only way for me to answer definitively it would be to review the code, which you can also do :-) As a general note, the osgUtil::Optimizer classes attempt to fix issues that commonly appear in loaded scenes, it's not perfect, or even the best optimization that you can do, it's an imperfect scheme for fixing even less perfect databases. Think of the Optimizer as trying to catch and tame a horse that has already bolted from the stable. It's far better to build efficient scene graphs from the start and not use the Optimzer at all. For your particular usage case it may be best to write your own classes to analyze the scene graph and decide what to do about them. It might even be that you'd want to write a custom osg::Drawable, or subclass from osg::Geometry to implement a scheme where all the signs are in a single custom Drawable/Geometry object which has a renders each sign as a separate PrimitiveSet (which represents a quad) then in the drawImplementation() you step through the PrimitiveSet deciding which ones to dispatch to OpenGL or not. Such as scheme would be lighter weight than having lots of switches and separate geometries. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Best Practices and Switches
Thank you for your reply. In general my CPU load is pretty good, what I am really concerned about is reducing the number of OpenGL calls/driver overhead. If I have 200 signs all under there own switch, each sign is only 4-64 triangles each, and all the signs share the same texture mosaic. Having 200 unique drawls can get expensive, especially for such a low poly objects. Ideally the 200 street signs would get combined in the same draw object. My assumption was this cannot happen with each sign being under its own switch. My second question is 2 part, if I remove the switches, would I want to then export the result to a file and reload the file run, then run the optimizer. Or would the performance of the optimizer be all the same if I ran it on a graph that I had just programmatically removed the switches from. I am basically concerned with running into "nodeWeCannotRemove". Also, the second part is..what criteria does the MERGE_GEOMETRY option use to merge geometry. For example lets say I wanted to go a step further, and remove the textures from the state sets, and add an attribute for a texture index for each vertex. Then I could say use a texture array or bindless texture in the shader to reference the texture to use. We should be able to start combining nodes with dissimilar textures. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75924#75924 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Best Practices and Switches
Hi David, On Tue, 30 Apr 2019 at 17:38, David Heitbrink wrote: > I have some scenes with tons of osgSim::MultiSwitch's, I think for some of my > scenes it can be in the low 1000s. For a scene these are typically setup > once, and then rarely changed. From what I understand a lot of the optimize > operations do not work across switches, which makes sense, I would think it > would be hard to merge geometry with something that can change. > > Since these switches rarely change, I was thinking about loading my switch > options from a file, then just removing the switches, and attaching the > selected child of the multi-switch to its parent. In general is this a solid > approach, or is just setting "DataVariance" to static for the switch good > enough? > > Typically the object size under these switches are pretty small. Often times > they are just 4 triangles. Having 1000's of Switch nodes can create a CPU load that ideally is only somethng you'd want to pay for if you are actively using them as Switches. If the Switches just get to one state and for the rest of the applications life remain the same then just replacing them with the subgraph that is enabled should provide a performance gain. Another alternative would be to use the osg::Node::setNodeMask(uint mask) instead of a Switch. It doesn't have exactly the same functionality as the switch but can be close enough for many tasks and as all nodes have a NodeMask and they are always checked during traversal you don't pay any extra cost in using the NodeMask as a switch. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Best Practices and Switches
I have some scenes with tons of osgSim::MultiSwitch's, I think for some of my scenes it can be in the low 1000s. For a scene these are typically setup once, and then rarely changed. From what I understand a lot of the optimize operations do not work across switches, which makes sense, I would think it would be hard to merge geometry with something that can change. Since these switches rarely change, I was thinking about loading my switch options from a file, then just removing the switches, and attaching the selected child of the multi-switch to its parent. In general is this a solid approach, or is just setting "DataVariance" to static for the switch good enough? Typically the object size under these switches are pretty small. Often times they are just 4 triangles. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75921#75921 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
