<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.im
{mso-style-name:im;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Laurens,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks for the response.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">What you’ve posted below is definitely my fallback if the problem can’t be solved by changing osg::Array/Geometry.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">- Dan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">============================<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Dan Emminizer<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Code 5773.40<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Naval Research Laboratory<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
<a href="https://simdis.nrl.navy.mil/">https://simdis.nrl.navy.mil</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> osg-users [mailto:osg-users-bounces@lists.openscenegraph.org]
<b>On Behalf Of </b>Voerman, L.<br>
<b>Sent:</b> Monday, June 11, 2018 10:26 AM<br>
<b>To:</b> OpenSceneGraph Users<br>
<b>Subject:</b> Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Daniel,<o:p></o:p></p>
<div>
<p class="MsoNormal">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)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Can your problem be avoided by changing<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">if (geometry->getColorArray()) geometry->getColorArray()->setBinding(osg::Array::BIND_PER_VERTEX);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">if (geometry->getColorArray()) <span style="background:white">
geometry->setColorArray( geometry->getColorArray(), osg::Array::BIND_PER_VERTEX);</span>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">if (geometry->getNormalArray()) geometry->getNormalArray()->setBinding(osg::Array::BIND_PER_VERTEX);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">by<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">if (geometry->getNormalArray()) geometry->setNormalArray( <span style="background:white">
geometry->getNormalArray(),</span> osg::Array::BIND_PER_VERTEX);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">(both changes appear two times in <span style="background:white">
src\osgPlugins\OpenFlight\GeometryRecords.cpp</span> )<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Regards, Laurens.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, Jun 11, 2018 at 3:37 PM, Daniel Emminizer, Code 5773 <<a href="mailto:dan.emminizer@nrl.navy.mil" target="_blank">dan.emminizer@nrl.navy.mil</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi Robert,<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
During the draw traversal, as a result, the Array::getBinding() flag does not match the VBO state in Geometry.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<span class="im">Thanks,</span><br>
<br>
<span class="im"> - Dan</span><br>
<br>
<br>
<br>
<span class="im">> -----Original Message-----</span><br>
<span class="im">> From: Daniel Emminizer, Code 5773</span><br>
<span class="im">> Sent: Monday, June 04, 2018 8:45 AM</span><br>
<span class="im">> To: OpenSceneGraph Users</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">> Subject: RE: [osg-users] VBO Bug with 3.6.1 and Normal Arrays<br>
> <br>
> Hi Robert,<br>
> <br>
> The file you sent is identical to the one I sent. Was that intentional? You also<br>
> mention Cessna; do you have the examples mixed up perhaps?<br>
> <br>
> The bug will manifest if the geometry's normal array (and presumably fog,<br>
> colors, etc) are set before the array binding type is set. It's entirely possible<br>
> to have correctly loaded models. I only ran across this because the<br>
> OpenFlight loader sets the binding late.<br>
> <br>
> <br>
> This bug prints on console:<br>
> <br>
> Warning: detected OpenGL error 'invalid operation' at after<br>
> drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable&<br>
> drawable)<br>
> <br>
> <br>
> No change in error message with with OSG_GL_ERROR_CHECKING=on. No<br>
> change in error message with --ro, with --reset, or with --ro --reset.<br>
> <br>
> I am building OSG 3.6.1 (and tried OpenSceneGraph-3.6) in core profile on<br>
> Windows 10. Video card data is:<br>
> <br>
> Vendor = NVIDIA Corporation<br>
> Renderer = NVS 510/PCIe/SSE2<br>
> Version = 3.3.0 NVIDIA 388.19<br>
> GLSL Version = 330<br>
> <br>
> <br>
> Responses from me will be slow this week; my email access will be spotty.<br>
> <br>
> Hope this helps. Thanks,<br>
> <br>
> - Dan<br>
> <br>
> <br>
> <br>
> > -----Original Message-----<br>
> > From: osg-users [mailto:<a href="mailto:osg-users-bounces@lists.openscenegraph.org">osg-users-bounces@lists.openscenegraph.org</a>] On<br>
> > Behalf Of Robert Osfield<br>
> > Sent: Sunday, June 03, 2018 6:11 AM<br>
> > To: OpenSceneGraph Users<br>
> > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays<br>
> ><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">> > Hi Dan,<br>
> ><br>
> > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773<br>
> > <<a href="mailto:dan.emminizer@nrl.navy.mil">dan.emminizer@nrl.navy.mil</a>> wrote:<br>
> > > Attached is a demo of the problem that generates a console warning.<br>
> > More complex scenes can cause crashes. The red triangle has the problem,<br>
> > but the green one does not.<br>
> ><br>
> > I have built the example, and to help with test have changed the #ifdef<br>
> > blocks to ones that check arguments.read("--ro") for the RealizerOperation<br>
> > usage and "--reset" for the<br>
> > resetVertexAttributeAlias. Attached is the modified file.<br>
> ><br>
> > If you run the test with --ro and have it use the custom RealizerOperation I<br>
> > see a completely red cessna. If I used --ro and --reset I see multi-colour<br>
> > (blue, red etc) one, if I run without any options I see the multi-colour one.<br>
> ><br>
> > I don't see any command line warnings though. I'm testing under Kubuntu<br>
> > with OSG-3.6 branch, my drive info is:<br>
> ><br>
> > OpenGL vendor string: NVIDIA Corporation OpenGL renderer string:<br>
> GeForce<br>
> > GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA<br>
> 384.111<br>
> > OpenGL core profile shading language version string: 4.50 NVIDIA<br>
> ><br>
> > I don't yet have any idea what is going wrong, it's obviously very odd that<br>
> the<br>
> > custom RealizeOperation is having an effect when it does nothing itself.<br>
> ><br>
> > Before I start diving deeper I'd like to know what others are seeing with<br>
> > these different combinations and if any errors are being printed in the<br>
> > console, if so what are they. Also let us know the OSG version and<br>
> driver/OS<br>
> > details.<br>
> ><br>
> > Robert.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>