[osg-users] [About VertexArrayObject Branch] FeedBack and Insight

Robert Osfield robert.osfield at gmail.com
Tue Aug 16 11:25:35 PDT 2016

Hi Julien,

On 16 August 2016 at 18:37, Julien Valentin <julienvalentin51 at gmail.com> wrote:
> Hello all
> @scraw : geometries doesn't have to share vertex arrays but bufferobjects..this is not the same:
> The pattern that maximize vao reutilization is the followed
> Geom1
> G1VertAttrib1->BO1 G1VertAttrib2->BO2...and a Unique IndexArray->BON
> Geom2
> G2VertAttrib1->BO1 G2VertAttrib2->BO2...and a Unique IndexArray->BON
> With this pattern and vao sharing I have not only draw stage drop but also a huge gpu charge decrease
> The only problem is that you should use glDrawXXBaseVertex or offsetIndices of your IndexArray
> My bench in release this time
> .............................................................. Cull       Draw        GPU          FPS
> Pattern on all geometries with 1VAO/Geom   2            4            1.37            160
> Pattern on all geometries with shared VAOs   2            2            0.47            200
> So I think there's interest in sharing vaos

If you have a usage case please create an example that we can share
and use when benchmarking.

FYI, The VertexArrayState class that wraps up vertex array dispatch
and vertex array objects when enabled is capable of enabling sharing
between osg::Drawable.  In fact it's possible to share a single
VertexArrayState between the whole scene graph just relying upon the
VertexArrayState object in osg::State.  When VAO is not enabled
osg::State maintains a single VertexArrayState object that handles all
the vertex array dispatch.

Currently I haven't exposed the local osg::Drawable VertexArrayState
object as publicly accessing able in osg::Drawable but this could be
done easily.  I'm not yet convinced that this is good idea and don't
yet know of the consequence that might unfold.

Please remember the VAO system has to work well with the non VAO
usage, performance overheads have to be kept to a minimum and the
usage for end users has to be kept simple, adding an extra layer of
complexity is something that most users would really struggle with.


More information about the osg-users mailing list