Hi Robert,
On Tuesday 07 November 2006 16:22, Robert Osfield wrote:
> 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.
In a standard scene at the default location with the default aircraft about
5000-10000. Depending on the models in the scene even more.
Think that every object that moves wrt its parent - including for example the
ball in the artificial horizont - is updated using such an update callback.
I have tried to replace the update callbacks that actually do anything with
the plain osg::NodeCallback implementation that does nothing but return.
This way we will have the same traversal node count but no meat in the
callback. The update() time is roughtly (~95%) the same. That tells me that
traversing is the cost not the callbacks itself.
As told before this could be done more inteligent and I think we need to do
so.
> If there are performance issues its typically down the way the scene
> graph is being used.
This is possible too.
What are the top 10 most often made mistakes you see in your consulting job?
:)
> 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".
Oops, I have looked into that. I had in my head that the operator() that is
called with the triangle corners is a virtual - but it is not.
> > > 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... :-)
Ok. That depends.
The scenery tiles are relatively croase. Only about 1-20 triangles in a ball
of about 20 meters around the aircraft. But thise triangles are organized in
long tristrips that for example cover the whole runway or just bigger parts
of the scene. So boundingbox tests are very croase. You need to enter many
nodes that cover such strips to see that no triangles are in.
OTOH there are some objects that are very fine. These are also in the scene
and are sometimes masked out with the nodemask for the intersection test but
sometimes need to be considered since people want to land their heilcopter on
a roof of a building ...
Some of these objects also move over time. We need to consider not only at
discrete time snapshots but also at continous times in between. You would
else see aircraft jumpig on a rolling carrier ...
All in all I think that we need to seperate the intersection stuff from the
scene stuff and place that in some bounding volume treethat can have movable
nodes.
Smaller objects could then be tested just with a croaser test geometry.
Relevant parts can probably be simplified.
> 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
That is interresting. Thanks!
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/
