<div dir="ltr">Could this be why I'm not getting my colors?<div><br></div><div>Cheers,</div><div>Brad</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 1, 2018 at 8:51 AM, Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dan,<br>
<br>
Thanks for the explanation and example to reproduce the bug... Guess<br>
it looks like we'll need to make 3.6.2 rather sooner than I was<br>
hoping, it'll be one a month at this rate...<br>
<br>
Robert.<br>
<br>
On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773<br>
<div><div class="h5"><<a href="mailto:dan.emminizer@nrl.navy.mil">dan.emminizer@nrl.navy.mil</a>> wrote:<br>
> Hi Robert,<br>
><br>
> Oops -- I sent this earlier today but apparently to the bounces list; that explains the confusion on GitHub -- my mistake.  This was supposedly sent right before I posted the PR.  Here's the original text:<br>
><br>
><br>
> I think I found a bug in 3.6.1.  I am loading a FLT model and it's causing a crash in my application to draw it.  The same model does not crash in OSG 3.4.  I think I've finally tracked down the cause and have a candidate solution too.<br>
><br>
> A few weeks back I saw a similar crash in my own code, and figured it was due to incorrect usage of the binding flags on osg::Array.  Much of our code was using osg::Geometry::<wbr>setNormalBinding() (and related methods).  During debugging, I was able to determine my normals were crashing in 3.6, and the problem went away when I used the osg::Array(osg::Array::<wbr>Binding) signature -- i.e. assigning a binding on construction.  At the time I thought it was something I was doing wrong and moved on.<br>
><br>
> The problem showed up again earlier this week but not in my code, and not manifesting in exactly the same way.  Here's the run-down of what's going on:<br>
><br>
> - Loading FLT model<br>
> - FLT model loads a face, which has vertices, textures, and normals<br>
> - FLT uses getOrCreateNormalArray(), which allocates an array (BIND_UNDEFINED) and sets it on the geometry<br>
> - Geometry::<wbr>addVertexBufferObjectIfRequire<wbr>d() is called on the normals, but nothing done due to BIND_UNDEFINED<br>
> - FLT later sets normals to BIND_PER_VERTEX appropriately, which is a direct set and does not do anything to the Geometry's VBOs<br>
> - First frame starts to render<br>
> - Geometry::drawVAImpl calls vas->setNormalArray()<br>
> - VertexArrayState::setArray() calls new_array-><wbr>getOrCreateGLBufferObject(), which returns 0.  This is the first major problem.<br>
> - Because vbo is NULL, unbindindVertexBufferObject() is called, leading to GL_ARRAY_BUFFER to go to 0<br>
> - vad->enable_and_dispatch() gets called and does glVertexAttribPointer() with a non-NULL data ptr, which is a GL error because array buffer is 0<br>
><br>
> Unwinding the error:<br>
> - enable_and_dispatch() shouldn't be called if ptr is non-NULL and no GL_ARRAY_BUFFER is 0<br>
> - GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the normal array<br>
> - There is no normal array because the only place it seems to be created is in setNormalArray(), which fails because at that time, it is BIND_UNDEFINED<br>
> - Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after setNormalArray(), leading to the error<br>
><br>
> There are several possible solutions I can see.  You can probably see more:<br>
> 1) Change FLT plugin to assign array binding per vertex on construction of array.  Seems poor because invariably this bug is crashing other code -- maybe it's the cause of the DXF that Brian Hutchison reported earlier this week?<br>
> 2) Update Array::setBinding() to create the VBO if needed.  I do not know if this is possible nor how to do it.<br>
> 3) "Lazily" detect this issue somewhere in the rendering calls and create VBO there if necessary<br>
><br>
><br>
><br>
> PR 554 was an attempt at approach #3 but I agree with your assessment on GitHub.  It does not solve the problem in all cases.<br>
><br>
> 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.<br>
><br>
>  - Dan<br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> osg-users mailing list<br>
> <a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.<wbr>openscenegraph.org</a><br>
> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.<wbr>org/listinfo.cgi/osg-users-<wbr>openscenegraph.org</a><br>
><br>
______________________________<wbr>_________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.<wbr>openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.<wbr>org/listinfo.cgi/osg-users-<wbr>openscenegraph.org</a><br>
</blockquote></div><br></div>