Ok, this explains what is going on. In my case the "group" was in the ac3d hierarchy. But the effect is still the same. The group member is being moved out of the ac3d hierarchy and plopped into the branch for the select tag. So...hmmm...well I can always do one or the other individually. It seems as though defining separate "select" tags for individual group members would be a bit cheaper than rotate or translate (no math involved).
BTW your response might be a good addition to the model how-to. Even leave the first paragraph in there somewhere (as a footnote or something) since it succinctly describes the issue for those with even a little knowledge of plib. Best, Jim David Megginson <[EMAIL PROTECTED]> said: > Jim Wilson writes: > > > It looks like the animation code fails to move a group object if > > one of it's subobjects is identified in a object selection tag. > > When you add a new animation, the animation code slices a new > ssgBranch of some kind between the existing node and its parent -- > that should never cause any problem. If, however, you specify several > nodes for the same animation, all but the first will be moved to the > new ssgBranch. So if you have > > <animation> > <type>translate</type> > <object-name>Foo</object-name> > <object-name>Bar</object-name> > ... > </animation> > > <animation> > <type>rotate</type> > <object-name>Hack</object-name> > <object-name>Bar</object-name> > ... > </animation> > > The Bar object will be be reparented first to the ssgBranch above Foo, > then to the ssgBranch above Hack (losing the 'translate' animation). > You can work around this problem with > > <animation> > <type>translate</type> > <object-name>Foo</object-name> > <object-name>Bar</object-name> > ... > </animation> > > <animation> > <type>rotate</type> > <object-name>Hack</object-name> > ... > </animation> > > <animation> > <type>rotate</type> > <object-name>Bar</object-name> > ... > </animation> > > If you specify only one object-name, the object should always stay in > the same group. That's slightly less efficient, but if you picture > the way the animation code modifies the tree, you'll be able to figure > out when you really need it and when you don't. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
