Hi Cedric, With modern cards and use of VBO's over display lists it's becoming preferable to place all surface primitive into a small DrawElements container. Use of the tri-stripper is something that we should probably start dropping by default and leave it up to client apps to tri-strip if they feel it's appropriate for their hardware target.
For the case of the obj plugin I'd suggest we recode it so that it direclty generates an reasonable well conditioned PrimitiveSet usage i.e. use DrawElementUShort in place of multiple small primitive sets. You submission works as after processing of just one type of primitive set so is not really addressing the wider issue. After 2.9.10 is out I'd suggest we look at how the obj plugin creates it surface primitives and get it to build them more efficiently for the start i.e. build a single DrawElementUShort(GL_TRIANGLES,..); Robert. On Fri, Dec 3, 2010 at 2:45 PM, Cedric Pinson <[email protected]> wrote: > Hi, > > Here a small fix to obj plugin and I would like to discuss about > 'policy' on Reader/Writer. > In my application I need to avoid draw call so using a lot of tristrip > is a problem. > By default obj plugin stripify the data in the reading part, there is a > flag to disable this behaviour, but in this case it generates one > triangle fan per triangle. So my fix remove all triangles fan of size 3 > and add one draw element as replacement. > > The question is a plugin should optimize directly the data read ? or can > we say that optimization is better to be done outside of the reader > writer. Or use local option to enable optimization instead of option to > disable it. > > Is there a doc or recommandation about writer a reader/writer ? because > we could recommand the 'good' policy if it makes sense to have one. > > Regards, > Cedric > > -- > Provide OpenGL, WebGL and OpenSceneGraph services > +33 659 598 614 Cedric Pinson mailto:[email protected] > http://www.plopbyte.net > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
