Hi Julian, I don't have the time right now to dive in to a complex discussion. A few general feelings on the topic so you know where I stand:
First up sharing VAO's would be best done by shading a VertexArrayBlock container class for per vertex arrays, that osg::Geomertry objects would share. The VertexArrayBlock would map to VAO's. At this point in time I don't think the performance benefit of adding this extra level of complexity into the OSG is probably not justified - in tests I did with your early VAO sharing code performance was worse than the non shader VAO implementation that is now in the core OSG. You may have improved your VAO sharing implementation to avoid the CPU overhead that was limiting performance, but I wouldn't expect it'll make a big difference for most OSG usage cases. The BaseVertex extension to OpenGL is something that looks like a hack for lazy OpenGL application developers that don't wish to update their index and draw array offsets. The osg::PrimitiveSet class has an ofsetIndices(int) method makes it easy to readjust primitive sets when vertex array are merged, so it's essentially the same feature, just implemented on the OSG side and in a way that is compatible with all OpenGL versions and compatible with scene graph code that traverses the scene graph for things like intersection tests. I am not aware of any real benefit of base vertex for OSG users. We are now not far from making the next stable OSG release, I still have shader_pipeline functionality to complete for it, this is my focus. The shader_pipeline functionality will benefit the majority of OSG users so in terms of bang for the buck this is where I need to spend my time working on rather on niche areas of the OSG/OpenGL usage. Are there are small and uncontroversial changes to the OSG that will help your usage case then please put them forward. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
