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
