Hi. I'm not sure I follow the discussion, since each post is starting to become a separate article, but I'll try to tell what I think. I don't know the policy on OSG ABI, but if it's to keep ABI compatible between some releases, I would: * add compile flag to select between old and new Geometry (defaults to old one); * warn during compile time and during running (into the log) that using the old Geometry is deprecated and will be removed in the following stable release; * warn in changelog about the coming ABI breakage;
If the policy is only to keep API compatibility with some minor changes like obsoleting unused functions, then Geometry could be removed. 2013/6/15 Robert Osfield <robert.osfi...@gmail.com> > Hi Mattias et. al, > > On 14 June 2013 14:23, Mathias Fröhlich <mathias.froehl...@gmx.net> wrote: > > I really like the idea of GeometryDeprecated. It takes somehow more work > to > > make this happen for users. But at very first it's just about changing a > single > > datatype. Once it compiles with osg::Geometry again you know that you > will > > nowhere have a slow path geometry anymore. You do not need to rely on > your > > test coverage and an exception then. > > I know, this is against what you usually do with your api. > > My clean up work today has focused on sliming down > osg::ArrayDispatchers and as a knock on effect implementing > GeometryDeprecated has become a bit more complicated as it'll need to > take on more of the work that ArrayDispatchers used to handle. I > don't think it's right for us to bloat the core OSG just to maintain > deprecated functionality so my current inclination is to perhaps even > go further and not provide GeometryDeprecated at all. > > I'm currently toying with the idea of leaving the deprecated slow path > methods in osg::Geometry and have flag that gets set to declare this > osg::Geometry in invalid condition that can't be rendered or handled > in any osg::Geometry processing, to make this osg::Geometry usable > you'd then call an optimize method that converts all the indices and > per primitive usage into OpenGL fast path compliant usage. My current > implementation has the valid fast path version of this osg::Geometry > nested within the invalid one and used in it's place when rendering, > but this feels a bit cludgy and potentially inefficient when it comes > to updates. The awkwardness with this nested osg::Geometry is why I'm > starting to wonder if just labelling these problem osg::Geometry as > invalid and let them be ignored unless the uses runs the optimize > method. > > For the .osg, .ive loaders and new serilizers and thinking that by > default we could automatically run the optimizer on the any problem > osg::Geometry that have been loaded. > > > > > If we really start to optimize geometries under the hood, when would you > do > > this then? You cannot rely on anything in osgDB since you have to > account for > > in application generated geometries. The only non concurrent opportunity > is > > the update stage so far. Ok, let's assume that happens there. > > But then we at least have *huge* geometries. Processing them with this > kind of > > optimization to get rid of the indices and that can take a long time. > > It can, so I'm inclined to push this back to user and do a one time > convert after they have created the osg::Geometry. When could > possible have a contains invalid osg::Geometry flag in the whole scene > graph so that the update traversal knows it needs to hunt down and > convert them, this does add complexity though. The other alternative > might be to have a linked list of invalid osg::Geometry that need to > be dealt with. > > Having this invalid/deprecated osg::Geometry be updated each frame > would be very costly, but then they are any way. What we really want > users to do is migrate away from ever creating these bad osg::Geometry > in the first place, so having to jump through an extra hoop or two to > make it explicit about what is happening might be the best way, even > if it does mean that end users can't just recompile and run with the > latest OSG and expect everything including there old deprecated usage > to still work. > > Offically array Indices and BIND_PER_PRIMTIVE have been deprecated for > several releases, every time the topic is mentioned I try to persuade > users to use fast paths. The inline docs have long been clear that > they are deprecated so perhaps I needn't be so accommodating. > > > > We > > experience this as of today with non fast path geometries where the > driver is > > doing this work under the hood. And in contrast to osg these drivers > have a > > long histroy of optimizing this code paths and are well optimized. > > OpenGL drivers have been better at replicating the glBegin/glEnd than > the OSG equivalent found in the osg::GLBeginEndAdapter, as much as I > tried to optimize the later I could never get the same performance as > what the OpenGL driver was doing. By contrast fast path osg::Geometry > are relatively easy to just push out to OpenGL without a big CPU > overhead. > > > > Also update is currently empty. And for applications that do not need an > > additional graph traversal this should stay like that IMO. Depending on > the > > structure of your graph - most probably for viz sim applications - you > might > > need to traverse way more nodes in update than you need for cull, since > you > > might have loaded much more geometry than you currently have in the > current > > view. So having update walk the whole present tree can itself take a > noticable > > time. > > If we did an update traversal then one would have to limit it to just > the slow path geometry that is being updated on that frame. If you > don't have much slow path geometry this needn't be too slow. If you > have lots of slow path geometry then well perhaps you deserve to do > the work to correct or suffer a slow app... > > > > Rather than that I would prefer to have this explicitly stated in the > API what > > is sensible to use and what not. > > At least a compile switch which only allows me to use fast path stuff > would be > > helpful IMO. > > > > So I would vote for GeometryDeprecated. May be you can call the two > classes > > also FastGeometry vs. Geometry indstead of Geometry vs. > DeprecatedGemetry. > > The clean version has to be the standard osg::Geometry, otherwise we > end up with practically no one using the new clean and faster version, > while the majority would be stuck on the old one that has all the > cruft to handle the few cases where users do have osg::Geometry with > deprecated slow path usage. > > So I want as many people to move across directly to the new > osg::Geometry with just a recompile and no other changes to their > application. It's the minority of users who have been using > deprecated functionality against long standing advice that need will > need to do the extra work. How much extra work, and how easy it'll be > is the question I'm playing with right now. > > How easy and how much work they will need to do will depend upon how I > get on with my experiments and feedback from the community. My > current favourite approach is to just keep the old deprecated > osg::Geometry for OSG-3.2 but automatically make the osg::Geometry > that they are used on as invalid and in need of conversion by an > explicit optimize/fix method call. Loading of models with deprecated > usage would be by default automatically converted to the efficient > form. This approach wouldn't support automatic updates or any clever > update traversal mechansim, if the user sticks now invalid > osg::Geometry in the scene graph without convert them then they'll > just see holes in the scene and an error on the console, or > potentially see an exception thrown - the later configured via CMake > rather as default. > > Compiling with the deprecated methods #ifdef'd out is also something > I'm thinking of providing, but for 3.2 this would be off by default, > but perhaps we should have them not compiled in by default... > > Robert. > _______________________________________________ > 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
