Hi Aurelien, On 4 June 2013 12:37, Aurelien Albert <[email protected]> wrote: > I've seen your commit about osg::GeometryNew, and I think this is a great > idea to clean up this class. > > So maybe it's time to move "normalize" parameter from > osg::Geometry::ArrayData to osg::Array, but also the "binding" parameter ? > > And maybe this leads to removing the whole osg::Geometry::ArrayData structure > since all parameters are now stored in osg::Array ? > > And, finally, maybe add the "attribDivisor" parameter to osg::Array ? > > The idea is to have a single place where "data, data format, data binding and > data divisor" are configured ?
The discussion about attribute divisor and normalize brought into focus this are of design/implementation in osg::Geometry and I've long been wanted to remove the deprecated slow path elements of osg::Geometry so it seemed an ideal time to "bite the bullet" and "kill two birds with one stone" :-) With the removal of indices from ArrayData it leaves only normalize and binding left. Both these aren't features I feel warrant separation from osg::Array to enable reuse of osg::Array between ArrayData, in fact as I mentioned in a previous post I believe reusing a single Array and using it in slightly different ways is dangerous programming, and a bit like slow paths, if you make the facility available it will be overused/misused. So safe coding wise I believe normalize and binding belong in Array. The attribute divisor tells use how an Array is intended to be used, it's very similar to normalize and binding so would naturally fall in osg::Array. At least from a theoretical design standpoint I feel this is a good destination to get to. However, theoretical design and actual final design and implementation are two very different things so during implementation we'll find out just how sound the approach might be. > (I can give a hand on this, I *should* have time for it at the end of this > week / begin of next week) Thanks for the offer. At this stage I need to handle the bulk of the refactoring work required as the code will be changing very rapidly, and I'm the one with the best inside knowledge about how all these classes have worked together over the years. Once I'm through the initial refactor I'll need assistance for sure - the attribute divisor will porting to the new functionality, and the examples still stuck on osg::Geometry slow paths will need porting. I am also wondering about whether osg::Geometry can be simplified - just so it does slow paths and make no effort to convert to or handle fast paths, I'll feel this would keep the old backwards compatibility class simple and easier to maintain once it gets annexed. The best place for these discussion is on osg-users, so unless you wish to discuss adapting your divisor submission I'd suggest posting follow ups there. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
