Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
Here is my repro case for the 1 children of a switch node causing massive cull times. Tried this piece of code on Linux with osg 3.1.1 developer release. I do not observe any high cull times here, even when drastically increasing the number of children of the switch node. Too bad, my intention was to do code profiling to get to the bottom of this. So either osg 3.1 fixes this, or some implementation detail is more efficient on Linux than it is on Windows. I would have profiled on Windows, except the Visual Studio versions with this feature cost a fortune (you can purchase a car for that price). Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
Am 07.03.2012 13:22, schrieb Christian Buchner: However, the computeBounds will check every node, thus recomputing the bounds if a children is changed, so every child has to be touched (not saying that all of them have to recompute their bounds). So you're essentially saying by imlementing a subclass of osg::Switch() and overloading computeBounds() to only look at active children I would be able to fix the performance issues? I shall try, that is easy enough. ;) That could be an option as far a I saw. But I don't think there is much benefit. Essentially the computeBounds is called recursively for each node, that states a dirty bound. So you would maybe save on virtual call per child that is not changed, but you'd have to manage changes on the children on your own. In my opinion the benefits wouldn't outweigh the efforts, as the recursive traversal here is the only way to hide the information at the child level. A more interesting fact that I was thinking about and which might improve your performance is to organize your graph in a different way. Instead of putting all childs under one big switch I'd rather split them up to switch groups of less heavy size. I'm not sure (because I never measured) but I guess that with vectors ~1 elements large things like cache coherency and stuff might start to play a bigger role. But as said before, anything but measuring (using a profiler or at least doing some high res. time queries inside the code) is wild guessing, and as you have the OSG source code you are totally free to check where the bottlenecks are. cheers Sebastian Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
I found that an osg::Switch object will still have all its children run through the cull traversal. So we migrated away from osg::Switch to conditionally display thousands of child nodes. Node masks could be a better solution for what you are trying to achieve. This will at least get rid of the bad cull performance. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
HI Christian, On 6 March 2012 11:07, Christian Buchner christian.buch...@gmail.com wrote: I found that an osg::Switch object will still have all its children run through the cull traversal. So we migrated away from osg::Switch to conditionally display thousands of child nodes. A rather curious statement. If a switch node switches off a child it won't traverse it in the update and cull traversals. It does however have to test each child to see if it's switched off or not, which is an O(n) operator where n is the number of children of the switch. If you just want to switch on one child out of thosuands then osg::Switch will be relatively expensive. For this type of switch a custom node would be best, osg::Switch is designed primarily for flexibility rather than serving a niche task of optimizing for massive switching between thousands of children. Node masks could be a better solution for what you are trying to achieve. This will at least get rid of the bad cull performance. Using NodeMask will be worse for performance as the osg::Switch testing will be done prior to checking the child itself so less memory will need to be checked and less virtual functions needed to be called. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
We had 1 children in an osg::Switch, all osgText::Text objects (which themselves were children of a PositionAttitudeTransform object). Nearly all of them were disabled in the parent osg::Switch. The culling pass would take forever (especially noticeable in debug builds of the software). Besides this observation, these osg::Text objects had huge runtime memory requirements, so we had to refactor the code so that we dynamically add these objects to the scene graph as needed. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
Here is my repro case for the 1 children of a switch node causing
massive cull times.
Just enable the stats with the 's' key. Even though most children are
turned off, they seem to be processed in the cull traversal - the
culling dominates the render time.
I do not understand enough of OpenSceneGraph to exactly pinpoint the
cause, maybe Robert can shed a bit of light as to what is going on.
Christian
/* OpenSceneGraph example, osgminimalglsl.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
/* file:examples/osgrepro.cpp
*
* Showing why it's a bad idea to put 1 children into an osg::Switch
* observe the culling times!!!
*/
#include osg/ArgumentParser
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/Switch
#include osg/PositionAttitudeTransform
#include osg/Drawable
#include osgText/Text
using namespace osg;
int main(int argc, char **argv)
{
osg::ArgumentParser arg(argc, argv);
// construct the viewer.
osgViewer::Viewer viewer(arg);
// use a geode with a Box ShapeDrawable
osg::Switch* sw = new osg::Switch();
for (int y=0; y100; ++y)
{
for (int x=0; x100; ++x)
{
osg::PositionAttitudeTransform *pat = new osg::PositionAttitudeTransform();
pat-setPosition(osg::Vec3(10*x,10*y,0));
osg::Geode *geode = new osg::Geode();
osgText::Text *text = new osgText::Text();
text-setText(foo);
text-setAlignment(osgText::TextBase::CENTER_BOTTOM);
text-setAutoRotateToScreen(true);
text-setDataVariance(osg::Object::DYNAMIC);
geode-addDrawable(text);
pat-addChild(geode);
sw-addChild(pat);
// turn on only a small subset of childs
sw-setChildValue(pat, rand() % 100 == 0);
}
}
viewer.addEventHandler(new osgViewer::StatsHandler);
// run the osg::Viewer using our model
viewer.setSceneData( sw );
return viewer.run();
}
/*EOF*/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
Hello Christian, Don't forget that the cull traversal also collects all the draw-calls /objects to be rendered. So cull should better be called cullcollect. Also from your example: You're creating one individual node per switch children. This means the scenegraph is not able to share any geometry etc. at this level. You could try to change your example to use the same text-node over and over as child and performance should grow. Besides, try to cut down the individual transforms if possible or set them to static data variance and possibly run an optimizer over the scene. cheers Sebastian Here is my repro case for the 1 children of a switch node causing massive cull times. Just enable the stats with the 's' key. Even though most children are turned off, they seem to be processed in the cull traversal - the culling dominates the render time. I do not understand enough of OpenSceneGraph to exactly pinpoint the cause, maybe Robert can shed a bit of light as to what is going on. Christian ___ 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
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
Am 06.03.2012 20:05, schrieb Sebastian Messerschmidt: Am 06.03.2012 19:34, schrieb Christian Buchner: well in our production code each text node would show an individual text (some radio related parameters). The thing is: the cull traversal should not even be looking at objects in the osg::Switch that are turned off. I've checked in the source: If the visitor (in this case cullvisitor) is set to TRAVERSE_ACTIVE_CHILDREN it will only traverse those nodes which are active. The cull visitor takes exactly this settings, so it won't traverse non active children. However, the computeBounds will check every node, thus recomputing the bounds if a children is changed, so every child has to be touched (not saying that all of them have to recompute their bounds). So I can't quite support your statement. Why don't you experiment with the count of active children in your example? Given your theory the cull time should not increase linearly with increasing number of nodes. Besides, try to cut down the individual transforms if possible or set them to static data variance and possibly run an optimizer over the scene. Same here, the positions of my texts would be dynamically updated each frame. But only a few texts would be needed at any given time. All is good now because we dumped osg::Switch. How did you organize it then? One question that arose is : Do you have to display all the active children at a time? Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Performance question: Switch / NodeMask / WriteToFile
Hello everyone, I'm experiencing performance problems with my osg scene. I have many (up to 100k) geometries to display a tree. I'm building my whole scene graph at the beginning. To view it only partially I inserted root - group - PositionAttitudeTransform - Switch - (a/b) (a) LOD - Geode - Geometry or LOD - BillBoard - Geometry (b) Geode - Geometry Now when the scene is only partially visible (using osg::Switch), it's laggy nonetheless. If I wanted to load and save my scene on demand, what would be the best possibility (in regards of performance) 1) write unneeded subgraphs to a file 2) cache unneeded subgraphs (how would I do this?) 3) use NodeMask on osg::Group (would this also black out the respective subgraph?) Looking forward for input. Thanks in advance. Hartmut -- frag nicht - du könntest eine antwort erhalten Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance question: Switch / NodeMask / WriteToFile
Hi Hartmut, Using 100's of thousands of scene graph objects to represent a tree will always be a performance problem, no matter what LOD'ing or scene graph structure you use. Using such a fine grained scene graph will cause problems in cull, draw dispatch and draw down of the GPU. It very much sounds like you have engineered one of the worst possible ways to tackle the task one could think of. This really begs the question what you are trying to do here? When you say a tree, could you give us a screen shot so we know what you are trying to achieve. Perhaps if we know what you are trying to achieve we can recommend how you should construct your scene graph to achieve best performance. Robert. On 2 March 2012 12:34, Hartmut Leister haleis...@gmx.de wrote: Hello everyone, I'm experiencing performance problems with my osg scene. I have many (up to 100k) geometries to display a tree. I'm building my whole scene graph at the beginning. To view it only partially I inserted root - group - PositionAttitudeTransform - Switch - (a/b) (a) LOD - Geode - Geometry or LOD - BillBoard - Geometry (b) Geode - Geometry Now when the scene is only partially visible (using osg::Switch), it's laggy nonetheless. If I wanted to load and save my scene on demand, what would be the best possibility (in regards of performance) 1) write unneeded subgraphs to a file 2) cache unneeded subgraphs (how would I do this?) 3) use NodeMask on osg::Group (would this also black out the respective subgraph?) Looking forward for input. Thanks in advance. Hartmut -- frag nicht - du könntest eine antwort erhalten Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ 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
