Hi Robert, The issue is that it's impossible to create a custom node that overrides add/remove child, because of the architecture of the node classes. Specifically, there's no way for the custom node to correctly remove itself from its childrens' parent lists. We've hacked around this by creating a modified osg::Node header that friends our unordered group class, but I hope that won't be the permanent solution. That's why I suggested that this be added to osg.
I agree that it would be better to organize the scene graph differently in this case - it makes culling performance pretty bad as well - but that will take significantly more time, and just making removeChildren fast has been good enough so far. Max On Fri, Aug 14, 2009 at 9:55 AM, Robert Osfield <[email protected]>wrote: > Hi Max, > > osg::Group and the scene graph in general really isn't designed for > handling tens of thousands of children, let alone hundreds of > thousands. Huge flat scene graphs will be inefficient all-round, and > you'll be seeing all manor of performance problems due to this type of > scene graph set up. > > First I would suggest solve your scene graph management to avoid this > large number children - there is clearly something rather abnormal > about your scene graph, what it might be I can't say as I know nothing > about your app, but I can say it's quite the most extreme usage of OSG > I've headed of, and there is almost certainly a far better way of > managing your scene. If you really must have so many children then a > custom node would probably be the best way to manage it, this way you > can do custom traversals to handle scalability issues as well as have > custom addChild/removeChild mechanisms. > > Likely the solution to your scene graph needs will be refactoring the > scene graph in a way that uses custom nodes/drawables that avoid the > need for such colossal numbers of nodes. > > Robert. > > On Fri, Jul 31, 2009 at 6:54 PM, Max Bandazian<[email protected]> > wrote: > > Hi, > > I've been having performance issues with osg::Group, related to removing > > children one at a time. In one case, we have a group node with ~120,000 > > children, of which 30,000 need to be removed. This is much slower than > > expected - I'm consistently timing the removal at about 188 seconds total > on > > my quad-core machine. About 187.99 of these seconds are spend on > group.cpp > > line 182, which calls std::vector::erase: > > > > > _children.erase(_children.begin()+pos,_children.begin()+endOfRemoveRange); > > The problem with this usage of erase is that everything after the last > > erased element in the vector will be copied up, which in my case is a > whole > > lot of copies. One solution, which I'm now using, is to avoid calling > erase > > by making sure elements are only ever removed from the end of the vector. > > Here's my replacement for the line above: > > if (_children.size() == numChildrenToRemove) > > { > > _children.clear(); > > } > > else > > { > > int numThingsToCopy = std::min(numChildrenToRemove, > > _children.size() - numChildrenToRemove); > > std::copy(_children.end() - numThingsToCopy, > _children.end(), > > _children.begin() + pos); > > _children.resize(_children.size() - numChildrenToRemove); > > } > > With this change, removing the 30,000 nodes takes less than 1 second. It > > does change the semantics of removing children from a group, in that the > > children will be in a different order rather than just having their index > > changed. In my opinion it's worth it for the performance gain. > > The modified Group.cpp is attached. > > -Max Bandazian > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
