HI Mathias, On 11/7/06, Mathias Froehlich <[EMAIL PROTECTED]> wrote:
Is he still around here?
Geoff occassionally pops up now and then, not sure he's on osg-uers right now :-)
Anyway, do you have any methods to do OpenGL profiling? Can I find out what parts of the scenegraph are more expensive than others? What are your methods to do do that?
The thing to do is start at the top and work down, worry about OpenGL much later. Producer/osgProducer has stats code in for measuring update, cull and draw dispatch, and draw GPU times. This usually gives a broad brush from which to work from. For local timings just use an osg::Timer::instance() to get start/end times.
Well, there are just many nodes where some updates must be done. So it has to traverse many nodes. And due to the structure of the visitor pattern you have to do many calls that cannot be inlined.
Traversal is generally quick, I certainly wouldn't worry about cost of the virtuals used during a traversal, the big hit you contend with is memory bandwidth when doing a traversal. How many nodes are you updating? 10? 100? 1000? 10,000? If its under 1000 then I wouldn't expect traversal to be a big issue. More likely is the ops you are doing in the update traversal.
I am thinking of collecting those update callbacks in one top level callback per toplevel aircraft model. That would - depending on the distance to the eyepoint - decide if the updates are executed or not. I could avoid traversing a huge count of subgraphs and avoid doing many callbacks as such if the aircraft that is animated using that update callbacks is too far away.
I'd find the bottlenecks before you try anything elaborate. Most users don't need to do the above. The OSG is used is heavy duty flight sims and I don't here of problems. The OSG gets hammered pretty hard by some pretty serious end users. If there are performance issues its typically down the way the scene graph is being used.
> There shouldn't be an virtual calls within the inner loops, it should > be inline functions all the way, this is whole reason for the > existance of the TriangleIndexFunctor and TriangleFunctor templates. Nope. Devirtualization is an optimization that is very seldom implemented in compilers.
I not expecting any clever compiler tricks. The TriangleIndexFunctor doesn't rely upon virtual functions its a pure template class, there isn't anything to "devirtualize". Unless you are using a virtual method in your functor, if this is the case rewrite it straight away into an inline method. See the src/osgUtil/IntersectVisitor.cpp for an example of collision detection and TriangleFunctors.
If you interrested I can provide an implementation of that.
Feel free to post you intersector code.
That would be anyway interresting since we do also need something similar than the TrinalgeFunctor for lines - at least with the current implementation.
So far a LineFunctor or PointFunctors haven't been requested. You can dynamically cast osg::Drawable leaves to a osg::Geometry and get the source primitive data if your wish. Its easier to do this for lines and points than it is for triangles as surface primitives can be defined in some many different forms in OpenGL/OSG.
> If your primitive sets are very fine grained then this perhaps could > cause a lot of virtual method calling,so longer tri strips or lists of > triangles will be more efficient. How are you setting up the terrain? > How many triangles for tile? Are you testing about bounding > volumes? Yep, I do.
Ok. Can I ask the above questions again, minus the one that your answered... :-)
> There are lots of ways to make collision detection efficient. What to > recommend will depend alot of the type of scene graph structure you > have and what ops you want to do on them. That code part is something that must change in the longer term. There must be some hierarchical bounding volume tree that fits better than the current scenegraph structure. But that is a far term project. Currently I am working on restoring all we had with the previous implementation. From my point of view I do not have the time to rewrite such parts from ground up.
The OSG has an optimization pass that can create balanced quad trees for you, if this is what you are after. See include/osgUtil/Optimizer Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
