Hi Julian, I have just done review of your latest VAO changes. There are several areas that I'm not 100% happy with the approach taken that I don't feel it's appropriate to merge them as is. I don't think it's just a matter of tweaking a few changes here or there as that approach taken just doesn't feel right, and it's a complex enough a topic that I can't personally give good guidance on how to fix them without spending more time learning about the specifics of the extension and the possible approaches that could be taken on the OSG.
My gut instinct it that I simply need to set aside a couple of days and totally absorb myself in the topic and come up with the most efficient way to implement VAO. Most GL extensions are pretty orthogonal to the rest of the OSG so can be easily integrated, VAO isn't though, it's really deeply involved in how the OSG sets up and and bind vertex data. The VAO path will be used so often during draw traversal that it's essential that we make it as efficient as we can so that the CPU overhead is minimized and the full speed of the VAO is made available to applications. I optimistic we can add VAO reasonably seamlessly, exactly how isn't something that will pop into my head without really thinking about things. My hunch is that it'll be best to have a VAO objects per osg::Geometry for each context, a bit like the way display lists have been used in the past. If we get VAO right hopefully the CPU overhead associated with vertex array set up will be minimized enough that we can change the default of the OSG to use VAO's instead of display lists. I need to decide whether I go for this work this week or next. Either way I want to wrap it up by the end of next week. Thanks for you patience on this, Robert. On 28 June 2016 at 18:25, Julien Valentin <[email protected]> wrote: > Oups I've introduced a bug doing this > > > mp3butcher wrote: >> I have forgotten some tests if glBufferObject.dirty then recompile >> >> >> mp3butcher wrote: >> > I have spot a problem in VAO implementation: >> > In the case ContextData is freed before Geometry, VAO destructor may >> > re-create a new VAOManager not managing itself >> > fix (that can be judged hacky): >> > -implement VAOManager::deleteAllGLObjects deleting all managed glvao >> > -add a test (!empty) in VAOManager::deleteVertexArrayObject in order not >> > to try deleting glvao if VAOManager::deleteVertexArrayObject is called >> > after its destruction (and so on a new VAOManager) >> > >> > >> > >> > mp3butcher wrote: >> > > I clean a bit add add required define in GL.in,GL and main CMakeLists >> > > >> > > >> > > mp3butcher wrote: >> > > > Hi Robert >> > > > I think there was a threading issue with my last design (release of >> > > > vao) >> > > > I introduced a new GraphicsObjectManager singleton to overcome this >> > > > issue >> > > > >> > > > >> > > > mp3butcher wrote: >> > > > > Hi Robert, >> > > > > >> > > > > I don't have any news from Mathieu of the MACOS core context support >> > > > > of my implementation of VAO so I ask Robert for its toughts about it. >> > > > > >> > > > > Take your time no hurry there >> > > > > >> > > > > Thank you! >> > > > > >> > > > > Cheers, >> > > > > Julien >> > > > >> > > >> > >> > > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=67884#67884 > > > > > _______________________________________________ > 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
