Hi Robert, Yes it's a small fix that does not address the full plugin, I wanted to have your opinion before. If need to adjust other things in this plugin I will consider to rewrite how primitive set are generated and I will drop the tristrip.
Thanks Cedric On Fri, 2010-12-03 at 18:55 +0000, Robert Osfield wrote: > 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 > -- Provide OpenGL, WebGL and OpenSceneGraph services +33 659 598 614 Cedric Pinson mailto:[email protected] http://www.plopbyte.net
signature.asc
Description: This is a digitally signed message part
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
