My initial reaction is that it's far too late. We should have addressed these types of problems several years ago when they were first raised, at a point where we could have developed design policy decisions aroud these and other related design issues. We simply can't be compatible with everyone, and we have lacked the necessary manpower and focus to support a greater generality than we already have. This is not a simple matter of 'patching' existing controllers. We accepted a certain simplicity which has allowed us to move forward to where we are now. Otherwise we are faced with something akin to starting over from scratch, and falling much further behind than I suspect our funding can tolerate.
On the other hand, it may be possible to address some of this by adding new joints to the skeleton that existing controllers ignore, which maintain fixed rotational offsets between the joints that get manipulated. I would not proceed lightly with this. We are flirting with painful complexity. -Marcus On Fri, 11 Jul 2008, Andrew n marshall wrote: > > I just had an inquiry about our lack of support of per-joint rotational > offsets. That is a skeleton joint with zero rotation always has the > same rotational coordinate system as its parent. This implies.. > * ...a skeleton with every rotation zeroed-out, every joint with share > the world's rotational coordinate system. > * ...a positive-z rotation around one elbow with not be symmetrical > with the positive-z rotation around the other elbow. > * ...SmartBody prefers unnatural, "rectilinear" default/"zero" postures > so that bones lengths exist along a single axis (an arm segment is +/-X, > a leg segment is -Y, etc.). > > We've just run into this problem again when trying to import animation > data from another project. > > I'm not happy with the results, and I'd like to discuss how to change > the situation. Adding support for rotational offsets will help us do > simple tasks like flipping an animation. It should also simplify > asymetrical procedural controllers, like walk & point, as they will need > less code to abstract or special case left and right sides. > > However, I think our support for multiple rotation types (Euler, > quaternions, and swing-twist) will complicate the issue. Each rotation > type will need its own offset format. > > It will also require we add support for these offsets to our existing > procedural controllers (gaze in particular), and may break several prior > assumptions, like our straight, vertical spine. > > > This is not something we can jump on right away, but I believe it is a > long standing issue we will need to address. > > Thoughts and comments are welcome. > > > > Anm > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Smartbody-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/smartbody-developer > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Smartbody-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/smartbody-developer
