"melo" <mel### [at] coxnet> wrote in message 
news:web.47c7cf38dddebe08587ef5e20@news.povray.org...
>I got myself into a few more exception errors.  Chris.  Your 
>recommendations on
> how to trace such an error is of utmost value, I wonder if it could go 
> into a
> How To library of information for those of us who tend to get themselves 
> into
> trouble quite often.
>
> Well, s/he is walking but s/he is not going anywhere.
>
> By rereading your posting it sounded like you used lots of neat 3D 
> geometry to
> figure out how to map 3D rotation vectors of joints into joints 
> coordinates in
> 3D.

I did spend a lot of time on developing the 3D geometry and joint rotation 
stuff to my own satisfaction.  I wanted a system where poses could be 
readily hand coded, so I wanted flexibility over how to specify each set of 
joint rotations.

> Given each segment spans two joints and the tree structure of Skeletal
> being then you have all you need to construct it and render it.

I wouldn't quite agree with this statement. Some body parts are only 
connected to one joint. Others are connected to many, for example the palm 
of each hand has joints with the wrist and with the base of each finger.

> I have taken a much simpler approach, and relied on POV-RAY for forward
> kinematics.  Given a pose, i.e joint rotation vectors involved in that 
> pose,
> and
> a hierarchically unioned CSG, placing
>
>      Rotate_Around_Trans( AVAR[R_Hip_Ind], JOC_R_Hip )
>
> kind of rotations throughout object creation, did the trick.  POV-RAY very
> nicely determines where to place segments as a result of a set of 
> rotations
> burried within CSG tree.
>
> Once I construct my Humanoid in his/her current Pose, I apply the same
> transformation to her/him as I render him.  So s/he gets nicely scaled and
> positioned in the display window.
>
> Now that all poses and transition are good enough, I thought I could make
> him/her move in the direction s/he takes his steps.  I calculated his step 
> size
> and tired to translate her/him by clock, so by the time s/he moves to his
> cross-over pose s/he would be completely moved over his one standing leg 
> which
> was his forward leg.
>
> I hoped
>
>   #if ( !VZero( Forward_Foot_Coord ) )
>      object {
>         TransformedHumanoid
>
>         //Align left side of object to be coplanar with Forward_Foot_Coord
>         Align_Trans( TransformedHumanoid, -x, Forward_Foot_Coord )
>
>         //Align bottom of object to be coplanar with Forward_Foot_Coord
>         Align_Trans( TransformedHumanoid, -y, Forward_Foot_Coord )
>      }
>
> Here Forward_Foot_Coord is the coordinates of whichever foot had just 
> strode
> forward. As Humanoid gathers his back leg into cross-over position his 
> center
> of gravity gets shifted over the heal of his forward foot.
>
> Align_Trans would be a very crude 1st approximation, what would you 
> recommend
> that I do?  So he moves.   For later, I like him to follow footsteps laid 
> out.

In mine I had an array to store all of the joint locations and a macro that 
repeatedly scanned back and forth through the array calculating locations 
that hadn't yet been calculated, where one of the adjoining ones had. To 
start the process of resolving the pose I therefore just had to fix the 
position of a single body part (using my ppFixBodyPart macro) then run the 
location resolution macro to resolve the remaining positions. It only had to 
scan back and forth a couple of times to resolve all unresolved positions.

For my walking animation I fixed the Right Foot for the first half and the 
Left Foot for the second half. Because the array ends up holding the 
position of both feet, I was able to simply display the position of the Left 
Foot at the end of the first half of the animation cycle and plug the result 
into the key frames for the second half of the animation.

I would think that you could achieve something similar with your accumulated 
tranformations using Align_Trans. You could use #debug to output the 
position where the moving foot comes flat on the ground. Presumably you 
record the cumulative transformations from a single fixed body part in an 
array. If so you can get the tranformation from any body part to any other 
body part by using 'inverse' to transform a point or an orientation vector 
relative to the fixed body part, then use the transform for the second body 
part to derive it's position/orientation.

 > For later, I like him to follow footsteps laid out.

I've thought about that in the past, but concluded it might be better and 
easier to define a walk path as a spline rather than trying to aim for very 
specific foot locations (though I never got around to trying either). I 
figured you could have a parameter to approximately control stridelength and 
then work out from the change of direction of the spline how much the body 
would need to turn to the left or right during a particular step. Scaling 
rotations to get the person turning and striding by roughly those amounts 
should be fairly trivial compared with working out specific foot-fall 
locations.

I also had thoughts on automating the transition to an alternative 
animation, such as transitioning from walking across a floor to climbing up 
some stairs. I figured that by defining a spline through space I could drop 
a line using the 'trace' function to the surface and work out whether the 
person needed to step up/step down or walk on the level automatically. Some 
of my initial workings on this were built into the crowd control functions 
where I positioned people on a surface, and used the 'trace' function to 
make sure they weren't too close to the edge or on too steep a gradient.

Laying out specific footsteps that the character's feet must hit starts to 
bring you into the difficult area of how to define more than one fixed body 
part and how to calculate movement so that the rest of the body moves 
without moving those fixed points.  It then gets tricky to make sure that 
the body parts still link up correctly.

Regards,
Chris B.

Post a reply to this message