Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Robert, I agree that your solution here seems to cover the common failure case (assigning by-vertex too late). I think given the system constraints and time constraints, that is the best solution. Your solution does work in all my testing. Regarding a 3.6.2 release, that sounds great. At this point we've upgraded almost all of our applications and this was the last major issue we had. We've still got one minor text output annoyance, and I'll start a new thread on that once I track it down if it's a change in OSG causing it. I'll do that in the next couple of days here. Thanks, - Dan > -Original Message- > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On > Behalf Of Robert Osfield > Sent: Thursday, June 14, 2018 4:10 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays > > H Dan et. al, > > On Thu, 14 Jun 2018 at 08:25, Robert Osfield > wrote: > > Perhaps another approach would be to just warn the user that the > > Binding hasn't been set prior to the Geometry::set*Array() call, or do > > a belt and braces of treat an BIND_UNDEFINED binding as a > > BIND_PER_VERTEX to force a VertexBufferObject to be assign > > automatically even though it might not be needed. This might waste a > > byte or two but would probably be safe. > > This is the approach I have taken, it fixes the test program when > VAO's are used and the array::setBinding(..) is called after the > Geometry::set*Array() call. > > > https://github.com/openscenegraph/OpenSceneGraph/commit/4665a2f033 > 68be95f4773463f733dbdd88f63c5f > > I think it's the safest and least intrusive way to catch late calls to > setBinding(..). > > Could you all test the OpenSceneGraph-3.6 head and if this works fine > we can start thinking about going for 3.6.2. > > Robert. > ___ > osg-users mailing list > 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
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
H Dan et. al, On Thu, 14 Jun 2018 at 08:25, Robert Osfield wrote: > Perhaps another approach would be to just warn the user that the > Binding hasn't been set prior to the Geometry::set*Array() call, or do > a belt and braces of treat an BIND_UNDEFINED binding as a > BIND_PER_VERTEX to force a VertexBufferObject to be assign > automatically even though it might not be needed. This might waste a > byte or two but would probably be safe. This is the approach I have taken, it fixes the test program when VAO's are used and the array::setBinding(..) is called after the Geometry::set*Array() call. https://github.com/openscenegraph/OpenSceneGraph/commit/4665a2f03368be95f4773463f733dbdd88f63c5f I think it's the safest and least intrusive way to catch late calls to setBinding(..). Could you all test the OpenSceneGraph-3.6 head and if this works fine we can start thinking about going for 3.6.2. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Daniel, On Wed, 13 Jun 2018 at 23:29, Daniel Emminizer, Code 5773 wrote: > I don't know enough about the inner workings to know if this is a dumb idea > -- but could you perhaps detect the problem during cull (VBO attachment is > NULL but array exists and is non-empty), then call > addVertexBufferObjectIfRequired() on the geometry between the cull and the > draw phases? Given my brief exposure to Renderer.cpp, I think that is easier > to say than do... Cull can be multi-threaded so calling addVertexufferObjectIfRequired() could cause a race condition. > > > Just got your new email -- right, the VBO=0 occurs because the array never > gets a VBO from array->setVertexBufferObject(). Because of this, > VertexArrayState::setArray() gets 0 when it calls getOrCreateGLBufferObject(). Yes, the osg::Array in question never has a osg::VertexBufferObject so you can't create GLBufferObject for it. One possibility would be to have the GLObjectsVsitor run single threaded and do the check, but this won't catch geometry that is created on the fly. Perhaps another approach would be to just warn the user that the Binding hasn't been set prior to the Geometry::set*Array() call, or do a belt and braces of treat an BIND_UNDEFINED binding as a BIND_PER_VERTEX to force a VertexBufferObject to be assign automatically even though it might not be needed. This might waste a byte or two but would probably be safe. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Robert, That would cover our primary use cases. We've already done the same in all of our application code. Catching the failure instead of crashing is very much preferred, even if it leads to a bad display. I'm on board with this solution and can help test my end. - Dan > -Original Message- > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On > Behalf Of Robert Osfield > Sent: Wednesday, June 13, 2018 3:28 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays > > I am moving towards the idea that we may only be able to catch on the > fly bad usage and disable the arrays that don't have a VBO assigned > when trying to render with VAO, and emit a warning. this will be > better than having an application crash. > > I'm going to re-factor the existing places in the OSG where the later > Array::setBinding() is being used so that doesn't cause problems, this > will at least make the above problem case less likely. This won't fix > application code that needs to be amended though. > > Robert. > ___ > osg-users mailing list > 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
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
I am moving towards the idea that we may only be able to catch on the fly bad usage and disable the arrays that don't have a VBO assigned when trying to render with VAO, and emit a warning. this will be better than having an application crash. I'm going to re-factor the existing places in the OSG where the later Array::setBinding() is being used so that doesn't cause problems, this will at least make the above problem case less likely. This won't fix application code that needs to be amended though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Robert,
I agree with your analysis on all points. I did not see a quick solution that
was "proper" either.
I agree that creating temporary VBOs doesn't seem like a wise solution.
I don't know enough about the inner workings to know if this is a dumb idea --
but could you perhaps detect the problem during cull (VBO attachment is NULL
but array exists and is non-empty), then call addVertexBufferObjectIfRequired()
on the geometry between the cull and the draw phases? Given my brief exposure
to Renderer.cpp, I think that is easier to say than do...
Just got your new email -- right, the VBO=0 occurs because the array never gets
a VBO from array->setVertexBufferObject(). Because of this,
VertexArrayState::setArray() gets 0 when it calls getOrCreateGLBufferObject().
Yes, in GL3 VAO is required, and VAO requires VBO. We do require VAO and VBO
in our application, because due to customer requirements we need to be
targeting (or start targeting) the core profile.
- Dan
> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, June 13, 2018 1:06 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
>
> Hi Dan, et. al,
>
> I haven't yet got to bottom of this issue, but so far it looks like
> doing the Array::setBinding(Array::BIND_PER_VERTEX) call later than
> the array itself is assigned to the geometry bypasses the mechanism
> that osg::Geometry uses to make sure all the arrays that need a VBO
> have one assigned.
>
> To clarify this issue further I've made the
> Geometry::addVertexBufferObjectIfRequired() public so I can see if
> calling this after the late Array::setBinding(). This isn't a
> solution, just another workaround, but for me mainly a means of
> testing a hypothos, to the problem late binding code I added the
> geom->addVertexBufferObjectIfRequired(normals); call:
>
> if (!earlyBinding)
> {
> normals->setBinding(osg::Array::BIND_PER_VERTEX);
> geom->addVertexBufferObjectIfRequired(normals);
> }
>
> This enables the test program to run properly without crash or
> warnings, both triangles now behave the same regardless of the early
> or late setBinding. However, this isn't a proper solution, it won't
> fix problem without amending late setBinding() codes in the OSG or in
> client applications. For these cases they really should be calling
> setBinding prior to the Geometry:set*Array() methods.
>
> As things stand I can't see easy solution as the Array doesn't know
> about the osg::Geometry that it's attached to so can't jump in a do
> the addVertexBufferObjectIfRequired(), we could automatically assigned
> a local VBO when the Binding is set to BIND_PER_VERTEX but this would
> then lead to lots of separate VBO's being created all over the place
> where they aren't needed, and would blow up memory and performance.
>
> Another avenue is perhaps to try and make the code a bit more
> resilient to a VBO being assigned or not. I don't know exactly why we
> are getting crash in the draw code so I'll look into this next.
>
> Robert.
> ___
> osg-users mailing list
> 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
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi All, I've started investigating what is happening in the VertexArrayState that is passing the array data to OpenGL. When things are all set up correctly w.r.t VBO assignment to the Arrays we get: VertexArrayState::setArray(VertexArrayDispatch, new_array=0x1092250 vbo=0x7f583c09d210 VertexArrayState::setArray(NormalArrayDispatch, new_array=0x1092310 vbo=0x7f583c09d210 VertexArrayState::setArray(VertexArrayDispatch, new_array=0x1092b60 vbo=0x7f583c09f320 VertexArrayState::setArray(NormalArrayDispatch, new_array=0x1092c80 vbo=0x7f583c09f320 But for the late setBinding() usage case we have: ertexArrayState::setArray(VertexArrayDispatch, new_array=0x870250 vbo=0x7f0e4809d210 VertexArrayState::setArray(NormalArrayDispatch, new_array=0x870310 vbo=0 Warning: detected OpenGL error 'invalid operation' at after drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable& drawable) VertexArrayState::setArray(VertexArrayDispatch, new_array=0x870b60 vbo=0x7f0e4809f400 VertexArrayState::setArray(NormalArrayDispatch, new_array=0x870c80 vbo=0x7f0e4809f400 Note the vbo=0 followed by the OpenGL error, and later by a crash. Commenting out the geom->setUserVertexArrayObjects(true) in the main.cpp test program so that only VBO's and direct array calls are done the GL error disappears and no crash. So it's Vertex Array Objects to is the problem area. I vague recollection that VAO's requires VBO's, but it's been a while since I added the VAO support so not 100% sure. More investigation is required... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Dan, et. al,
I haven't yet got to bottom of this issue, but so far it looks like
doing the Array::setBinding(Array::BIND_PER_VERTEX) call later than
the array itself is assigned to the geometry bypasses the mechanism
that osg::Geometry uses to make sure all the arrays that need a VBO
have one assigned.
To clarify this issue further I've made the
Geometry::addVertexBufferObjectIfRequired() public so I can see if
calling this after the late Array::setBinding(). This isn't a
solution, just another workaround, but for me mainly a means of
testing a hypothos, to the problem late binding code I added the
geom->addVertexBufferObjectIfRequired(normals); call:
if (!earlyBinding)
{
normals->setBinding(osg::Array::BIND_PER_VERTEX);
geom->addVertexBufferObjectIfRequired(normals);
}
This enables the test program to run properly without crash or
warnings, both triangles now behave the same regardless of the early
or late setBinding. However, this isn't a proper solution, it won't
fix problem without amending late setBinding() codes in the OSG or in
client applications. For these cases they really should be calling
setBinding prior to the Geometry:set*Array() methods.
As things stand I can't see easy solution as the Array doesn't know
about the osg::Geometry that it's attached to so can't jump in a do
the addVertexBufferObjectIfRequired(), we could automatically assigned
a local VBO when the Binding is set to BIND_PER_VERTEX but this would
then lead to lots of separate VBO's being created all over the place
where they aren't needed, and would blow up memory and performance.
Another avenue is perhaps to try and make the code a bit more
resilient to a VBO being assigned or not. I don't know exactly why we
are getting crash in the draw code so I'll look into this next.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Dan, Oopps, like I was using another VBO bug test program earlier, and fixed an entirely separate bug The one I was testing had a issue with normals on the cessna model. Still another bug fixed, that's good. Trying your test program out with the latest OpenSceneGraph-3.6 default build (so GL2) I get a crash: ./arraybug Warning: detected OpenGL error 'invalid operation' at after drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable& drawable) Segmentation fault (core dumped) I haven't tried GLCORE build yet. Robert. On Wed, 13 Jun 2018 at 16:59, Daniel Emminizer, Code 5773 wrote: > > Hi Robert, > > Thanks for this change. Unfortunately it does not look like it fixes my > issue. > > I'm building GL3 core profile mode against OpenSceneGraph-3.6. I use the > main.cpp and CMakeLists.txt from my 6/1/18 email. I'm using NVidia card with > NVS 510, driver 388.19, OpenGL version 3.3.0 (due to core profile flag). It > is Windows 10. > > I still see the error: > Warning: detected OpenGL error `invalid operation` at after > drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable& > drawable) > > I have no modifications to OSG. I did a full rebuild from scratch on OSG. > > > > What I believe is the problem is that the the VertexArrayState object > > gets initialized by the realizer operation and uses the > > State::getUseVertexAttributeAliasing() that was current at the time of > > the realizer operation, then code then calls > > State::setUseVertexAttributeAliasing() afterwards to a different > > value, so the rest of the OSG assumes that is now the current value > > but the global VertexArrayState is still set up against the original > > value so is passing using GL vertex array settings that are > > inconsistent with the shaders. > > This is the second email you've mentioned the realizer operation. I do not > understand what you're referring to; this is very likely my inexperience with > the depth of OSG. Do you mean the code that eventually calls and includes > Geometry::drawVertexArraysImplementation()? > > I do not see any code that calls State::setUseVertexAttributeAliasing() in > osg/src/*/*, or in osg/include/*/*. I don't call it in main.cpp either (and > if I did, I would only call it at startup, not on each geometry creation). > > Are we running the same main.cpp? I'm attaching my original just in case. > > Thanks, > > - Dan > > > > > -Original Message- > > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On > > Behalf Of Robert Osfield > > Sent: Wednesday, June 13, 2018 7:45 AM > > To: OpenSceneGraph Users > > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays > > > > Hi Dan et. al, > > > > I have had another look into this issue, looked at Dan's workaround > > and used Dan's test example to see investigate what might be going on. > > I have checked in a fix: > > > > > > https://github.com/openscenegraph/OpenSceneGraph/commit/673292b995 > > 115c6ca9a3cc82c26e05023f504774 > > > > This allows the test example to work correctly in all different > > combinations with the realizer operation on/off etc. > > > > What I believe is the problem is that the the VertexArrayState object > > gets initialized by the realizer operation and uses the > > State::getUseVertexAttributeAliasing() that was current at the time of > > the realizer operation, then code then calls > > State::setUseVertexAttributeAliasing() afterwards to a different > > value, so the rest of the OSG assumes that is now the current value > > but the global VertexArrayState is still set up against the original > > value so is passing using GL vertex array settings that are > > inconsistent with the shaders. > > > > The solution is simple reassign the VertexArrayState for each call to > > State::setUseVertexAttributeAliasing(). > > > > I have only tested with Dan's test program, there is chance that other > > usage cases might tease out the issue in a different way, fingers > > crossed the just solves all these issue. > > > > Could users who've seen issues with the arrays being used correctly > > update to the head of the OpenSceneGraph-3.6 branch and let me know > > how you get on. > > > > If this all works fine then we can start looking at a release of 3.6.2 > > this month. > > > > Cheers, > > Robert. > > ___ > > osg-users mailing list > > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Robert,
Thanks for this change. Unfortunately it does not look like it fixes my issue.
I'm building GL3 core profile mode against OpenSceneGraph-3.6. I use the
main.cpp and CMakeLists.txt from my 6/1/18 email. I'm using NVidia card with
NVS 510, driver 388.19, OpenGL version 3.3.0 (due to core profile flag). It is
Windows 10.
I still see the error:
Warning: detected OpenGL error `invalid operation` at after
drawable.compileGLObjects() call in GLObjectsVisitor::apply(osg::Drawable&
drawable)
I have no modifications to OSG. I did a full rebuild from scratch on OSG.
> What I believe is the problem is that the the VertexArrayState object
> gets initialized by the realizer operation and uses the
> State::getUseVertexAttributeAliasing() that was current at the time of
> the realizer operation, then code then calls
> State::setUseVertexAttributeAliasing() afterwards to a different
> value, so the rest of the OSG assumes that is now the current value
> but the global VertexArrayState is still set up against the original
> value so is passing using GL vertex array settings that are
> inconsistent with the shaders.
This is the second email you've mentioned the realizer operation. I do not
understand what you're referring to; this is very likely my inexperience with
the depth of OSG. Do you mean the code that eventually calls and includes
Geometry::drawVertexArraysImplementation()?
I do not see any code that calls State::setUseVertexAttributeAliasing() in
osg/src/*/*, or in osg/include/*/*. I don't call it in main.cpp either (and if
I did, I would only call it at startup, not on each geometry creation).
Are we running the same main.cpp? I'm attaching my original just in case.
Thanks,
- Dan
> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Wednesday, June 13, 2018 7:45 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
>
> Hi Dan et. al,
>
> I have had another look into this issue, looked at Dan's workaround
> and used Dan's test example to see investigate what might be going on.
> I have checked in a fix:
>
>
> https://github.com/openscenegraph/OpenSceneGraph/commit/673292b995
> 115c6ca9a3cc82c26e05023f504774
>
> This allows the test example to work correctly in all different
> combinations with the realizer operation on/off etc.
>
> What I believe is the problem is that the the VertexArrayState object
> gets initialized by the realizer operation and uses the
> State::getUseVertexAttributeAliasing() that was current at the time of
> the realizer operation, then code then calls
> State::setUseVertexAttributeAliasing() afterwards to a different
> value, so the rest of the OSG assumes that is now the current value
> but the global VertexArrayState is still set up against the original
> value so is passing using GL vertex array settings that are
> inconsistent with the shaders.
>
> The solution is simple reassign the VertexArrayState for each call to
> State::setUseVertexAttributeAliasing().
>
> I have only tested with Dan's test program, there is chance that other
> usage cases might tease out the issue in a different way, fingers
> crossed the just solves all these issue.
>
> Could users who've seen issues with the arrays being used correctly
> update to the head of the OpenSceneGraph-3.6 branch and let me know
> how you get on.
>
> If this all works fine then we can start looking at a release of 3.6.2
> this month.
>
> Cheers,
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
#include
#include
#include
#include
osg::Node* createTriangle(float x, bool earlyBinding, const osg::Vec4f& color)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;
geom->setUseVertexArrayObject(true);
geom->setUseVertexBufferObjects(true);
osg::Vec3Array* vertices = new osg::Vec3Array();
vertices->push_back(osg::Vec3(x - 100, 0, -100));
vertices->push_back(osg::Vec3(x, 0, 100));
vertices->push_back(osg::Vec3(x, 0, -100));
osg::Vec3Array* normals = new osg::Vec3Array;
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
if (earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);
osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_OVERALL);
colors->push_back(color);
geom->addPrimitiveSet(new osg::DrawArrays(GL_TRIANGLES, 0, 3));
geom->setVertexArray(vertices);
geom->setNormalArray(normals);
ge
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Dan et. al, I have had another look into this issue, looked at Dan's workaround and used Dan's test example to see investigate what might be going on. I have checked in a fix: https://github.com/openscenegraph/OpenSceneGraph/commit/673292b995115c6ca9a3cc82c26e05023f504774 This allows the test example to work correctly in all different combinations with the realizer operation on/off etc. What I believe is the problem is that the the VertexArrayState object gets initialized by the realizer operation and uses the State::getUseVertexAttributeAliasing() that was current at the time of the realizer operation, then code then calls State::setUseVertexAttributeAliasing() afterwards to a different value, so the rest of the OSG assumes that is now the current value but the global VertexArrayState is still set up against the original value so is passing using GL vertex array settings that are inconsistent with the shaders. The solution is simple reassign the VertexArrayState for each call to State::setUseVertexAttributeAliasing(). I have only tested with Dan's test program, there is chance that other usage cases might tease out the issue in a different way, fingers crossed the just solves all these issue. Could users who've seen issues with the arrays being used correctly update to the head of the OpenSceneGraph-3.6 branch and let me know how you get on. If this all works fine then we can start looking at a release of 3.6.2 this month. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Robert, I have committed and pushed my solution at https://github.com/emminizer/OpenSceneGraph/commit/4d2601e05e96aa It's on my branch https://github.com/emminizer/OpenSceneGraph/tree/crash-vbo-array-bindings As Laurens pointed out earlier, it may not catch all use cases, including some important ones. I'm (mildly) confident that the solution is to detect the change in array bindings and call addVertexBuffObjectIfRequired() -- but I just don't know the right insertion point in the code to do this. I hope this helps in some way. - Dan > -Original Message- > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On > Behalf Of Robert Osfield > Sent: Monday, June 11, 2018 10:48 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays > > Hi Daniel, > > Thanks for looking further into this. I did some investigation > originally but didn't get to the bottom of the issue. FYI, the > support for Vertex Array Objects is what instigated these changes to > way that VBO's had to be managed. Essentially all osg::Array with per > vertex bindings now need have a a VertexBufferObject assigned. > > If you have made a commit for this fix against your own git clone of > the OSG just pointing me at this commit should help me understand what > is going on better. > > Cheers, > Robert. > On Mon, 11 Jun 2018 at 14:44, Daniel Emminizer, Code 5773 > 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 > > > > &g
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
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 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 ex
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Daniel,
Thanks for looking further into this. I did some investigation
originally but didn't get to the bottom of the issue. FYI, the
support for Vertex Array Objects is what instigated these changes to
way that VBO's had to be managed. Essentially all osg::Array with per
vertex bindings now need have a a VertexBufferObject assigned.
If you have made a commit for this fix against your own git clone of
the OSG just pointing me at this commit should help me understand what
is going on better.
Cheers,
Robert.
On Mon, 11 Jun 2018 at 14:44, Daniel Emminizer, Code 5773
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] 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
> > > 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.
> > >
> > > I
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> 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] 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 > > > 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.
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
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
> > 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
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
> 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
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
On 3 June 2018 at 11:11, Robert Osfield wrote:
> Hi Dan,
>
> On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
> 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.
I have tried the test program against the OpenSceneGraph-3.4 branch
and it behaves the same for all command line options. This doesn't
tell us much other than that there is regression between 3.4 and 3.6.
I haven't tried master yet.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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
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.
#include
#include
#include
#include
osg::Node* createTriangle(float x, bool earlyBinding, const osg::Vec4f& color)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;
geom->setUseVertexArrayObject(true);
geom->setUseVertexBufferObjects(true);
osg::Vec3Array* vertices = new osg::Vec3Array();
vertices->push_back(osg::Vec3(x - 100, 0, -100));
vertices->push_back(osg::Vec3(x, 0, 100));
vertices->push_back(osg::Vec3(x, 0, -100));
osg::Vec3Array* normals = new osg::Vec3Array;
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
if (earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);
osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_OVERALL);
colors->push_back(color);
geom->addPrimitiveSet(new osg::DrawArrays(GL_TRIANGLES, 0, 3));
geom->setVertexArray(vertices);
geom->setNormalArray(normals);
geom->setColorArray(colors);
geode->addDrawable(geom);
// Warning gets generated due to this line not causing (eventually) a VBO creation
if (!earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);
return geode;
}
osg::Node* createScene()
{
osg::Group* group = new osg::Group;
// Reddish: Generates warning
group->addChild(createTriangle(-100, false, osg::Vec4f(1, 0.5, 0.5, 1)));
// Greenish: No warnings
group->addChild(createTriangle(100, true, osg::Vec4f(0.5,1,0.5,1)));
return group;
}
int main(int argc, char** argv)
{
osg::ArgumentParser arguments(, argv);
// construct the viewer.
osgViewer::Viewer viewer(arguments);
viewer.setSceneData(createScene());
viewer.setUpViewInWindow(100, 100, 800, 600);
viewer.addEventHandler(new osgViewer::StatsHandler());
return viewer.run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Could this be why I'm not getting my colors? Cheers, Brad On Fri, Jun 1, 2018 at 8:51 AM, Robert Osfield wrote: > Hi Dan, > > Thanks for the explanation and example to reproduce the bug... Guess > it looks like we'll need to make 3.6.2 rather sooner than I was > hoping, it'll be one a month at this rate... > > Robert. > > On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773 > wrote: > > Hi Robert, > > > > 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: > > > > > > 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. > > > > 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::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::Binding) > signature -- i.e. assigning a binding on construction. At the time I > thought it was something I was doing wrong and moved on. > > > > 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: > > > > - Loading FLT model > > - FLT model loads a face, which has vertices, textures, and normals > > - FLT uses getOrCreateNormalArray(), which allocates an array > (BIND_UNDEFINED) and sets it on the geometry > > - Geometry::addVertexBufferObjectIfRequired() is called on the normals, > but nothing done due to BIND_UNDEFINED > > - FLT later sets normals to BIND_PER_VERTEX appropriately, which is a > direct set and does not do anything to the Geometry's VBOs > > - First frame starts to render > > - Geometry::drawVAImpl calls vas->setNormalArray() > > - VertexArrayState::setArray() calls new_array->getOrCreateGLBufferObject(), > which returns 0. This is the first major problem. > > - Because vbo is NULL, unbindindVertexBufferObject() is called, leading > to GL_ARRAY_BUFFER to go to 0 > > - 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 > > > > Unwinding the error: > > - enable_and_dispatch() shouldn't be called if ptr is non-NULL and no > GL_ARRAY_BUFFER is 0 > > - GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the > normal array > > - 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 > > - Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after > setNormalArray(), leading to the error > > > > There are several possible solutions I can see. You can probably see > more: > > 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? > > 2) Update Array::setBinding() to create the VBO if needed. I do not > know if this is possible nor how to do it. > > 3) "Lazily" detect this issue somewhere in the rendering calls and > create VBO there if necessary > > > > > > > > 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. > > > > 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. > > > > - Dan > > > > > > ___ > > osg-users mailing list > > 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 > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Dan, Thanks for the explanation and example to reproduce the bug... Guess it looks like we'll need to make 3.6.2 rather sooner than I was hoping, it'll be one a month at this rate... Robert. On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773 wrote: > Hi Robert, > > 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: > > > 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. > > 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::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::Binding) signature > -- i.e. assigning a binding on construction. At the time I thought it was > something I was doing wrong and moved on. > > 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: > > - Loading FLT model > - FLT model loads a face, which has vertices, textures, and normals > - FLT uses getOrCreateNormalArray(), which allocates an array > (BIND_UNDEFINED) and sets it on the geometry > - Geometry::addVertexBufferObjectIfRequired() is called on the normals, but > nothing done due to BIND_UNDEFINED > - FLT later sets normals to BIND_PER_VERTEX appropriately, which is a direct > set and does not do anything to the Geometry's VBOs > - First frame starts to render > - Geometry::drawVAImpl calls vas->setNormalArray() > - VertexArrayState::setArray() calls new_array->getOrCreateGLBufferObject(), > which returns 0. This is the first major problem. > - Because vbo is NULL, unbindindVertexBufferObject() is called, leading to > GL_ARRAY_BUFFER to go to 0 > - 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 > > Unwinding the error: > - enable_and_dispatch() shouldn't be called if ptr is non-NULL and no > GL_ARRAY_BUFFER is 0 > - GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the normal > array > - 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 > - Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after > setNormalArray(), leading to the error > > There are several possible solutions I can see. You can probably see more: > 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? > 2) Update Array::setBinding() to create the VBO if needed. I do not know if > this is possible nor how to do it. > 3) "Lazily" detect this issue somewhere in the rendering calls and create VBO > there if necessary > > > > 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. > > 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. > > - Dan > > > ___ > osg-users mailing list > 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
[osg-users] VBO Bug with 3.6.1 and Normal Arrays
Hi Robert,
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:
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.
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::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::Binding) signature --
i.e. assigning a binding on construction. At the time I thought it was
something I was doing wrong and moved on.
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:
- Loading FLT model
- FLT model loads a face, which has vertices, textures, and normals
- FLT uses getOrCreateNormalArray(), which allocates an array (BIND_UNDEFINED)
and sets it on the geometry
- Geometry::addVertexBufferObjectIfRequired() is called on the normals, but
nothing done due to BIND_UNDEFINED
- FLT later sets normals to BIND_PER_VERTEX appropriately, which is a direct
set and does not do anything to the Geometry's VBOs
- First frame starts to render
- Geometry::drawVAImpl calls vas->setNormalArray()
- VertexArrayState::setArray() calls new_array->getOrCreateGLBufferObject(),
which returns 0. This is the first major problem.
- Because vbo is NULL, unbindindVertexBufferObject() is called, leading to
GL_ARRAY_BUFFER to go to 0
- 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
Unwinding the error:
- enable_and_dispatch() shouldn't be called if ptr is non-NULL and no
GL_ARRAY_BUFFER is 0
- GL_ARRAY_BUFFER is set to 0 because there is no VBO set up for the normal
array
- 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
- Binding gets swapped from BIND_UNDEFINED to BIND_PER_VERTEX after
setNormalArray(), leading to the error
There are several possible solutions I can see. You can probably see more:
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?
2) Update Array::setBinding() to create the VBO if needed. I do not know if
this is possible nor how to do it.
3) "Lazily" detect this issue somewhere in the rendering calls and create VBO
there if necessary
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.
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.
- Dan
cmake_minimum_required(VERSION 2.6)
SET(PROJECT_NAME arraybug)
PROJECT(${PROJECT_NAME})
FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgViewer)
FIND_PACKAGE(osgText)
SET(SOURCES
main.cpp
)
INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})
LINK_DIRECTORIES(${OSG_LIB_DIR})
ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})
TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${OSG_LIBRARIES} ${OSGVIEWER_LIBRARIES}
${OSGUTIL_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGGA_LIBRARIES} ${OSGTEXT_LIBRARIES}
${OPENTHREADS_LIBRARIES})
#include
#include
#include
#include
osg::Node* createTriangle(float x, bool earlyBinding, const osg::Vec4f& color)
{
osg::Geode* geode = new osg::Geode;
osg::Geometry* geom = new osg::Geometry;
geom->setUseVertexArrayObject(true);
geom->setUseVertexBufferObjects(true);
osg::Vec3Array* vertices = new osg::Vec3Array();
vertices->push_back(osg::Vec3(x - 100, 0, -100));
vertices->push_back(osg::Vec3(x, 0, 100));
vertices->push_back(osg::Vec3(x, 0, -100));
osg::Vec3Array* normals = new osg::Vec3Array;
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
normals->push_back(osg::Vec3(0, -1, 0));
if (earlyBinding)
normals->setBinding(osg::Array::BIND_PER_VERTEX);
osg::Vec4Array* colors = new osg::Vec4Array(osg::Array::BIND_OVERALL);
colors->push_back(color);
geom->addPrimitiveSet(new osg::DrawArrays(GL_TRIANGLES, 0, 3));
geom->setVertexArray(vertices);
geom->setNormalArray(normals);
geom->setColorArray(colors);
geode->addDrawable(geom);
// Warning
