Hi Daivd, First up Transforms are relatively expensive to use, using 10's of thousands of them will introduce a CPU bottleneck.
Second up, ShapeDrawable is just written to help out with small rendering tasks, it was never conceived or intended to be used for rendering many thousands of shapes at one time. I now regret ever writing ShapeDrawable as it's abused all too often. This focus is made clear in the doxygen comments for ShapeDrawable: /** Allow the use of <tt>Shape</tt>s as <tt>Drawable</tt>s, so that they can * be rendered with reduced effort. The implementation of \c ShapeDrawable is * not geared to efficiency; it's better to think of it as a convenience to * render <tt>Shape</tt>s easily (perhaps for test or debugging purposes) than * as the right way to render basic shapes in some efficiency-critical section * of code. */ So what your tests have shown that both of your solutions are poor solutions from performance standpoint, and both these approaches are none to be inappropriate as well. This topic has been discussed many times on osg-users so have a look through the archives on performance optimization and ShapeDrawable. -- Now how you should rendering tens or hundreds of thousands of spheres is rather an open topic - it all depends upon what you are trying to achieve. One solution is to use point sprites and a collection of osg::Geometry that just render a flat list points, this allows you to scale to millions of sphere's per frame at 60Hz on modern hardware. Another good solution is to use geometry instancing. Without more knowledge of what you are trying to achieve it's not possible to point you directly in the right direction, but one thing we can say for sure is the direction you've taken so far is well established as not the way to tackle the problem. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
