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] 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> 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 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
