"melo" <mel### [at] coxnet> wrote:
"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47a3eb67e148a5763c0d56f20@news.povray.org...
> >I am new to POV-RAY and animation, I have managed to create a H-ANIM
> >complaint
> > CSG based pov-ray Humanoid model and managed to provide AVARs (Animation
> > control
> > variables) to define control frame poses,  POV-RAY does animate each

frame
> > wonderfully on its own.
> >
>
> Hi Melo,
>
> It's very brave to start with human animation as this is normally

something
> of an advanced topic.

Hi Chris,

Well, I was not brave, I was uninformed and I was driven.  I thought
learning Humanoid Animation would combine my love of Figural Arts with
Computer Technology.  Besides, I needed to create virtual being to tell my
hard learned stories.  Stories of what it might mean to lose who you thought
you were.


> I hope you mean you're new to animation with POV-Ray and not new to both
> animation and POV-Ray. Otherwise you may find the learning curve a bit
> steep.
> The wording you've used below is not totally clear to me, so forgive me if
> I've misunderstood anything;

Sorry, I agree sometimes I get too wordy, sometimes I am to cryptic.  I am

afraid, I am the one who is responsible for misunderstanding.  So, please

accept my appologies for causing you to offer a solution to a problem that

was not the problem.


> > I had placed each of my control frames in its own block using multi-

stage
> > animation setup.

My I am so crytic.  Okay, once I defined my HUmanoid based on joint center
locations as given by H-ANIM standard, and based on parent=child hierarcy
definition, I inserterted rotation transformations into the union tree at
approriate places.
   Rotate_Around_Trans( rl_elbow_ctl, JOC_l_elbow )
based on joints at which rotation was going to be allowed.  The parent-child
hierearchy right was very important so that when a movement happens at a
node all of its children should move.  For example if I want my Humanoid to
raise his right arm, I want his right hand to come along.  While in that
position, I could decide to get him wave his right hand Goodbye, well I
accomplish that by rotating his right hand about his right wrist.  As he
waves, I don't want him to lose any of his fingers they should all follow
along.  If I wanted his fingers to be slightly bend as he waived, I needed,
rotate each finger seperately.

Let's use this example to say I set up a staged animation. In stage 1, I set
right shoulder joint AVAR so arm is raised in steps
In stage 2, I bend fingers and rotate wrist in steps so hand is waived.
Since in both cases I call the same macro to draw my humanoid and and render
it.  How stage 2 is going to know that the waiving is to happen when the arm
is up.  Once arm got up, I have to have a way to remember to keep it there.
Ah, that was what was missing. I am afraid.

I created 13 animation stages, each stage was describing all joint locations
for a key frame, then building Humanoid as a tree of UNIONS with burried
rotation spec if any specified.  let me give you an example

   #range( 4.0, 5.0 )
      //=== FRAME 7: CROSS OVER RIGHT
      // straighten bend left elbow, bend right elbow
      #declare IBP = clock - 4.0;  // In-Between Position counter
      #declare Action = 2.207; // "CrossOver.Right.Frame7
      // declare all AVARs associate with right cross over
      #declare l_hip_ctl = <-21*IBP, 0, 0>;
      #declare l_knee_ctl = <21*IBP, 0, 0>;
      #declare r_ball_ctl = <0, 0, 0>;
      #declare HumanoidRoot_ctl = <-10*IBP, -60, 0>;
      // there were quite a number of AVAR speciications

      #declare Human_Trans_2_2_07 =
      transform {
         //scale 5 // <5, 5, 5>
         translate l_step_size*clock*z  // now the body takes his step
         //rotate <-10*IBP, -60, 0>
         };

      Move_Humanoid( Action )
      #declare Humanoid_2_2_07 = Humanoid;  // make a copy with transformations
      object{ Humanoid_2_2_07 transform Human_Trans_2_2_07 } // render it
   #break


My Move_Humanoid( Action ) macro is the one that build Humanoid and applied
joint rotations at the appropriate places in the hierarchy,

Given I had 13 key frames each described in its own #range block, I decided to
generate 5 In-Between-Positions within each animation stage so, my .,ini file
looked like
  ..
  Initial_Frame = 1
  Final_Frame = 65
  ;Subset_Start_Frame = 1
  ;Subset_End_Frame = 13
  Initial_Clock = 0.0
  Final_clock = 13.0
  Cyclic_Animation = no
  Input_File_Name = 'Hanim3LOA.pov'

What I think I was seeing was my Humanoid going from its default pose, lets call
it Frame 0 to the pose targetted in the current animation stage.

Let's say now we are in animation stage 10.  POV-RAY has generated 9*5=35
renderings already.  35th pose corresponded where Key-Frame 9 intended to take
my guy.  When the stage 10 starts, what I see is my Humanoid being rendered in
pose 0.  That is, he jumps to pose 0 from pose 35, then in 5 steps, I see him
slowly moving into the pose targetted for Stage 10 from Frame0=Pose 0.

May be this was because in staged animation, Humanoid was not maintaining its
pose memmory?

Do you think I need to device a way to remember the last state of AVARs in each
animation stage?  Then when a new stage starts, I can set my Humanoid to where
the previous stage left him at?

>
> If I understand your code sample below correctly you already have a
> variable
> defined for the default position of each object - effectively an anatomical
> definition, based upon the default pose for H-Anim forms -  and a variable
> for each individual joint rotation (the pose). Presumably the unions in your
> CSG correspond to the anatomy so that successive rotations correctly adjust
> the ultimate position and orientation of any body parts that are affected
> by a succession of rotations by virtue of the fact that they are connected to
> other moving parts.

Yes.  Correct.  I wonder if we can form  skeletal animation interest group

and then I would be glad to share what I have so far.  My union are
hieararchically structured so that movement higher up in the tree effect all of
its children, while the branches of tree are free to move - coresponds to fine
motor control?-.

Ah, I am afraid for hands and feet I would need to create separate animations.
Trying to do it all in one .pov file will get too unruely.
>
> If I understand your problem correctly you need some way of calculating
> intermediary sets of joint rotations so that you can engineer a smooth
> transition from one pose to another;

Well, my thinking had not progressed that far yet.  I am afraid you are waay
ahead of me.  For this walk/ran animation, I manually defined enough key
frames. 13 key-frames for 2 steps.   I left it to POV-RAY to generate the
additional in-Betweens posses.

I wonder if my problem was me calling the macro that reconstructed my
hierarchically unioned Humanoid definition within each animation stage.  So, at
the beginning of each new animation stage Humanoid appeared to jump back to his
initial pose as opposed to continuing from the pose I left him at in the
previous stage.


> > Is there a way to query coordinates of my AVAR joint objects from a nested
> > CSG
> > Object, which is what my Humanoid is, so I can transform my Humanoid to
> > where
> > the previous movements had left him at the beginning of the each new
> > stage?
> >
>
> I think what you're asking is to be able to do is to make a macro call from
> within the CSG definition that will look up two values for the same
> variable, from different pose files,

pose files?  Now that is a new term.  Did I miss a file type tha t POV-RAY
supports.

> and return an intermediary set of
> rotations. Conceptually it is possible and I can think of a number of
> approaches, but they all get pretty messy given the way your variables are
> defined. So you could have one macro per joint that reads one pose file,
> copies the required value into a temporary variable then reads the other
> pose file and returns the results of processing the two values, but this is
> extremely cumbersome and involves a lot of unnecessary IO. You could have a
> single macro and pass it some indication of which variable you want, but
> this is difficult and will also get very messy very quickly.

I agree, this does not sound like an approach I would go for.

> The approach I took for POV-Person

POV-Person??  My gosh was there already a skeletal animation in the public
domain.  Well, I have spent 2-3 months to come this far, but I have learned
more in the process.

> was to assign all of the rotations to an
> array, recording the array index into a variable with a real-world joint
> name, so I could access an individual rotation as
> JointRotations[L_Elbow_Ref], but it also meant that I could process the
> whole array by using a #while loop to loop through the array elements. To
> calculate intemediary poses I then used a macro to:
> 1. read one pose file
> 2. copy all elements into a temporary array
> 3. read a second pose file
> 4. copy all elements into a second temporary array
> 5. calculate the intermediary rotations (based on the desired interpolation
> methods -  linear, sinusoidal etc.) and write them back into the main array
> which the SDL could subsequently use to create the figure.

WOW.  I love your array idea.  Thank you. It will make my code a whole lot more
understandable and maintainable.  As for interpolating additional poses, I had
not progressed that far in my thinking either.  I painfully defined as many
key-frames as I could.  I guess for future work, defining fewer key frames and
interpolating additional ones might be better.

Is there a documentation on how interpolation could be done in POV-RAY
>
> This only had to process the two pose files once and could be run before
> building the CSG. From within the CSG you could then access the individual
> rotations using the 'JointRotations[L_Elbow_Ref]' notation.
>
> > After he walks he can learn TaiChi and Yoga with me.
> >
>
> There are already quite a few BVH files about, so he may be able to learn
> quicker than you. :-)

My, While I was burried working at SAS Institute Inc.for 15 years until 3.5
years back, 3d computer graphics and animation got light years ahead.
Supposedly I pursued a minor in ECE back then computer graphics was its
infancy.  VRLM is outside my realm of knowledge, it sounds so much more
powerful.  Yet one more thing to teach myself.

Well sorry for being this verbose.  I was kind of feeling uneasy about not
knowing what BVH files are all about.  Thanks Universe there is Google.

I appreciate your input and recommendations.

Meltem



>
> > This is too much detail but the variable name declared for one joint
> > object
> > center is like
> >
> > #declare JOC_l_elbow = <a, b, c>; // These are from H-ANIM ISO standard
> > #declare JOC_l_wrist = <d, e, f>;
> >
> > #declare joint_radius_arm = 0.3; // These are some values I picked
> >
> > #declare l_elbow_ctl = <x, y, z>; // a rotation control vector  All my
> > AVARs
> >                            // have _ctl suffix, for an example I show

one
> > here.
> >
> > then in my Humanoid CSG definition is something like
> >
> > #declare Humanoid =
> > Union {
> >  sphere{
> >  cone{..
> >  union{
> >    sphere{
> >    cone{
> >    sphere{
> >    cone{
> >    union{
> >      sphere{ JOC_l_elbow, joint_radius_arm }
> >      cone{ JOC_l_elbow, joint_radius_arm, JOC_l_wrist, 0.0 }
> >      #if ( VZero(r_elbow_ctl) )
> >      #else
> >         Rotate_Around_Trans( rl_elbow_ctl, JOC_l_elbow )
> >         //Rotate_Around_Trans( l_elbow_ctl, vtransform( JOC_l_elbow,
> > Human_Trans ) )
> >      #end
> >     }
> >      }
> >    }
> >  };
> >
>
> I hope I've understood your question correctly and that the answer helps in
> some way.
>
> Regards,
> Chris B.

thank you very much Chris.  How about creating an interest group for skeletal
animation.  Well.  Rigging, Inverse kinematics awaits me.

Meltem

Post a reply to this message