On 15 January 2014 20:40, Ethan Fahy <[email protected]> wrote: > Thanks for bearing with me Robert, I do realize that there has been much > discussion over this topic (I have spent hours trying to understand it all > but OSG is the only exposure to OpenGL that I've ever had so trying to > understand it all is tricky for me). > > You mention using the osg_deprecated to tide me over, but I'm wondering > what is the more appropriate long-term solution. To be clear, I don't need > to support any existing geometry that contains BIND_PER_PRIMITIVE (i.e. I > don't need to use fixDeprecatedData(). What I do need to do is to be able > to create new osgGeometry objects with osg3.2 and future versions of osg > that allow me to have the end-effect of coloring each primitive > individually. Now, if I am understanding correctly, what I will have to do > when creating new geometry is to only put a single primitive in each > primitiveset and use BIND_PER_PRIMITIVE_SET. My understanding is that > BIND_PER_PRIMITIVE_SET is supported in OpenGL and that this will not be > deprecated any time soon. Do I have this more or less correct?
BIND_PER_PRIMITIVE_SET is OK to use, it can be used relatively efficiently with all versions OpenGL. It could result in lots of OpenGL calls though as you have fine grained primitive sets that each have to be sent to OpenGL. Performance witse this is still be more efficient than what the OSG was having to do with BIND_PER_PRIMITIVE though as here it had to duplicate data and reorder before sending it OpenGL. The route with best performance on modern hardware would be to duplicate the vertices and use per vertex colours. This route would allow you to use a single DrawElementsUByte and lead to less OpenGl call overhead, which typically saves more than the cost of the extra data. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
