Hi Robert, I know it's a difficult feature to integrate but it's mandatory in order to migrate to correct core profile code.
I would be glad to modify the approach I've adopted but I need more details on what seams wrong to you. Here's my approach: -Grossly VAO are the evolution of displaylists for the use of Buffer Arrays, allowing encapsulation of vertex array state on the client side. (mainly vertexpointers and bindbuffer command) As osg::BufferObject( and so on underlying gl Buffer Array) can be shared among several Geometrys, it feel natural to me to make vaomanager hashkeys to be the associated list of associated BufferObject. (Is it bad?) -This first assertion taken as a good one. I just took the design use for display list in Drawable.cpp and adapt it for the purpose of VAOs. The main differences are: *I use a referenced Object (PerContextVertexArrayObject) in order to know when VAO isn't not use anymore *I don't use a VAO pool but create it on demand (Further optimisations could be: -storing current bounded VAO in osg::State.cpp in order to minimizing call to glBindVertexArray, (I want to add it for long but doesnt want to involve more classes for the moment) -user notification when he use not core profile feature such as not PER_VERTEX buffer binding) Julien. robertosfield wrote: > 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 <> 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 > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > > _______________________________________________ > osg-submissions mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > ------------------ > Post generated by Mail2Forum ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67919#67919 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
