Hi Xia, It's a bit late in the evening for me to go into the topic deeply.
It's not possible for us to know what is specifically going amiss in your case as the details are too scant, the best we can do is provide some general pointers: For datasets with a large number of nodes and vertices the cost of computing the bounding volumes of the geometries and nodes can be expensive enough to take up time in the update traversal if you just add the new subgraph into the main scene graph without computing the bounding volumes in the separate thread. Calling subgraph->getBound() in your compute thread prior to move the node into the merge queue is one way to avoid this issue. This is what the osgDB::DatabasePager does, so have a look at src/osgDB/DatabasePager.cpp if you want to see how a full blown mutli-threaded database works (it's probably overkill for your specific needs though). The osgterrain example has some multi-threaded scene generation built into for testing purpose, so have a look at this for inspiration. Make sure you do all performance tests with a release build. Consider your approach - does it need to be done on the CPU, any chance you could defer much of the work to the GPU? These days GPU's are extremely powerful and many tasks that used to be done on CPU to avoid overloading the GPU can now be done on the GPU. Often the throughput of the GPU allows you to process data in quite a raw way and brute force solve the problem rather than try to be "clever" with CPU side optimizations. One example of this the osgTerrain::DisplacementMappingTechnique that I've been working over the last couple of months, this is available in svn/trunk and gains efficiency by sharing a set of osg::Geometry containing grid meshes, these shared meshes then read height fields from textures on the GPU to displacement them to their intended position for each tile in the terrain. The vertex shader also computes normals. This approach of sharing geometry and sending just height fields as textures dramatically reduces the CPU and GPU memory consumption and with it bandwidth load and cache misses. It ends up being faster than the old GeometryTechnique even though the GPU processing load is far higher - as it address the actual bottlenecks that see on modern computer systems, rather than ones we might have seen a decade or two ago. Finally, you'll just need to profile your own application if you can't spot bottleneck from just a review of the design and code. We can't help this I'm afraid as you're the only one with your code and your data. Robert. On 14 January 2015 at 16:22, Xia Baobao <[email protected]> wrote: > I want to implement a dynamic node. Actually, it is a terrain, changing > with time. The calculation costs a lot, which cannot be done in one frame. > My "silly" attempts are as follows: > At first, I tried to change vertices in an UpdateCallback, with the whole > change done per frame. Of course this attempt resulted in a very low frame > rate. > Then I tried to do the calculation in another thread (using pthreads ). > The data would only be changed after the calculation. So the change were > not done every frame. But I still had to replace all vertices of the node > in one UpdateCallback, which I guessed should still be very slow. > I came up with an idea. I constructed a new node from the new data. And in > the UpdateCallback, I replaced the old node with the new node. I thought > the new node would be compiled, so it would be fast. > Actually, It failed again, it took a long time to replace the node. > > I still want to ask, is there any way to implement a compiled node? > I am also curious about other solutions. > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=62332#62332 > > > > > > _______________________________________________ > 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
