Hi Julien and Robert, I've added and successfully tested Julien's proposal into my branch (updated to current master) dedicated to test macOS OpenGL Core Profile.
There are some minor modifications as we need to use of vertex buffer objects by default if fixed pipeline isn't available. To make it easier to look into it I've create a PR : https://github.com/openscenegraph/OpenSceneGraph/pull/92 HTH -- nǝıɥʇɐƜ On 29 June 2016 at 19:21, Julien Valentin <[email protected]> wrote: > 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 >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
