OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

VBO Bug with 3.6.1 and Normal Arrays

Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Daniel Emminizer, Code...
Guest





PostPosted: Fri Jun 01, 2018 3:01 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12095

PostPosted: Fri Jun 01, 2018 3:51 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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:
Quote:
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






------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
bcolbert (Brad Colbert)
User


Joined: 24 May 2012
Posts: 37

PostPosted: Fri Jun 01, 2018 5:09 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

Could this be why I'm not getting my colors?

Cheers,
Brad


On Fri, Jun 1, 2018 at 8:51 AM, Robert Osfield < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
< (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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




Quote:
_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12095

PostPosted: Sun Jun 03, 2018 10:11 am    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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.



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12095

PostPosted: Sun Jun 03, 2018 11:08 am    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

On 3 June 2018 at 11:11, Robert Osfield <> wrote:
Quote:
Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Mon Jun 04, 2018 12:46 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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



Quote:
-----Original Message-----
From: osg-users [mailto:] On
Behalf Of Robert Osfield
Sent: Sunday, June 03, 2018 6:11 AM
To: OpenSceneGraph Users
Subject: Re: VBO Bug with 3.6.1 and Normal Arrays

Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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.


------------------
Post generated by Mail2Forum
Back to top
Daniel Emminizer, Code...
Guest





PostPosted: Mon Jun 11, 2018 1:38 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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



Quote:
-----Original Message-----
From: Daniel Emminizer, Code 5773
Sent: Monday, June 04, 2018 8:45 AM
To: OpenSceneGraph Users
Subject: RE: 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



Quote:
-----Original Message-----
From: osg-users [mailto:] On
Behalf Of Robert Osfield
Sent: Sunday, June 03, 2018 6:11 AM
To: OpenSceneGraph Users
Subject: Re: VBO Bug with 3.6.1 and Normal Arrays

Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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
Quote:
GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
384.111
Quote:
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
Quote:
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
Quote:
details.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Voerman, L.
Guest





PostPosted: Mon Jun 11, 2018 2:26 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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 (srcosgPluginsOpenFlightGeometryRecords.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  srcosgPluginsOpenFlightGeometryRecords.cpp )
Regards, Laurens.


On Mon, Jun 11, 2018 at 3:37 PM, Daniel Emminizer, Code 5773 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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



Quote:
-----Original Message-----
From: Daniel Emminizer, Code 5773
Sent: Monday, June 04, 2018 8:45 AM
To: OpenSceneGraph Users
Subject: RE: 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



Quote:
-----Original Message-----
From: osg-users [mailto: (
Only registered users can see emails on this board!
Get registred or enter the forums!
)] On
Behalf Of Robert Osfield
Sent: Sunday, June 03, 2018 6:11 AM
To: OpenSceneGraph Users
Subject: Re: VBO Bug with 3.6.1 and Normal Arrays



Quote:
Quote:
Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
< (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
Quote:
GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
384.111
Quote:
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
Quote:
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
Quote:
details.

Robert.


_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12095

PostPosted: Mon Jun 11, 2018 2:48 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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:
Quote:

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



Quote:
-----Original Message-----
From: Daniel Emminizer, Code 5773
Sent: Monday, June 04, 2018 8:45 AM
To: OpenSceneGraph Users
Subject: RE: 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



Quote:
-----Original Message-----
From: osg-users [mailto:] On
Behalf Of Robert Osfield
Sent: Sunday, June 03, 2018 6:11 AM
To: OpenSceneGraph Users
Subject: Re: VBO Bug with 3.6.1 and Normal Arrays

Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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
Quote:
GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
384.111
Quote:
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
Quote:
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
Quote:
details.

Robert.



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Mon Jun 11, 2018 3:14 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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


From: osg-users [mailto:] On Behalf Of Voerman, L.
Sent: Monday, June 11, 2018 10:26 AM
To: OpenSceneGraph Users
Subject: Re: 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 (srcosgPluginsOpenFlightGeometryRecords.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 srcosgPluginsOpenFlightGeometryRecords.cpp )

Regards, Laurens.



On Mon, Jun 11, 2018 at 3:37 PM, Daniel Emminizer, Code 5773 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> 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



Quote:
-----Original Message-----
From: Daniel Emminizer, Code 5773
Sent: Monday, June 04, 2018 8:45 AM
To: OpenSceneGraph Users
Subject: RE: 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



Quote:
-----Original Message-----
From: osg-users [mailto: (
Only registered users can see emails on this board!
Get registred or enter the forums!
)] On
Behalf Of Robert Osfield
Sent: Sunday, June 03, 2018 6:11 AM
To: OpenSceneGraph Users
Subject: Re: VBO Bug with 3.6.1 and Normal Arrays



Quote:
Quote:
Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
< (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
Quote:
GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
384.111
Quote:
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
Quote:
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
Quote:
details.

Robert.


_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

------------------
Post generated by Mail2Forum
Back to top
Daniel Emminizer, Code...
Guest





PostPosted: Mon Jun 11, 2018 3:19 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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


Quote:
-----Original Message-----
From: osg-users [mailto:] On
Behalf Of Robert Osfield
Sent: Monday, June 11, 2018 10:48 AM
To: OpenSceneGraph Users
Subject: Re: 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:
Quote:

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.
Quote:


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.
Quote:

During the draw traversal, as a result, the Array::getBinding() flag does not
match the VBO state in Geometry.
Quote:

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.
Quote:


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.
Quote:

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.
Quote:

Thanks,

- Dan



Quote:
-----Original Message-----
From: Daniel Emminizer, Code 5773
Sent: Monday, June 04, 2018 8:45 AM
To: OpenSceneGraph Users
Subject: RE: 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
Quote:
Quote:
mention Cessna; do you have the examples mixed up perhaps?

The bug will manifest if the geometry's normal array (and presumably
fog,
Quote:
Quote:
colors, etc) are set before the array binding type is set. It's entirely
possible
Quote:
Quote:
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&
Quote:
Quote:
drawable)


No change in error message with with OSG_GL_ERROR_CHECKING=on.
No
Quote:
Quote:
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.
Quote:
Quote:

Hope this helps. Thanks,

- Dan



Quote:
-----Original Message-----
From: osg-users [mailto:]
On
Quote:
Quote:
Quote:
Behalf Of Robert Osfield
Sent: Sunday, June 03, 2018 6:11 AM
To: OpenSceneGraph Users
Subject: Re: VBO Bug with 3.6.1 and Normal Arrays

Hi Dan,

On 1 June 2018 at 16:01, Daniel Emminizer, Code 5773
<> wrote:
Quote:
Attached is a demo of the problem that generates a console warning.
More complex scenes can cause crashes. The red triangle has the
problem,
Quote:
Quote:
Quote:
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
Quote:
Quote:
Quote:
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
Quote:
Quote:
Quote:
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.
Quote:
Quote:
Quote:

I don't see any command line warnings though. I'm testing under
Kubuntu
Quote:
Quote:
Quote:
with OSG-3.6 branch, my drive info is:

OpenGL vendor string: NVIDIA Corporation OpenGL renderer string:
GeForce
Quote:
GTX 760/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA
384.111
Quote:
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
Quote:
Quote:
the
Quote:
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
Quote:
details.

Robert.

openscenegraph.org



------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12095

PostPosted: Wed Jun 13, 2018 11:45 am    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Daniel Emminizer, Code...
Guest





PostPosted: Wed Jun 13, 2018 2:44 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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.


Quote:
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



Quote:
-----Original Message-----
From: osg-users [mailto:] On
Behalf Of Robert Osfield
Sent: Wednesday, June 13, 2018 7:45 AM
To: OpenSceneGraph Users
Subject: Re: 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.




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12095

PostPosted: Wed Jun 13, 2018 4:30 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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:
Quote:

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.


Quote:
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



Quote:
-----Original Message-----
From: osg-users [mailto:] On
Behalf Of Robert Osfield
Sent: Wednesday, June 13, 2018 7:45 AM
To: OpenSceneGraph Users
Subject: Re: 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.




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12095

PostPosted: Wed Jun 13, 2018 5:06 pm    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts EXTERNAL: Re: World space normal. Rowley, Marlin R General 1 Wed Jul 11, 2018 4:30 pm View latest post
No new posts World space normal. Rowley, Marlin R General 4 Wed Jul 11, 2018 1:18 pm View latest post
No new posts How to get the normal of every triangle? Wangbingqian General [forum] 2 Mon Mar 19, 2018 1:53 am View latest post
No new posts How to get the triangle normal vector? Wangbingqian General 0 Fri Mar 16, 2018 1:07 pm View latest post
No new posts Normal Mapping using Dynamic Cubemap romulogcerqueira General 11 Tue Dec 19, 2017 2:10 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP