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

[Robert Osfield]

Hi Wang,

The RenderLeaf is a object that is dynamically allocated and reused,
it doesn't have a lifetime linked to any specific drawable let alone
the vertex arrays or buffer objects objects associated with them.  The
RenderLeaf only exists to help the cull traversal specify what parts
of the scene graph should be rendered and when, it isn't and shouldn't
be directly linked to the scene graph as there is the mapping is
entirely dynamic and deliberately separated from the scene graph i.e.
the scene graph itself knows nothing about what RenderLeafs might
reference it.

Vertex array objects are very much the domain of the scene graph and
have a natural affinity to the other OpenGL objects that the scene
graph maintains.  Furthermore, the strongest affinity that VAO's have
is with vertex arrays and vertex buffer objects, which in the OSG's
case are tied to osg::Geometry. this means the natural place to manage
VAO's is with Drawable/Geometry.  The only open question I see is
whether we enable/encourage sharing of VAO's between osg::Geoemetry.

For most OSG users osg::Geometry will all have their own osg::Array's
for vertex arrays etc. and each of these would have their own VBO's,
so in turn this would map to each Geometry having their own VAO.  This
implementation is supported right now in the OSG' vertex_array_object
branch.

All the OSG plugins that load 3rd party data create models such that
each osg::Geometry has it's own vertex arrays etc, without sharing.

In special cases users could create their own vertex arrays and share
these between osg::Geometry, or have separate vertex arrays but share
the osg::VertexBufferObject between them.  I don't know how many end
users do this, over the years it's not something that has been
discussed much.  The OSG has been written to support this sharing but
how much potential benefit there might be from building your scene
graphs this way I can't say as I haven't tested it.

>From what I understand Julian is proposing is for those sharing vertex
arrays then sharing VAO's also would be valuable.

Right now my focus is on getting the vertex_array_object branch
working well across the full range of OSG usage models, this is far
from trivial task.  The sharing of VAO's might be interesting to a
small number of users so I'm open to it, but it's always going to be
niche feature given how sharing of vertex arrays hasn't historically
been a hot topic in the OSG community.

What is really important for the OSG right now is that end users
actually have a look at the vertex_array_object branch and test it out
on their models.

Robert.





On 17 August 2016 at 05:43, wang dexing <wangdexingit at gmail.com> wrote:
> Hi Julien,
>
> Thank you for your reply,I think there is no separation between user level and system level,since the development of OpenGL also exposes more low-level implementation.
> the reason why I didn't use 'vao' in 'drawable' is that I think  'vao' is used to manage 'vbos',but 'vbos' is not only from 'drawables' ,but also from somwhere else,for example,'instance arrays' of 'status information' .It's rigid to put 'vao' in 'drawable'.So I'd like to find a better place using 'vao'.I think 'RenderLeaf' can be a good place because it has the member '_drawable' and its parent is 'stategraph', it can be closely linked to the two.
> I know that cullvisitor isn't fit for instance culling,so I didn't change the original structure,only calculated 'instance data' when cullvisitor traverse 'instance node' which I signed.just as I wrote,I didn't want to give up osg's 'cull' function,I only add some extra features when cullvisitor traversing.I extended some classes to support it.
>
> Thank you!
>
> Cheers,
> wang
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68399#68399
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org