Hi Peter, On 4 June 2013 14:29, Peter Amstutz <peter.amst...@tseboston.com> wrote: > Would you consider changing BIND_PER_PRIMITIVE code to do some kind of > internal conversion to fast path rendering, such as expanding the arrays by > 3x (duplicating the color or normal for each vertex) so that it can use the > per-vertex rendering path?
That is what the OSG has been doing since 3.0.x but this type of emulation is very slow. While it might be convenient for end users It's bad for a scene graph to hiding the complexity to such an extent that you get huge slow down with seemingly Innocent usage. I much prefer making efficient use of OpenGL the default, and dropping off efficient fast paths something you have to try hard to do, rather than something you can do without even realizing. Going forward there are advanced features of OpenGL that really build upon the that vertex arrays can be accessed and how primitive data is used that doesn't fit well with this old functionality. > I have certainly written code where I wanted > per-face coloring or sharp edged shading (same normal across the face) and > PER_PRIMITIVE captures my intent better than using PER_VERTEX and having to > duplicate the colors/normals. It's not a big deal, but having the concept > handled by osg::Geometry is more convenient than handling it in client code > --- as you've noted, even in the examples PER_PRIMITIVE is used quite a bit. I understand the convenience angle, but as it hides a multitude of sins I don't believe it's a good practice. Perhaps the best way to deal with this to to help a osg::Geometry builder class that can help users create the data they want in a convenient form. In the short term you could simply use GeometryDeprecated. Having a converter from GeometryDeprecated to new cleaned up Geometry will be relatively straight forward and might be another approach. I believe that a fast path only osg::Geometry is worthy enough goal to explicitly drop all slow path support, so it only supports what modern OpenGL can support with no "clever" emulation being hidden behind the scenes. This does mean the convenience of things like vertex indices and BIND_PER_PRIMITIVE have to be dropped, to deal with this I don't think new osg::Geometry should bend to accomodate, rather we should seek out ways of making it more convenient to create osg::Geometry - I call upon the community to make suggestions about help classes. Cheers, Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
