it prevents annoying Warnings from Apple GL Headers relevant part of gl3.h :
#if defined __gl_h_ && !(defined GL_DO_NOT_WARN_IF_MULTI_GL_VERSION_HEADERS_INCLUDED) #warning gl.h and gl3.h are both included. Compiler will not invoke errors if using removed OpenGL functionality. #endif -- nǝıɥʇɐƜ On 9 June 2016 at 18:36, Robert Osfield <robert.osfi...@gmail.com> wrote: > Hi Mathieu, > > Changes look like they are close to what will work. We could stick > with the simple object ID but I'd be inclined towards having a object > for it so you could share objects between osg::Geometry, as we all as > having the ability to store data such as the osg::Array associated > with the VAO. I haven't really thought enough about the issue yet to > know for sure whether going the Object route is required so take this > as me just mulling things over. > > What is the addition the CMakeLists.txt: > > add_definitions(-DGL_DO_NOT_WARN_IF_MULTI_GL_VERSION_HEADERS_INCLUDED) > > For? Is this a hint the the Apple GL headers to do something special? > > Robert. > > Robert. > > On 9 June 2016 at 16:40, Mathieu MARACHE <mathieu.mara...@gmail.com> > wrote: > > I've finally made my mods against master branch on my clone for the > > OpenSceneGraph repo. > > > > > https://github.com/openscenegraph/OpenSceneGraph/compare/master...mathieu:feature/CoreProfileMacOSX?expand=1 > > > > I use the example osgsimplegl3 to display files, I've added the > > osgUtil::Optimizer to retessellate since CoreProfile doesn't do QUADS or > > POLYGONS. > > > > I've hacked into Geometry only to create a VAO and bind it. If I unbind > it I > > don't get anything displayed with the osgsimplegl3 example. > > > > However this doesn't look good since only the first geometry gets > > displayed... > > > > WIP > > > > > > -- > > nǝıɥʇɐƜ > > > > On 9 June 2016 at 11:57, Mathieu MARACHE <mathieu.mara...@gmail.com> > wrote: > >> > >> Hi Robert, > >> > >> Indeed VAO support is needed (in obligatory sense) for Macosx Core > Profile > >> targets but would be useful to other platforms also since it would make > the > >> system more efficient. > >> > >> I'm putting osg-users's mailing list in copy to see if someone has more > >> insight into VAO. > >> > >> I've tried to setup VAO inside Geometry and make appropriate calls when > >> needed but fail to show more than one geometry... > >> > >> I was on OpenSceneGraph-3.4 branch, I will try to setup a working branch > >> from master to show what I came up with. We can discuss on what would > the > >> appropriate route should be to implement this. As you mentioned it would > >> imply osg::Geometry and maybe also osg::State modifications... > >> > >> Regards > >> > >> -- > >> nǝıɥʇɐƜ > >> > >> On 9 June 2016 at 09:19, Robert Osfield <robert.osfi...@gmail.com> > wrote: > >>> > >>> Hi Mathieu, > >>> > >>> On 9 June 2016 at 07:44, Mathieu MARACHE <mathieu.mara...@gmail.com> > >>> 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 > >>> osg-submissi...@lists.openscenegraph.org > >>> > >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >> > >> > > > > > > _______________________________________________ > > osg-submissions mailing list > > osg-submissi...@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > _______________________________________________ > osg-submissions mailing list > osg-submissi...@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org