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

[Voerman, L.]

Hi Daniel,
I don't understand why your modification to addPrimitiveSet() resolves your
issue with the openflight plugin, as it's called before the proper array
bindings have been set (src\osgPlugins\OpenFlight\GeometryRecords.cpp line
601)
Can your problem be avoided by changing
if (geometry->getColorArray())
geometry->getColorArray()->setBinding(osg::Array::BIND_PER_VERTEX);
to
if (geometry->getColorArray()) geometry->setColorArray(
geometry->getColorArray(), osg::Array::BIND_PER_VERTEX);
and
if (geometry->getNormalArray())
geometry->getNormalArray()->setBinding(osg::Array::BIND_PER_VERTEX);
by
if (geometry->getNormalArray()) geometry->setNormalArray(
geometry->getNormalArray(), osg::Array::BIND_PER_VERTEX);

(both changes appear two times in
src\osgPlugins\OpenFlight\GeometryRecords.cpp )
Regards, Laurens.

On Mon, Jun 11, 2018 at 3:37 PM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180611/d4c3f586/attachment.html>