OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Geometry useVertexArrayObject

Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission
View previous topic :: View next topic  
Author Message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Tue Jun 21, 2016 5:48 pm    Post subject:
Geometry useVertexArrayObject
Reply with quote

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
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Wed Jun 22, 2016 2:19 pm    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

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
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Thu Jun 23, 2016 10:50 am    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

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
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Tue Jun 28, 2016 3:30 pm    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

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
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Tue Jun 28, 2016 4:12 pm    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

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
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Tue Jun 28, 2016 5:25 pm    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

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
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 10890

PostPosted: Wed Jun 29, 2016 3:57 pm    Post subject:
Geometry useVertexArrayObject
Reply with quote

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:
Quote:
Oups I've introduced a bug doing this


mp3butcher wrote:
Quote:
I have forgotten some tests if glBufferObject.dirty then recompile


mp3butcher wrote:
Quote:
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:
Quote:
I clean a bit add add required define in GL.in,GL and main CMakeLists


mp3butcher wrote:
Quote:
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:
Quote:
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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Wed Jun 29, 2016 5:20 pm    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

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 have a lot of experience using VAO through 2 pure OpenGL personal projects:
-a custom MT rendering engine based on gl core profile -YARE YetAnotherRenderingEngine- (I kinda abandonned it to focus osg)
-a post php project (a multiscale approach to realtime 3D Flow) that I ported to osg (osgFluid)
Don't search the web they aren't public

I would be glad to modify the approach I've implemented 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 glBufferArray) can be shared among several Geometrys, it felt natural to me to make vaomanager hashkeys to be the list of associated BufferObject.
Is it bad?

-This first assertion taken as a good one, I just took the design used for display list in Drawable.cpp and adapt it for the purpose of VAOs. The main differences are:
*I used a referenced Object (PerContextVertexArrayObject) in order to know when VAO isn't not use anymore (in destructor)
*I didn't use a VAO pool but create it on demand

Further optimisations could be:
-use a VAO pool (I don't know if there's a consequent overhead in glGenerateVertexArray)
-storing current bounded VAO in osg::State.cpp in order to minimizing call to glBindVertexArray,
(Edited: not possible in fact: other array buffers can be bound between drawimplementations so it would break the vao def)
-user notification when he use not core profile feature such as not PER_VERTEX buffer binding)
-find a way to integrate glVertexArrayBindingDivisor( i think -not sure- it can implement the osg BIND_OVERALL 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:
Quote:
Oups I've introduced a bug doing this


mp3butcher wrote:
Quote:
I have forgotten some tests if glBufferObject.dirty then recompile


mp3butcher wrote:
Quote:
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:
Quote:
I clean a bit add add required define in GL.in,GL and main CMakeLists


mp3butcher wrote:
Quote:
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:
Quote:
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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Mathieu (Mathieu MARACHE)
Appreciator


Joined: 29 Oct 2009
Posts: 102

PostPosted: Fri Jul 01, 2016 8:51 am    Post subject:
Geometry useVertexArrayObject
Reply with quote

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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:
Quote:
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.





Quote:
On 28 June 2016 at 18:25, Julien Valentin <> wrote:

Quote:
Oups I've introduced a bug doing this


mp3butcher wrote:

Quote:
I have forgotten some tests if glBufferObject.dirty then recompile


mp3butcher wrote:

Quote:
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:

Quote:
I clean a bit add add required define in GL.in,GL and main CMakeLists


mp3butcher wrote:

Quote:
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:

Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Fri Jul 01, 2016 9:38 am    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

Thanks Mathieu
Despite your PR is based on an older versions of mine, perhaps, it could be judged cleaner than my current versoin ...
Since then I changed a lot of things just because VAO deletion didn't feel thread safe to me in the versions you used.
(I also add code to recompile bufferObjects if they're dirty before VAO binding and other stuff i don't remember)

Feel free to give your feeling about it but Robert doesn't happy with it

On my side I will try to locate specifities you added and merge them with my version

Mathieu wrote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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:
Quote:
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.





Quote:
On 28 June 2016 at 18:25, Julien Valentin <> wrote:

Quote:
Oups I've introduced a bug doing this


mp3butcher wrote:

Quote:
I have forgotten some tests if glBufferObject.dirty then recompile


mp3butcher wrote:

Quote:
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:

Quote:
I clean a bit add add required define in GL.in,GL and main CMakeLists


mp3butcher wrote:

Quote:
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:

Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 10890

PostPosted: Fri Jul 01, 2016 11:10 am    Post subject:
Geometry useVertexArrayObject
Reply with quote

Hi Mathieu,

Quote:
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

Good to hear that you've been able to adapt Jiulien's work and get it
functioning under OSX.

I have just done a quick code review of the PR. However, I have the
same reservations about the specifics of the approach as I reported
after reviewing Julien's original submission.

The work isn't wasted though, it's a really useful background
implementation to compare against as a final VAO implementations
shapes up.

My plan is to spend a couple of days next week dedicated entirely to
VAO issue with the aim of finalizing a VAO implementation, either from
scratch or drawing from Julien+your work.

I'm afraid my own ideas aren't yet solidified enough to explain how I
think things should look, it's also means I'm not in position to give
a critic of what I feel is lacking in the proposals so far. I'm
mainly going on gut reaction/instinct with this stuff right now. Been
involved with the OSG/OpenGL and trying to resolve the two as they've
evolved for so long now that some of the process is subconscious.
Sometimes that gut feel is indicative that something isn't quite right
yet and needs more work, even if I can't consciously explain it yet.
This is where just thinking about things fully without rushing helps
solidify things and bring out the communicable reasons for preferring
one approach vs another.

Sorry for the arm waving.... my brain sometimes works in mysterious ways :-)

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 294

PostPosted: Sat Jul 02, 2016 2:32 am    Post subject:
Re: Geometry useVertexArrayObject
Reply with quote

Hi all,
Ok you won I removed the map:)
It's right that at high scale it could induce a cpu overhead in VAOManager::getVertexArrayObject() and VAOManager::generateVertexArrayObject() ...
But in this implementation, vaos cannot be shared among Geometrys

see attached

(I haven't test it deeply as It was mainly code removal)

robertosfield wrote:
Hi Mathieu,

Quote:
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

Good to hear that you've been able to adapt Jiulien's work and get it
functioning under OSX.

I have just done a quick code review of the PR. However, I have the
same reservations about the specifics of the approach as I reported
after reviewing Julien's original submission.

The work isn't wasted though, it's a really useful background
implementation to compare against as a final VAO implementations
shapes up.

My plan is to spend a couple of days next week dedicated entirely to
VAO issue with the aim of finalizing a VAO implementation, either from
scratch or drawing from Julien+your work.

I'm afraid my own ideas aren't yet solidified enough to explain how I
think things should look, it's also means I'm not in position to give
a critic of what I feel is lacking in the proposals so far. I'm
mainly going on gut reaction/instinct with this stuff right now. Been
involved with the OSG/OpenGL and trying to resolve the two as they've
evolved for so long now that some of the process is subconscious.
Sometimes that gut feel is indicative that something isn't quite right
yet and needs more work, even if I can't consciously explain it yet.
This is where just thinking about things fully without rushing helps
solidify things and bring out the communicable reasons for preferring
one approach vs another.

Sorry for the arm waving.... my brain sometimes works in mysterious ways Smile

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 10890

PostPosted: Thu Jul 07, 2016 9:57 am    Post subject:
Geometry useVertexArrayObject
Reply with quote

Hi Guys,

My plan is to dedicate the next two days to getting VAO support into the OSG.

I am still working on the design side, but am optimistic I'll get
something complete this week. Should have a design to implement by
lunchtime today. I'll post updates as my work progresses.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Mathieu (Mathieu MARACHE)
Appreciator


Joined: 29 Oct 2009
Posts: 102

PostPosted: Fri Jul 08, 2016 12:59 pm    Post subject:
Geometry useVertexArrayObject
Reply with quote

Great news Wink
--
nǝıɥʇɐƜ



On 7 July 2016 at 11:48, Robert Osfield < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hi Guys,

My plan is to dedicate the next two days to getting VAO support into the OSG.

I am still working on the design side, but am optimistic I'll get
something complete this week.  Should have a design to implement by
lunchtime today.  I'll post updates as my work progresses.

Robert.
_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 10890

PostPosted: Fri Jul 08, 2016 1:42 pm    Post subject:
Geometry useVertexArrayObject
Reply with quote

On 8 July 2016 at 13:49, Mathieu MARACHE <> wrote:
Quote:
Great news Wink

Was hoping to finish it today, but have a birthday family walk and
dinner planned for the rest of today so heading off line.

I have a prototype of VAO functionality kinda working. Performance is
on big city models better than without VAO but still not as good as
with display lists...

I'm currently refactoring the internals of how vertex data is passed
to try and avoid some of the CPU overhead. I expected there is couple
more days work getting it all working smoothly.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts draw primitive sets and geometry shad... wernerM General 0 Wed May 24, 2017 3:20 pm View latest post
No new posts Using Geometry with packed vertex arrays ravidavi General 2 Sat Mar 25, 2017 4:39 am View latest post
No new posts Jittering/Flickering geometry problem umesh General 3 Tue Feb 14, 2017 10:53 am View latest post
No new posts [Solved] Bug while updating geometry ... Nikkitta General 2 Thu Jan 26, 2017 9:27 am View latest post
No new posts Bounding box calculations of geometry... pugdogfan General 1 Thu Jan 19, 2017 8:57 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP