> > Ahhh premature optimization. With performance optimization work one really > does need to profile against normal usage. >
But I think that kind of optimization on for example Android devices is useful. > > Cull should normally be pretty cheap, if it's expensive it suggests that the > scene graph is sub-optimal and is too fine grained/contains too many in scene > graph transforms. There are lots of techniques for addressing this. > I know I was trying to improve it w. But when you have a lot of dynamic object on scene( 100-500 ). Lot's of animated object so you only optimize a root of problem which in my view is a cull traversal. > > One has to do testing in context, doing specific tests such as running a test > within a small loop will give you quite different results than when the code > is used in normal scene graph usage. As I mentioned, normally scene graphs > the cull and draw traversals are mostly effected by bandwidth limitations > that tend to swap CPU operations. > As you says earlier that OSG's focus is a high performance. So high performance should be not only in normal scene graph usage. I looking forward that OSG have a good performance in on heavy dynamic scene :). My personal goal is too help to achieve that. To end this discusion I will try in the near future to prepare SEE versions of mathematics. And I hope that the performance boost of their use will that will be available as an option in the OSG. Lukasz ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56726#56726 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
