Hi Dimi, Thanks for the further explanation about what you've been testing, this is useful. The large number of changes to BufferObject/VBO support is due to a revamp to make it more flexible and robust... which it "mostly" achieves but clearly you've found a flaw in new code.
>From your explanation I'm starting to wonder whether it's the sharing of a buffer object between the arrays and then substituting a new array which hasn't been assigned to the VBO is the problem, as the copying approach is working with this sharing the same VBO object, only just updatig the data. Robert. On Wed, May 25, 2011 at 9:23 PM, dimi christop <dimi_chris...@yahoo.com> wrote: > Hi Robert > thanks for looking into it. I also have spend the last days a few hours > looking at the src and comparing 2.8 and 2.912, there seem to be a lot of > changes in the > > BufferObjects and VertexBufferObjects. Especially the way the Arrays are > Dirtied > when setVertexArray is called. Unfortunately I got lost in the classes and > indirections and > could not locate anything specific. > > I managed to observe one strange thing however. If you dont call > setVertexArray() in order to substitute a new array > > but take the pointer of it and copy over the new values (using a for loop for > example) then a calling dirty() on this vertexArray > works as expected and does not invalidate all the other arrays (texcoords, > normal, color). > > I can send you a small example as soon as I get back to work tomorrow. > > Dimi > > > > > > ----- Original Message ---- > From: Robert Osfield <robert.osfi...@gmail.com> > To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org> > Sent: Wed, May 25, 2011 7:51:01 PM > Subject: Re: [osg-users] VBO incosistencies between 2.8 and 2.912 > > Hi Dimi, > > I have now recreated the issue on my system using your example. I > used the attached CMakeLists.txt to compile, this might help others > recreate the problem as well. > > As for the cause of the problem I can't yet say. Unfortunately I've > run out of working day so will need to come back to this tomorow. > > Robert. > > On Thu, May 19, 2011 at 2:21 PM, dimi christop <dimi_chris...@yahoo.com> > wrote: >> Hi Robert, >> >> this is exactly what I did, I called dirty on the vertexArray which is passed >> each frame >> to the geometry using >> geom->setVertexArray(vcoords); >> vcoords->dirty(); >> >> The problem was that, it screws up all other attached geometry arrays like >> (colors, normals, texcoords) which do not change.... >> >> This behavior does not occur when the geometry is not specified as VBO or in >> 2.8. >> I can try to call dirty on all arrays whether they change or not, but it does >> not seem logical. >> >> I attach a small example which show the problem (along with the makefile). >> The >> example >> changes vertexArrays of a VBO geometry (a cube) at runtime using 2 different >> vertexArrays. >> You should see a pulsating colored, textured cube if it runs fine. >> Commenting/Uncommenting the dirty calls make, or disabling the VBO makes it >> clear. >> >> Dimi >> >> >> >> >> ----- Original Message ---- >> From: Robert Osfield <robert.osfi...@gmail.com> >> To: OpenSceneGraph Users <osg-users@lists.openscenegraph.org> >> Sent: Thu, May 19, 2011 3:52:06 PM >> Subject: Re: [osg-users] VBO incosistencies between 2.8 and 2.912 >> >> Hi Dimi, >> >> The buffer object support in the OSG has been revamped and in theory >> should be robust and flexible... but like all code there is a chance >> for regressions so wide spread testing it neccessary. Whether in this >> instance there is an actual bug, or just a different behaviour I can't >> say as I haven't tested your code. >> >> As a quick test I would suggest calling dirty on each array your modiy. >> >> Robert. >> >> On Thu, May 19, 2011 at 1:37 PM, dimi christop <dimi_chris...@yahoo.com> > wrote: >>> Hi, >>> >>> I recently upgraded my code base to 2.912 (Linux, GTX 280) , unfortunately >>> my >>> GPU morphing code stopped working. >>> I use VBO, GLSL and vertex attributes to copy the changing morph shapes and > do >>> the interpolation on the GPU. >>> >>> After searching for the problem I found that when I declared a geometry as > VBO >>> // Disable Display lists and setup Vertex Buffer Objects >>> geom->setUseDisplayList (false); >>> geom->setUseVertexBufferObjects(true); >>> osg::VertexBufferObject* df = geom->getOrCreateVertexBufferObject(); >>> df->setUsage (GL_STREAM_DRAW); >>> >>> >>> the subsequent commands during the update which changed the vertexArray had > no >>> effect and produced random triangles on the screen. >>> geom->setVertexArray(vcoords); >>> >>> Because of the many morph shapes, I have many vertex arrays preallocated and >>> pass them to the geometry based on a time. I do not copy assign to the >>> vertex >>> array of the geometry for speed reasons. >>> As I said in the 2.8 version everything worked fine. >>> When change the code to issued a dirty on the vertex arrays >>> vcoords->dirty() >>> the shape morphed correctly but the color, normal, texcoord arrays (which do >>>not >>> morph) did not show up correctly. >>> >>> Has anyone any idea what changed between the 2.8-2.912 versions. I was under >>>the >>> impression that issuing a setVertexArray command >>> calls dirty() at least on the geometry array. >>> Is it therefore mandatory to issue a dirty() call for all arrays (color, >>>normal, >>> texcoords) assigned to the geometry? >>> >>> Please note then when I disable the VBO usage, a single dirty() call on the >>> vertexarray works and the other arrays show up normal. >>> >>> Thank you in advance >>> Dimi >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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
