Re: [Algorithms] Finding the best pose to re-enter animation graph from ragdoll

[Alex L. <lin...@gm...>]

I figure you've got 3 normalized vectors:

dollForward = stomach of ragdoll vector, pointing along Y, downwards (not
sure if positive or negative)
dollUp = along spine towards head of ragdoll
recoveryForward = stomach of recovery pose

dollForward DOT recoveryForward will be near 1 if the doll is on its
stomach. The same dot can be run against other categories of recovery pose
for lying on side or back. Camera look-at style cross products with dollUp
and dollForward will get you 3 axes and from them, a quat or matrix to
apply to the recovery pose root, or take vectors to or from 'doll space' to
'recovery space' to match other limbs against your
recovery-poses-on-stomach db.

Just writing aloud, hope it helps!



On Thu, Dec 13, 2012 at 11:39 AM, Jeff Russell <je...@gm...> wrote:

> There are probably a number of ways to do it. My first guess would be to
> compute the difference in rotation for the root bone (that is, what
> rotation takes you from your starting frame to the current ragdoll
> orientation), and then examine the "up" vector of the resulting transform.
> If it's too far from vertical, you don't have a very good match. You can
> compute a score perhaps based on the dot product between the "up" basis of
> this transform and the global up direction.
>
>
> On Thu, Dec 13, 2012 at 1:22 PM, Richard Fine <rf...@tb...> wrote:
>
>> Hi all,
>>
>> I've got a ragdolled character that I want to begin animating again.
>> I've got a number of states in my animation graph marked as 'recovery
>> points', i.e. animations that a ragdoll can reasonably be blended back
>> to before having the animation graph take over fully. The problem is,
>> I'm not sure how to identify which animation's first frame (the
>> 'recovery pose') is closest to the ragdoll's current pose.
>>
>> As I see it there are two components to computing a score for each
>> potential recovery point:
>>
>> 1) For each non-root bone, sum the differences in parent-space rotation
>> between current and recovery poses. This is simple enough to do; in
>> addition I think I need to weight the values (e.g. by the physics mass
>> of the bone), as a pose that is off by 30 degrees in the upper arm
>> stands to look a lot less similar to the ragdoll's pose than one that is
>> only off by 30 degrees in the wrist. The result of this step is some
>> kind of score representing the object-space similarity of the poses.
>>
>> 2) Add to (1) some value representing how similar the root bones are.
>> The problem I've got here is that I need to ignore rotation around the
>> global Y axis, while still accounting for other rotations. (I can ignore
>> position as well, as I can move the character's reference frame to
>> account for it).
>>
>> Suppose I have a recovery pose animation that has been authored such
>> that the character is lying stretched out prone, on his stomach, facing
>> along +Z. If the ragdoll is also lying stretched out prone on his
>> stomach, facing -X, then the recovery pose is still fine to use - I just
>> need to rotate the character's reference frame around the Y axis to
>> match, so the animation plays back facing the right direction. But, if
>> the ragdoll is lying on his back, or sitting up, then it's not usable,
>> regardless of which direction the character's facing in. So, I've got
>> the world-space rotation of the ragdoll's root bone as a quaternion, and
>> a quaternion representing the rotation of the corresponding root bone in
>> the recovery pose in *some* space (I think object-space, but I'm not
>> sure?) as starting points. What can I compute from them that has this
>> ignoring-rotation-around-global-Y property?
>>
>> It's been suggested there there's some canonicalization step I can
>> perform that would just eliminate any Y-rotation, but I don't know how
>> to do that other than by decomposing to Euler angles, and I suspect that
>> would have gimbal lock problems.
>>
>> This is probably some pretty simple linear algebra at the end of the
>> day, but between vague memories of eigenvectors, and a general
>> uncertainty as to whether I'm just overcomplicating this entire thing, I
>> could use a pointer in the right direction. Any thoughts or references
>> you could give me would be much appreciated.
>>
>> Cheers!
>>
>> - Richard
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> GDAlgorithms-list mailing list
>> GDA...@li...
>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>>
>
>
>
> --
> Jeff Russell
> Engineer, Marmoset
> www.marmoset.co
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>