re: [Flightgear-devel] model animation bug
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 typetranslate/type object-nameFoo/object-name object-nameBar/object-name ... /animation animation typerotate/type object-nameHack/object-name object-nameBar/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 typetranslate/type object-nameFoo/object-name object-nameBar/object-name ... /animation animation typerotate/type object-nameHack/object-name ... /animation animation typerotate/type object-nameBar/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
re: [Flightgear-devel] model animation bug
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 typetranslate/type object-nameFoo/object-name object-nameBar/object-name ... /animation animation typerotate/type object-nameHack/object-name object-nameBar/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 typetranslate/type object-nameFoo/object-name object-nameBar/object-name ... /animation animation typerotate/type object-nameHack/object-name ... /animation animation typerotate/type object-nameBar/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. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
