[osg-users] VBO Bug with 3.6.1 and Normal Arrays

Robert Osfield robert.osfield at gmail.com
Wed Jun 13 10:05:41 PDT 2018


Hi Dan, et. al,

I haven't yet got to bottom of this issue, but so far it looks like
doing the Array::setBinding(Array::BIND_PER_VERTEX) call later than
the array itself is assigned to the geometry bypasses the mechanism
that osg::Geometry uses to make sure all the arrays that need a VBO
have one assigned.

To clarify this issue further I've made the
Geometry::addVertexBufferObjectIfRequired() public so I can see if
calling this after the late Array::setBinding().  This isn't a
solution, just another workaround, but for me mainly a means of
testing a hypothos, to the problem late binding code I added the
geom->addVertexBufferObjectIfRequired(normals); call:

    if (!earlyBinding)
    {
        normals->setBinding(osg::Array::BIND_PER_VERTEX);
        geom->addVertexBufferObjectIfRequired(normals);
    }

This enables the test program to run properly without crash or
warnings, both triangles now behave the same regardless of the early
or late setBinding.  However, this isn't a proper solution, it won't
fix problem without amending late setBinding() codes in the OSG or in
client applications.  For these cases they really should be calling
setBinding prior to the Geometry:set*Array() methods.

As things stand I can't see easy solution as the Array doesn't know
about the osg::Geometry that it's attached to so can't jump in a do
the addVertexBufferObjectIfRequired(), we could automatically assigned
a local VBO when the Binding is set to BIND_PER_VERTEX but this would
then lead to lots of separate VBO's being created all over the place
where they aren't needed, and would blow up memory and performance.

Another avenue is perhaps to try and make the code a bit more
resilient to a VBO being assigned or not.  I don't know exactly why we
are getting crash in the draw code so I'll look into this next.

Robert.


More information about the osg-users mailing list