Hi Laurens, Thanks for the response.
I’m not super familiar with the back-end of OSG. I tried to tackle the problem by looking for possible insertion points for the addVertexBufferObjectIfRequired(), in a way that won’t break binary compatibility. This attempt did fix the crash for me in the dozen files I attempted to load. I debugged a bit more at your prodding. It’s working for me because the models that I am loading are reusing arrays in multiple primitive sets. As I load the models, each of them has thousands of calls to setBinding(), but tens of thousands of primitive sets, most occurring well after the setBinding() calls. This implies array reuse to me. Yes, the problem can definitely be avoided by editing the FLT plugin. However, this problem occurred in lots of our own user code (unrelated to FLT), and in osgEarth too. My first naïve approach was to fix all locations that set up arrays to configure binding before setting the array. But there are so many, and any missed one will cause a crash. I’ve been months into my OSG 3.6 (and GL3 core profile) upgrade before encountering this bug; how many more are waiting? This used to be valid usage in the sense that it used to work in 3.4, and presumably is still valid because setBinding() is still public, not deprecated, and there’s no warnings in the code to avoid this condition. That’s part of the reason for my original email – if this is not a valid use case, then someone’s going to have to find and fix all the violations in OSG code like FLT. I don’t mind taking a crack at it since it impacts me, but I’d rather fix the source of the problem than every symptom. What you’ve posted below is definitely my fallback if the problem can’t be solved by changing osg::Array/Geometry. - Dan ============================ Dan Emminizer Code 5773.40 Naval Research Laboratory https://simdis.nrl.navy.mil<https://simdis.nrl.navy.mil/> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Voerman, L. Sent: Monday, June 11, 2018 10:26 AM To: OpenSceneGraph Users Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays 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.emmini...@nrl.navy.mil<mailto:dan.emmini...@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-boun...@lists.openscenegraph.org<mailto:osg-users-boun...@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.emmini...@nrl.navy.mil<mailto:dan.emmini...@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@lists.openscenegraph.org<mailto:osg-users@lists.openscenegraph.org> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
