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 Previous  1, 2
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12148

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

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.


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





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

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


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



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


Joined: 18 Mar 2009
Posts: 12148

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

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.


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





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

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


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



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


Joined: 18 Mar 2009
Posts: 12148

PostPosted: Thu Jun 14, 2018 7:25 am    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

Hi Daniel,

On Wed, 13 Jun 2018 at 23:29, Daniel Emminizer, Code 5773
<> wrote:
Quote:
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.


Quote:


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.


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


Joined: 18 Mar 2009
Posts: 12148

PostPosted: Thu Jun 14, 2018 8:10 am    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

H Dan et. al,

On Thu, 14 Jun 2018 at 08:25, Robert Osfield <> wrote:
Quote:
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.


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





PostPosted: Thu Jun 14, 2018 10:23 am    Post subject:
VBO Bug with 3.6.1 and Normal Arrays
Reply with quote

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



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

H Dan et. al,

On Thu, 14 Jun 2018 at 08:25, Robert Osfield <>
wrote:
Quote:
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.



------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page Previous  1, 2
Page 2 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