Hi Julien ;-) Nice to see you there, do you have a branch with those changes I could test ?
-- nǝıɥʇɐƜ On 13 June 2016 at 22:27, Julien Valentin <[email protected]> wrote: > ...And now I encapsulated all the stuff in an object > I used a ref_ptr to share VAO among Geometries and manage VAO deletion. > It seams to work but it surely need reviews > ( > -not sure about the validity over time of the GLExtension pointer I store > in VAO > -perhaps _vao[contextID] should be dereferenced in releasGLObjects > ) > > > > mp3butcher wrote: > > After few thinking I remember why I haven't post this submission before: > > my stuff works but element buffer is bound separately (per primitive > set) so only I only use VAO for ARRAY_BUFFER an so (stop me if I'm wrong) > don't comply with Core profile requirements. > > Here's my update proposal: > > I changed PrimitiveSet's > > draw(State& state, bool useVertexBufferObjects) to > > draw(State& state, bool useVertexBufferObjects,bool bindEBO=true) > > in order to achieve ELEMENT_BUFFER encapsulation in vao > > > > > > > > mp3butcher wrote: > > > Oups, After few tests I found a bug > > > Ignore my last post > > > Sorry > > > Edit: > > > I've also found problems: > > > -with attributes with binding different than BIND_PER_VERTEX, I > investigated this but I'll wait for your first reviews before posting my > hacks (that doesn't seams to work with core context) > > > -EBO primitive set (Maybe changing PrimitiveSet::draw(State& state, > bool useVertexBufferObjects) to PrimitiveSet::draw(State& state, bool > useVertexBufferObjects,bool useVAO) is to consider) > > > > > > > > > mp3butcher wrote: > > > > Hi all > > > > Here is my support for VAOs > > > > It seams to work well until then.. > > > > Idon't know if its ready for commit > > > > reviews are welcome > > > > > > > > > > > > robertosfield wrote: > > > > > Hi Mathieu, > > > > > > > > > > On 9 June 2016 at 07:44, Mathieu MARACHE <> wrote: > > > > > > > > > > > I'm struggling to understand what to do. I merely put up a > solution that was > > > > > > explained in a staled thread from 2012 (!), subject was : OpenGL > 3.2 support > > > > > > in OS X 10.7 (Lion) > > > > > > > > > > > > > > > > This was clearly just a hack to get things "working" not an actual > solution. > > > > > > > > > > > > > > > > > > > > > I see your points, you are right this is not a general solution. > > > > > > > > > > > > I'll be reading a bit more on VAO and try to add VAO support > directly in > > > > > > Geometry is possible... > > > > > > > > > > > > > > > > I would be worth just moving the discussion about VAO support to > > > > > osg-users so we can all discuss the what solution. I'm happy to > pitch > > > > > in some time to getting this resolved for 3.6. > > > > > > > > > > Right now from what I've learnt that natural place for binding the > VAO > > > > > would be in osg::Geometry. It may be that osg::State would be the > > > > > part of the OSG that does the binding as it already manages the > vertex > > > > > arrays and associated buffer objects. The VAO essentially wraps > up > > > > > all the vertex array settings in one place so that once it's set up > > > > > one just binds a single VAO object rather than a VBO and then > specify > > > > > the individual vertex arrays within this. In theory this should > mean > > > > > the system is more efficient - as long as we get the design and > > > > > implementation right. > > > > > > > > > > Robert. > > > > > _______________________________________________ > > > > > 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=67597#67597 > > > > > _______________________________________________ > 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
