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.  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 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.

Thanks,
Meltem

Post a reply to this message

"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

"Chris B" <nom### [at] nomailcom> wrote:
> "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

This is an interesting discussion. thank you for sharing


[url=http://simulationpretpersonnel.com][color=#FFFFFF][u]pret personnel
enligne[/u][/color][/url][color=#FFFFFF] - Pret personnel en ligne et de
[/color]

Post a reply to this message

"comrau00" <com### [at] gmailcom> wrote in message 
news:web.4a67bf943b8517b42893924d0@news.povray.org...
>
>
> This is an interesting discussion. thank you for sharing
>

You may be interested to see the results of my efforts, including the 
walking animation and the crowd scene I mentioned, which are displayed on a 
page at http://www.geocities.com/povperson/.  But be warned that it's a 
largely abandoned project and I don't know of anyone who currently uses 
those macros.

Regards,
Chris B.

Post a reply to this message