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(verti
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
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 >
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. At
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 t
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(&argc, 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 gets
Re: [osg-users] VBO Bug ?
Great, that is good to hear. Thanks for reporting the issue to NVidia. Kind regards, Ruben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wojciech Lewandowski Sent: woensdag 23 november 2011 12:52 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] VBO Bug ? Hi, Everyone This the response I got from NVidia: > It turns out this issue is already fixed in our upcoming 290.xx drivers. We > expect a beta driver from this branch to be released sometime in the next few > weeks. > > Thanks for the very easy repro and very thorough detailing of the problem. > Cheers, Wojtek Lewandowski -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44009#44009 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi, Everyone This the response I got from NVidia: > It turns out this issue is already fixed in our upcoming 290.xx drivers. We > expect a beta driver from this branch to be released sometime in the next few > weeks. > > Thanks for the very easy repro and very thorough detailing of the problem. > Cheers, Wojtek Lewandowski -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44009#44009 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi, Guys, Bug reported to NVidia. Will keep you posted on progress. See my report below: WL From: Wojciech Lewandowski Sent: Saturday, October 15, 2011 2:10 PM To: devsupp...@nvidia.com Subject: OpenGL VBO bug in Windows (OpenSceneGraph) Dear Dev Support, We have recently isolated an issue with Vertex Buffer Objects in OpenSceneGraph on Windows 7 platform. Issue seems to happen on variety of boards and drivers. We actually saw it on everything we tested on. GF580, GF460, GF540, GF 280 with recent drivers from 270.xx to most current 285.xx. And people on osg forums also reported seeing it on several Quadros (don’t remember which ones, though) with older 186.xx drivers. We did not see it on other manufacturer boards and we did not see it on NVidia in Linux. It can be “fixed” by turning off Threading optimization in NVidia control panel. So its most probably an issue in NVidia OpenGL Windows drivers. The problem we observe is corruption of the texture coords stored in VBOs in one or more primitive sets when sufficiently large VBOs are used. It happens when VBO sizes are close to range limits addressable with 16 bit ushort and greater (we use Uint 32 bit indices, though). These large VBOs contain vertices and texcoords. These triangles are indexed and drawn with glDrawElements call. 32 bit Uint indices are used and also stored in buffer objects. It seems that issue is somehow triggered by small addition of legacy code. All these triangles use single overall normal (I am not sure but this probably translates to glNormal call). If this overall normal is not added output seems correct. I have attached modifed osgViewer applet showing the issue. Package contains both prebuilt binary with neccessary osg dlls and modified osgViewer source if you prefer to use your OSG version. osgViewer should be run without command line arguments to show the problem. Sample code in osgViewer replicating the issue was created in process of elimination of various factors so its now rather artificial. It just draws two primitive sets: one triangle and second primitve made of grid build from many triangles. Problem directly affects this grid of triangles. First triangle is somehow involved and neccessary to make it happen, though. If there is no first triangle and there is no overall normal problem does not appear. Visually the code just draws one triangle and quad over the triangle. Both quad and triangle are colored with red yellow magenta gradient. If all is ok - its hard to notice the border between quad and triangle. If the problem shows up - quad is either drawn in red or not drawn at all, so only a triangle is drawn with gradient and nasty z-fighting between red quad and triangle can be observed. See attached screenshots for correct and incorrect output. I will be grateful for some feedback on this issue. Let me know if you are going to fix it and in what drivers ? Best Regards, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi Wojtek, Hehe, do you read my mind ? You posted the answer before my question I arrived on the list. I will send them broken model then. If they have osg installed, they could easily see the OpenGL calls with glDebuger. I suggest you send them a zip with osgviewer and the required DLLs too, just to simplify their life. I doubt they have OSG installed, and requiring them to go get the binaries will just be a barrier to them examining this bug. J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi, J-S Hehe, do you read my mind ? You posted the answer before my question I arrived on the list. I will send them broken model then. If they have osg installed, they could easily see the OpenGL calls with glDebuger. Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Jean-Sébastien Guay Sent: Thursday, October 13, 2011 3:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VBO Bug ? Hi guys, So maybe we should try to reproduce this with pure OpenGL and send a sample to NVidia (they have been very responsive in the past if you send an example) And actually in my experience, even if you send an OSG-based example (binaries only) they can reproduce it and look at the OpenGL calls and find the problem that way. You don't even need to make a pure OpenGL example. I agree, they've been responsive, which reminds me I still haven't sent a repro example for an Optimus bug I found... Dev Support Hope this helps, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ 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 ?
Hi Wojtek, Sebastian: Just out of curiosity where do you send or post OpenGL bugs ? Thru Registered developer's site or NVidia forums ? I have mixed results with registered devs site. Maybe other paths are a faster ? Please see my message, generally there's no need to make a pure OpenGL test case, and I gave you the e-mail address to send to directly :-) J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi, Guys Big Thanks for testing. And Very Big Thanks to Ruben for this workaround. Yes it also works for me. I am glad I started this thread before trying to dig deeper in the OSG. Thats definitely something with drivers. I am not sure if I will be able to quickly prepare pure GL test case quickly, though. Sebastian: Just out of curiosity where do you send or post OpenGL bugs ? Thru Registered developer's site or NVidia forums ? I have mixed results with registered devs site. Maybe other paths are a faster ? Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Sebastian Messerschmidt Sent: Thursday, October 13, 2011 9:05 AM To: OpenSceneGraph Users Subject: Re: [osg-users] VBO Bug ? I've just tried this, and indeed: Setting Threaded Optimization from Auto to Off yields the "good" result. So maybe we should try to reproduce this with pure OpenGL and send a sample to NVidia (they have been very responsive in the past if you send an example) cheers Sebastian Dear Wojtek et al., This mail reminded me of an issue I had a couple of years ago with VBO's on a particular Windows pc with a 9800GX2. I thought it was an issue of that PC, as it was quite unstable, so I didn't report the problem at that time. The solution I accidently found back then was to turn off Threaded Optimization in the NVidia Control Panel (Auto per default). But now I'm getting the bad result of your test on a GTX 480 (266.58 driver), and that "fix" works again. After turning off Threaded Optimization, I see the proper gradient displayed. Could you try this as well? Kind regards, Ruben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P. Delport Sent: donderdag 13 oktober 2011 7:39 To: OpenSceneGraph Users Subject: Re: [osg-users] VBO Bug ? Hi, On 12/10/2011 18:45, Wojciech Lewandowski wrote: So if you are on Linux and have a minute please let me know how the test passed on your machine ;-) tested on two more for you, both Debian 32-bit. 1: dual nvidia GTS250s, driver 270.41.19, good result across 4 screens. 2: nvidia 9600GT, driver 280.13, good result on single screen. cheers jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ___ 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 ?
Hi guys, So maybe we should try to reproduce this with pure OpenGL and send a sample to NVidia (they have been very responsive in the past if you send an example) And actually in my experience, even if you send an OSG-based example (binaries only) they can reproduce it and look at the OpenGL calls and find the problem that way. You don't even need to make a pure OpenGL example. I agree, they've been responsive, which reminds me I still haven't sent a repro example for an Optimus bug I found... Dev Support Hope this helps, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
I've just tried this, and indeed: Setting Threaded Optimization from Auto to Off yields the "good" result. So maybe we should try to reproduce this with pure OpenGL and send a sample to NVidia (they have been very responsive in the past if you send an example) cheers Sebastian Dear Wojtek et al., This mail reminded me of an issue I had a couple of years ago with VBO's on a particular Windows pc with a 9800GX2. I thought it was an issue of that PC, as it was quite unstable, so I didn't report the problem at that time. The solution I accidently found back then was to turn off Threaded Optimization in the NVidia Control Panel (Auto per default). But now I'm getting the bad result of your test on a GTX 480 (266.58 driver), and that "fix" works again. After turning off Threaded Optimization, I see the proper gradient displayed. Could you try this as well? Kind regards, Ruben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P. Delport Sent: donderdag 13 oktober 2011 7:39 To: OpenSceneGraph Users Subject: Re: [osg-users] VBO Bug ? Hi, On 12/10/2011 18:45, Wojciech Lewandowski wrote: So if you are on Linux and have a minute please let me know how the test passed on your machine ;-) tested on two more for you, both Debian 32-bit. 1: dual nvidia GTS250s, driver 270.41.19, good result across 4 screens. 2: nvidia 9600GT, driver 280.13, good result on single screen. cheers jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ___ 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 ?
Dear Wojtek et al., This mail reminded me of an issue I had a couple of years ago with VBO's on a particular Windows pc with a 9800GX2. I thought it was an issue of that PC, as it was quite unstable, so I didn't report the problem at that time. The solution I accidently found back then was to turn off Threaded Optimization in the NVidia Control Panel (Auto per default). But now I'm getting the bad result of your test on a GTX 480 (266.58 driver), and that "fix" works again. After turning off Threaded Optimization, I see the proper gradient displayed. Could you try this as well? Kind regards, Ruben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P. Delport Sent: donderdag 13 oktober 2011 7:39 To: OpenSceneGraph Users Subject: Re: [osg-users] VBO Bug ? Hi, On 12/10/2011 18:45, Wojciech Lewandowski wrote: > So if you are on Linux and have a > minute please let me know how the test passed on your machine ;-) tested on two more for you, both Debian 32-bit. 1: dual nvidia GTS250s, driver 270.41.19, good result across 4 screens. 2: nvidia 9600GT, driver 280.13, good result on single screen. cheers jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi, On 12/10/2011 18:45, Wojciech Lewandowski wrote: So if you are on Linux and have a minute please let me know how the test passed on your machine ;-) tested on two more for you, both Debian 32-bit. 1: dual nvidia GTS250s, driver 270.41.19, good result across 4 screens. 2: nvidia 9600GT, driver 280.13, good result on single screen. cheers jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
12.10.2011 20:45, Wojciech Lewandowski wrote: > So if you are on Linux and have a minute please let me know how the test > passed on your machine ;-) Hi, Wojtek, gentoo x86_64 GeForce 9600 GT 270.41.06 good result Mikhail. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi, Thank You Guys Yeah, pattern starts to show. Its most probably something related to NVidia OpenGL drivers on Windows. When I have sent the email I realized I may test the code on Intel HD 3000 I have on a wife laptop. And I got “good” result there and “bad” when switched to NVidia 540 Optimus. We also saw “bad” results on GF 580 and GF 460 on several latest drivers from 270.xx to most recent ones on Windows. I would be interested in larger test sample group from guys with NVidias on Linux and Macs to exclude their system as not affected. So if you are on Linux and have a minute please let me know how the test passed on your machine ;-) I have not written how the problem manifests in real life. But I guess it may be useful in case someone is hit by this. I encountered this when I was playing with farirly huge geometries. 500 k – 2000 k vertices and 5000 k tris in one primitive set. With few such primitive sets I started to observe that texture coords in one of them are broken. After investigation I have created the test case above. It uses fairly small number of vertices and texcoords (33127 vertices and 65523 triangles) but it still shows the issue. So it seems like a problem is somehow triggered when vbo index range gets close to max value addresable on ushort. Cheers, Wojtek Lewandowski From: PP CG Sent: Wednesday, October 12, 2011 6:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VBO Bug ? On 12.10.2011 15:55, Wojciech Lewandowski wrote: Could you guys check if this problem also happens in other systems ? Hi Wojtek, "bad" result. Win 7 x64, osg build for x86 NVIDIA GTX 295 driver 280.26 Cheers, PP ___ 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 ?
On 12.10.2011 15:55, Wojciech Lewandowski wrote: Could you guys check if this problem also happens in other systems ? Hi Wojtek, "bad" result. Win 7 x64, osg build for x86 NVIDIA GTX 295 driver 280.26 Cheers, PP ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi, On 12/10/2011 15:55, Wojciech Lewandowski wrote: Could you guys check if this problem also happens in other systems ? I'm getting the "good" result. Debian Sid 64-bit Nvidia Quadro 2000M Driver 280.13 jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO Bug ?
Hi Wojciech, I get the bad result, running on NVidia Quadro NVS 140M, Driver version 186.94, Windows 7 Enterprise 32bit. Hi Robert and Community, I am seeing strange problem with VBOs in OSG on Windows and several NVidia boards and several driver versions. Basically a set of geometries with certain certain number of vertices and texcoords are drawn incorrectly when we use VBOs. When used with display lists they are drawn correctly. I was unable to investigate if the problem is in OSG or OpenGL or in my code. But I checked my code several times already so I would like to hear your opinion what is this. Could you guys check if this problem also happens in other systems ? I have isolated the problem as deep as I could and created a set of files that can be used to reproduce the issue. They just draw one quad and one triangle over the quad. Both quad and triangle are colored with red yellow magenta gradient. If all is ok - its hard to notice the border between quad and triangle. If the problem shows up - quad is either drawn in red or not drawn at all, so only a triangle is drawn with gradient and nasty z-fighting between quad and triangle can be observed. I have prepared a modified osgViewer source which can be used to reproduce the bug (run it without args). See attached screenshots for correct and incorrect output. I will be grateful for some feedback on this issue... If someone is interested I may send "good" and "bad" model files too. I have not attached them because they have 700 kb zipped. Cheers & Thanks in advance, Wojtek Lewandowski ___ 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 ?
On 10/12/2011 09:55 AM, Wojciech Lewandowski wrote: I have prepared a modified osgViewer source which can be used to reproduce the bug (run it without args). See attached screenshots for correct and incorrect output. I will be grateful for some feedback on this issue... Hi, Wojtek, RHEL 6.1 NVIDIA GTX 260 driver version 285.05.09 I get the "good" result. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org