Hi Julien, I have been moving between many different topics during my current submission purge, this means understanding all the ins and outs of larger and more intertwined topics are hard to grasp fully on first pass through. I simply can't resolve all of the various ins and outs of this particular topic right away.
The best thing is to spot bits that are self contained and easy to integrate and roll these out first, then build on these. The extensions is an example of something that is nice and separate from the other details and easy to review on it's own merits. Robert. On 1 June 2016 at 13:22, Julien Valentin <[email protected]> wrote: > Hi Robert, > Thank for merge changes in GLExtensions. > > I have think about the issue of backwards compatibility with osgdb and one > way to handle that (but not the cleaner) would be to add boolean property to > BufferData ( isSerializable ) > > I completely understand you point concerning the property > isRasterizerEnable... you surely can remove all references to it (I don't > know why I added this ..Silly me) > > But the main contribution here comes from TextureBuffer...Would you want my > test case for the Instancing pattern I wrote about ( TFeedback to VBO->bind > VBO as TBO for Instancing)? > > > > robertosfield wrote: >> Hi Julian, >> >> I have just done a review of the complete changes and have merged the >> changes to GLExtensions. >> >> The rest of the changes I will need to reflect upon and do some >> background research and thinking on how best to integrate these >> features. >> >> One of the main issues I spotted was the changes to the serializers >> will break backwards compatibility with older .osgb, .osgt and .osgx >> files as the addition of the BufferData will be run on all versions of >> the files. To integrate such a change we'd first need to come up with >> a way of versioning changes to the inheritance description. >> >> I'd also not add glEnable/glDisable into a draw callback as the >> osg::State has lazy state updating that can handle the mode >> enabling/disabling as required without risk of state leaking. >> Enabling a mode on a StateSet attached to the drawable should be >> sufficent for enabling a mode locally on that drawable, osg::State >> will automatically disable this mode for the rest of the scene. >> >> Robert. >> >> >> On 1 June 2016 at 04:06, Julien Valentin <> wrote: >> >> > Hi, >> > Here are an archive with the changes I talk about in my previous post >> > (as I'm not very good on writing complete posts on the first take, please >> > see the forum) >> > Hope I don't miss any files. >> > Fell free to contact me if my previous explanations (or my code) aren't >> > clear enough. >> > Thanks >> > >> > ------------------ >> > Read this topic online here: >> > http://forum.openscenegraph.org/viewtopic.php?p=67309#67309 >> > >> > >> > >> > >> > _______________________________________________ >> > osg-submissions mailing list >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > >> > >> _______________________________________________ >> osg-submissions mailing list >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> >> ------------------ >> Post generated by Mail2Forum > > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=67318#67318 > > > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
