Hi Robert, You're right, it wasn't really a scenegraph as you described it. Basically, each subsystem had the scene stored in a manner that was optimal for its purposes. (e.g. collision/response stored spatially, entity repository stored for quick name searches, renderer stored by visibility and states/materials, etc.) It was an interesting system which provided some nice features, but like you said it did make other things require a more work.
E. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Robert Osfield > Sent: Friday, September 22, 2006 11:31 > To: osg users > Subject: Re: [osg-users] simple question regarding transforms > > Hi Ericm > > > On 9/22/06, Eric Maslowski <[EMAIL PROTECTED]> wrote: > > Thanks guys and thanks for the example, Don. With some of the past > engines > I've worked on, an entity/node had access to everything that defines > its > current state (xform, mat, etc.) and would just be derived from the > components that it needed. > > class Door: public Animatable, public Drawable, public Entity {}; > > > These weren't general purpose scene graphs then, perhaps not scene graphs > at all. > > A scene graph is princply about uses a directed graph to "compose" a > scene, both logically and spatially. It is an embodiement of the > composite design pattern, where functionality is set up using "has a" > relationships. > > This is different from the approach above where entities are setup via "is > a" relatioships. > > In OO programming the "has a" is well know to be much more flexibility. > However, with the flexibility that loose coupling brings the downside is > that some operations require more work to obtain the effective state of > subgraph. > > Robert. > _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
