Hi Robert, On Friday, June 14, 2013 13:08:43 Robert Osfield wrote: > My opinions about what to do in about osg::Geometry and the old > deprecated functionality is continuing to evolve. I'm starting to > feel that have an osg::GeometryDeprecated is going to be awkward to > maintain and for end users, while the new cleaned up osg::Geometry is > clearly much better from an internal implementation and performance > point of view it might be best in the short term to maintain support > for the old deprecated functionality. > > For the old deprecated usage, while keep the clean fast path only > implementation I am think about having an internal osg::Geometry that > is generated from the parent osg::Geometry that is fully fast path > complient and automatically generated from the parent osg::Geometry's > data. This fallback could be optionally compiled out, as could the > public API for the old deprecated functionality. One could also at > runtime disable the fallback and possible emit an std::exception to > help users who want to migrate across.
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. 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. 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. 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. 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. Anyway thanks for all you work! Mathias _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
