[osg-users] [osg-submissions] GL3 Mac OS X needs VertexArrayObject

[Robert Osfield]

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.marache at 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.marache at 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.osfield at gmail.com> wrote:
>>>
>>> Hi Mathieu,
>>>
>>> On 9 June 2016 at 07:44, Mathieu MARACHE <mathieu.marache at 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-submissions at lists.openscenegraph.org
>>>
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>>
>
>
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>