Hi Harold, On Tue, Apr 14, 2009 at 12:37 PM, Harold Comere <[email protected]> wrote:
> Hi all, > > I am currently working on a kind of drawable optimizer. > My goal is to make primitive set groups and have only one drawable per > group. ( grouping vertexs linked by any face of the group ) > The effect will be to avoid to have separated objects in a same drawable. > In same way, i want to merge small drawables containing only few faces but > are in the same object. > I have a node visitor wich will do this for all drawable in each geode. > > When i look at primitive set types generated by any importer, i notice that > sometimes it is drawArrays, and other times drawElements. > So my question is if there is any osg optimisation wich choose between > drawArrays or drawElements alone ? drawElements is usually faster than > drawArray calls, so i wonder if i can convert everything in drawElements > type without lose fps .. This would make a useful addition to osgUtil::Optimizer if you'd care to submit it ;-) As for the performance benefits - I'd expect they'd vary with type of scene and drivers/hardware. Cases like drawing points or lines will be better done with DrawArrays. Cases like meshes where many triangles have shared vertices DrawElements should work best. It'd be interesting to do a test against various drivers on various machines. It would also be interesting to see which import routes prefer DrawArrays vs DrawElements and may well be down modeller's preference as well. > Another question, osg doesnt seem to use VBOs by default, is there any > reason ? > As Paul said the OSG's use of display lists predates the existence of VBO's. Now that OpenGL and OSG supports VBO's the question then comes should VBO's be made the default... we'll that depends upon the performance of the two. In my own tests big city models where you have lots of separate pieces of geometry the performance is better with disply lists. Whereas for scenes where you have a moderate number of large objects then VBO's are better. I believe the reason that VBO's aren't faster than display lists on all cases is that the function call overhead of setting up VBO's introduces a penalty that outweighs their benefit on scenes with lots of separate geometry. The fact that we have to use function pointers to set up VBO's compounds this, we have to use function pointers rather than straight functions as the OSG has to query for VBO support at runtime as not all drivers support VBOs. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
