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

Mon Jun 11 08:19:02 PDT 2018

Hi Robert,

I have committed and pushed my solution at https://github.com/emminizer/OpenSceneGraph/commit/4d2601e05e96aa

It's on my branch https://github.com/emminizer/OpenSceneGraph/tree/crash-vbo-array-bindings

As Laurens pointed out earlier, it may not catch all use cases, including some important ones.  I'm (mildly) confident that the solution is to detect the change in array bindings and call addVertexBuffObjectIfRequired() -- but I just don't know the right insertion point in the code to do this.

I hope this helps in some way.

 - Dan

> -----Original Message-----
> From: osg-users [mailto:osg-users-bounces at lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, June 11, 2018 10:48 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> 
> Hi Daniel,
> 
> Thanks for looking further into this.  I did some investigation
> originally but didn't get to the bottom of the issue.  FYI, the
> support for Vertex Array Objects is what instigated these changes to
> way that VBO's had to be managed.  Essentially all osg::Array with per
> vertex bindings now need have a a VertexBufferObject assigned.
> 
> If you have made a commit for this fix against your own git clone of
> the OSG just pointing me at this commit should help me understand what
> is going on better.
> 
> Cheers,
> Robert.
> On Mon, 11 Jun 2018 at 14:44, Daniel Emminizer, Code 5773
> <dan.emminizer at nrl.navy.mil> wrote:
> >
> > Hi Robert,
> >
> > I am back from travel and looking at this again.  Didn't get a response on last
> set of questions about this crash.  Sorry to distract from the Vulkan work -- it
> sounds interesting, and I'm watching your progress there excitedly.
> >
> >
> > Core problem seems to be that Array::setBinding() can change after
> Geometry::set*Array().  Geometry::set*Array() is responsible for calling
> addVertexBufferObjectIfRequired(), and doesn't have enough information
> to correctly do so.
> >
> > During the draw traversal, as a result, the Array::getBinding() flag does not
> match the VBO state in Geometry.
> >
> > One solution is to create the VBO as needed (using
> addVertexBufferObjectIfRequired) sometime between the start of cull
> phase and before the Geometry::drawImplementation().  But
> drawImplementation() is const, and not a place where this can happen.
> >
> >
> > Another possible solution that might help is to modify
> Geometry::setPrimitiveSet() and addPrimitiveSet() to call
> addVertexBufferObjectIfRequired() on the various arrays.  I prototyped this
> solution locally and it resolved the issue in the FLT loader.  I know it's not
> perfect, but most places I've seen that would trigger this bug have defined
> an array binding by the time a primitive set is added.
> >
> > Should I submit a PR for this approach?  It keeps binary compatibility and is
> fairly straightforward, and helps my immediate crash out of FLT and most of
> the other use cases I've encountered.
> >
> > Thanks,
> >
> >  - Dan
> >
> >
> >
> > > -----Original Message-----
> > > From: Daniel Emminizer, Code 5773
> > > Sent: Monday, June 04, 2018 8:45 AM
> > > To: OpenSceneGraph Users
> > > Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> > >
> > > Hi Robert,
> > >
> > > The file you sent is identical to the one I sent.  Was that intentional?  You
> also
> > > mention Cessna; do you have the examples mixed up perhaps?
> > >
> > > The bug will manifest if the geometry's normal array (and presumably
> fog,
> > > colors, etc) are set before the array binding type is set.  It's entirely
> possible
> > > to have correctly loaded models.  I only ran across this because the
> > > OpenFlight loader sets the binding late.
> > >
> > >
> > > This bug prints on console:
> > >
> > > Warning: detected OpenGL error 'invalid operation' at after
> > > drawable.compileGLObjects() call in
> GLObjectsVisitor::apply(osg::Drawable&
> > > drawable)
> > >
> > >
> > > No change in error message with with OSG_GL_ERROR_CHECKING=on.
> No
> > > change in error message with --ro, with --reset, or with --ro --reset.
> > >
> > > I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on
> > > Windows 10.  Video card data is:
> > >
> > > Vendor = NVIDIA Corporation
> > > Renderer = NVS 510/PCIe/SSE2
> > > Version = 3.3.0 NVIDIA 388.19
> > > GLSL Version = 330
> > >
> > >
> > > Responses from me will be slow this week; my email access will be
> spotty.
> > >
> > > Hope this helps.  Thanks,
> > >
> > >  - Dan
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: osg-users [mailto:osg-users-bounces at lists.openscenegraph.org]
> On
> > > > Behalf Of Robert Osfield
> > > > Sent: Sunday, June 03, 2018 6:11 AM
> > > > To: OpenSceneGraph Users
> > > > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
> > > >
> > > > Hi Dan,
> > > >
> > > > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
> > > > <dan.emminizer at nrl.navy.mil> wrote:
> > > > > Attached is a demo of the problem that generates a console warning.
> > > > More complex scenes can cause crashes.  The red triangle has the
> problem,
> > > > but the green one does not.
> > > >
> > > > I have built the example, and to help with test have changed the #ifdef
> > > > blocks to ones that check arguments.read("--ro") for the
> RealizerOperation
> > > > usage and "--reset" for the
> > > > resetVertexAttributeAlias.   Attached is the modified file.
> > > >
> > > > If you run the test with --ro and have it use the custom
> RealizerOperation I
> > > > see a completely red cessna.  If I used --ro and --reset I see multi-colour
> > > > (blue, red etc) one, if I run without any options I see the multi-colour
> one.
> > > >
> > > > I don't see any command line warnings though.  I'm testing under
> Kubuntu
> > > > with OSG-3.6 branch, my drive info is:
> > > >
> > > > OpenGL vendor string: NVIDIA Corporation OpenGL renderer string:
> > > GeForce
> > > > GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
> > > 384.111
> > > > OpenGL core profile shading language version string: 4.50 NVIDIA
> > > >
> > > > I don't yet have any idea what is going wrong, it's obviously very odd
> that
> > > the
> > > > custom RealizeOperation is having an effect when it does nothing itself.
> > > >
> > > > Before I start diving deeper I'd like to know what others are seeing with
> > > > these different combinations and if any errors are being printed in the
> > > > console, if so what are they.  Also let us know the OSG version and
> > > driver/OS
> > > > details.
> > > >
> > > > Robert.
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org