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 <[email protected]> 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
