Hi,
On Tuesday 07 November 2006 14:11, Robert Osfield wrote:
> I'm not the expert on ac3d, so hopefully Geof Michel the author can
> review and chip in.
Is he still around here?
> > In summary we have many people reporting performance problems with osg
> > compared to plib especially under win32.
>
> It'd be worth doing profiling about what is the bottleneck, it is
> likely that something is set or being used efficiently.
Yep.
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?
> During the update traversal the OSG only traverses subgraphs that
> contain nodes that need updating, this means that update traversals
> typically are less than a 1ms, if its substantially greater than it
> suggests that their is bottleneck that your adding somewhere along the
> line.
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.
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.
> > Also we have a visitor collecting scenery triangles around the aircraft
> > that collects them using a TriangleFunctor to do some kind of collision
> > detection with those few triangles. That TriangleFunctor has plenty of
> > virtual calls in the innermost loop that I currently expect to hog cpu
> > time. ... still investigating.
>
> 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. Code analysis is most often not good enough to see that even if
all required knowledge about the concrete types is available. Allmost allways
the compiler does not even have enought information about the types in
question without looking into other cpp files besides ...
A method to avoid the vtbl calls would be the so called Barton-Nackman trick.
In this case you do not have any virtual table that must be optimized away.
Even if the compiler decides not to inline the function in question you will
get a function that exactly fits the original problem without a vtbl.
If you interrested I can provide an implementation of that.
That would be anyway interresting since we do also need something similar than
the TrinalgeFunctor for lines - at least with the current implementation.
> 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.
> 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.
Greetings
Mathias
--
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
