Hi David, > Promoting osg::Drawable from being subclassed from osg::Object to > osg::Node is really a good idea ? > Why osg::Drawable is a subclass of osg::Object in original design ? > Which concept are implemented by this design?
I think one should ask the question the other way around. What value does osg::Geode add? I'm kinda stuck to provide may real benefits. osg::Geode exists for historical reasons - the OSG drew inspiration from a number of different scene graphs but among these Performer was most influential in the early days. Performer had pfGeode that you attached pfGeoSets too. The OSG has long outgrown the days when it's was influenced by other scene graphs but some aspects of the API have stuck around beyond their sell by date. If I were to write a new scene graph today it wouldn't have a Geode equivalent class, Geometry leaves would be just leaf Nodes on the scene graph. This approach is simpler and has the potential to perform better as there are less redundant Nodes in the scene graph, so less memory used and less memory to traverse on each frame. We do however have a big user base, deprecating osg::Geode isn't something we can do, we'll need it for backwards compatibility for a long time to come. It also won't do much harm just keeping this Node around. Documentation and code examples wise we'd want to steadily migrate to a osg::Geode free codebase, but there won't be any urgency for this. As for making a ParentList a vector<Node*> rather vector<Group*> with Node taking on some composite node API's to handle the compatibility side, this isn't ideal. The alternative would be to subclass osg::Geode from osg::Group, but then we'd have the issue of the addDrawable/removeDrawable interfaces that would sit in parallel to the addChild/removeChild ones, or to avoid this we'd deprecate addDrawable/removeDrawable and just use addChild/removeChild/etc but then a massive amount of OSG users codebase would be affected. These awkward little areas associated with this change are really down to trying to minimize the collateral damage to end users building against the OSG. End users have enough hassles to deal with so I really don't like adding more burden to this. However, being endlessly conservative about changes would mean that we ended up with lots of old cruft in the scene graph that we are always constrained by, with these changes I'm trying to find a balance between cleaning up and making the OSG more flexible and retaining backwards compatibility. I hoping that these changes sit the right side of this line for most users, but it's difficult to know just how intrusive changes will be as I'm not party to all users codebases, this is where I need feedback from the community to help and why threads like this are important. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
