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.

I had placed each of my control frames in its own block using multi-stage
animation setup.

What's missing is figuring out how to tie my frames smoothly.  Each pose in each
frame involve quite a number of joint object (represented by spheres) rotations
to take place.  The next frame needs to start off where the previous frame left
off.  What I see instead my humanoid jumping all over the screen from stage to
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?

After he walks he can learn TaiChi and Yoga with me.

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
     }
      }
    }
  };

Post a reply to this message

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

> I had placed each of my control frames in its own block using multi-stage
> animation setup.
>
> What's missing is figuring out how to tie my frames smoothly.  Each pose 
> in each
> frame involve quite a number of joint object (represented by spheres) 
> rotations
> to take place.  The next frame needs to start off where the previous frame 
> left
> off.  What I see instead my humanoid jumping all over the screen from 
> stage to
> stage.
>

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.

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;

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

The approach I took for POV-Person 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.

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

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

Post a reply to this message

"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.
> 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;
>
> > I had placed each of my control frames in its own block using multi-stage
> > animation setup.
> >
> > What's missing is figuring out how to tie my frames smoothly.  Each pose
> > in each
> > frame involve quite a number of joint object (represented by spheres)
> > rotations
> > to take place.  The next frame needs to start off where the previous frame
> > left
> > off.  What I see instead my humanoid jumping all over the screen from
> > stage to
> > stage.
> >
>
> 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.
>
> 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;
>
> > 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, 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.
>
> The approach I took for POV-Person 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.
>
> 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. :-)
>
> > 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.

Post a reply to this message

"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

Wow, You were right, that is a lengthy response :-)

I'll respond out of sequence if that's ok:

> How about creating an interest group for skeletal
> animation?

It's been a personal interest of mine for a long time, but I haven't seen 
more than a handful of people interested in using POV-Ray for this sort of 
thing over the years. Partially because it is very difficult to do just 
using POV-Ray and partially because you can readily do human animations in 
Poser, which is a commercial product that is not very expensive these days 

POV-Ray meshes using Poseray.

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

POV-Person is free to use, modify and redistribute (see 
http://www.geocities.com/povperson/), so you can use anything from there 
that you like. Body parts, poses and anatomical definitions are all split 
out into separate files to make it easier to modify. I haven't developed 
very much after publishing the V2 code that's on that site because there 
seemed to be only a tiny amount of interest in it (though I do have some 
moving hair macros and lip, eyelid and eyelash animation macros that I've 
done since then). It took me a few years to get that far and I learned a lot 
about how to structure the files and the optimum sequence for assembling 
animated models. I have a couple of diagrams on how the structure builds 
into an animateable figure that I could probably find if you're interested.

There are now also some public domain human modelling initiatives on the go 
that you might be interested in. If you do a Google on "open source human 
modelling" there's now nearly 15 million hits (whereas there weren't any 
when I started). One of the links I see there leads through to 
http://www.dedalo-3d.com/index.php for MakeHuman, which claims to be an open 
source equivalent to poser. It produces 'obj' files, which I believe PoseRay 
should be able to convert.

> VRLM is outside my realm of knowledge, it sounds
> so much more powerful.

Ah. I'd assumed you had chosen to use H-ANIM because it was a standard 
designed for VRML.

> 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.
> ... snip ...
> pose files?  Now that is a new term.  Did I miss a file
> type that POV-RAY supports.

I'd assumed that you'd defined each pose in a separate file (there's not a 
separate POV-Ray file type).

> I left it to POV-RAY to generate the
> additional in-Betweens posses.

I think that this is your main problem. POV-Ray doesn't retain any knowledge 
about the objects in the previous frame when it is parsing a subsequent 
frame. The only information it passes between frames is the frame number, 
the clock variable and other stuff to do with the animation cycle. If you 
need it to know anything about your objects or variable definitions from the 
previous frame then you have to tell it.

There are various approaches you can take to do this. You can use the IO 
functions to write information out to a file from one frame so that you can 
read it in when you generate the next frame. Alternatively you can add 
conditional statements to accumulate positional or rotational information up 
to the point required.

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

I think you'd have to call your macro each time to set the required 
variables, but your macro seems to just add a bit of rotation to the initial 
pose each time. Your examples seems to show the keyframe position/rotation 
information all mixed in together with an interpolation calculation:

>      #declare IBP = clock - 4.0;  // In-Between Position counter
>      #declare l_hip_ctl = <-21*IBP, 0, 0>;

Your 'IBP' variable changes from 0 and 1 as the clock progressively passes 
from 4 to 5 in successive frames. This effectively interpolates in a linear 
fashion between 0 and -21 for the 'x' rotation of the hip. This could be 
seen as defining a keyframe at clock=4 where all of the rotations are set to 
0 (the initial/default pose) and a key frame at clock=5 where the rotations 
are set to their required values.

What you really want to get to is something like:
l_hip_ctl = LeftHipFromPreviousStage + <-21*IBP, 0, 0>

You're likely to find this quite difficult to achieve with everything mixed 
in together like this.

One hack would be to effectively accumulate the rotations. You could 
initialise all of your variables then replace the #range specifications with 
a series of #if statements and cap IBP to 1 through each stage definition. 
For example:

// Initialise all variables
#declare l_hip_ctl = 0;
... replace the #range definitions with an #if clause for the start of each 
keyframe ..
#if (clock>=4)
  // Limit IBP, so that it goes from 0 to 1 then stays at 1.
  #local IBP = min(1,clock-4);
  // Accumultate the rotations by adding to the existing values
  #declare l_hip_ctl = l_hip_ctl + <-21*IBP, 0, 0>;

  ...
#end

However, this is a bit of a 'quick-fix' solution. If you want to go much 
further you're likely to want to move towards a different approach to make 
life easier down the line. I'd recommend considering using a seperate 
include file for each pose, using arrays to store the rotations and a macro 
call to do the interpolation.

Your current approach effectively hardcodes the interpolation mechanism into 
the pose definition structure. A linear interpolation of this kind gives a 
very jerky animation as one rotation in mid-flight could stop immediately 
and an alternative rotation, maybe at right angles, could commence. To get 
smooth transitions between key frames you're more likely to want to do 
non-linear interpolation to accelerate into a motion and decelerate at the 
end. If everything is mixed in together in a single file, you'll find 
yourself having to do a lot of unnecessary editing to achieve this.

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

The other advantage of splitting everything out is that it becomes 
terrifically easy to build composite poses. For example: You could have a 
walking animation keyframe containing the normal positions for arms and 
hands while walking. In a separate file you could define just the right arm 
positions for holding a cup in the right hand. To combine the two you can 
just do:

#include "WalkingKeyFrame4.inc"
#include "CupInRightHand.inc"

and the default arm positions from the first file get overridden by the 
second.


> Well, I was not brave, I was uninformed and I was driven.

There's not really a whole lot of difference in my experience :-)


Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> Wow, You were right, that is a lengthy response :-)
>
> I'll respond out of sequence if that's ok:

Absulutely.  Now I'll imitate you.

> > How about creating an interest group for skeletal
> > animation?
>
> It's been a personal interest of mine for a long time, but I haven't seen
> more than a handful of people interested in using POV-Ray for this sort of
> thing over the years. Partially because it is very difficult to do just
> using POV-Ray and partially because you can readily do human animations in
> Poser, which is a commercial product that is not very expensive these days

> POV-Ray meshes using Poseray.

My my, I am learning more and more.  Well, cost was a definite factor.  When I
noticed POV-RAY being mentioned in some research articles, it intrigued me even
more. Here was a scientifically sound, powerful tool making contributions to
science and humanity; let's not forget providing means for artistic expresssion
for those who need techology, i.e their left brain's help to unlock their right
brain's creative potential.  AND POV-RAY creators are not being driven by
material gain as they offer this enormous benefit.  Thank you ladies and
gentlemen.

Humanoid animation has both scientific and artistic applications.  It is an
incredible area.  I like to get my skeleton moving, so I can turn my attention
to the application areas I am interested in.


> >> 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.
>
> POV-Person is free to use, modify and redistribute (see
> http://www.geocities.com/povperson/), so you can use anything from there
> that you like. Body parts, poses and anatomical definitions are all split
> out into separate files to make it easier to modify.

Thank you Chris.  I will download it, I am sure it will teach me a lot about
POV-RAY and animation.

I like modularity.  I had a slighly different break down in mind.  Well it was
too long so I moved it to the end marked by ==========

>I haven't developed
> very much after publishing the V2 code that's on that site because there
> seemed to be only a tiny amount of interest in it (though I do have some
> moving hair macros and lip, eyelid and eyelash animation macros that I've
> done since then). It took me a few years to get that far and I learned a lot
> about how to structure the files and the optimum sequence for assembling
> animated models. I have a couple of diagrams on how the structure builds
> into an animateable figure that I could probably find if you're interested.

Absolutely.  Where are you based Chris?
>
> There are now also some public domain human modelling initiatives on the go
> that you might be interested in. If you do a Google on "open source human
> modelling" there's now nearly 15 million hits (whereas there weren't any
> when I started). One of the links I see there leads through to
> http://www.dedalo-3d.com/index.php for MakeHuman, which claims to be an open
> source equivalent to poser. It produces 'obj' files, which I believe PoseRay
> should be able to convert.

My gosh, another thing to play with.  Thanks.  Now a days, I am more interested
in the application areas of the animation, than tool development.

>
> > VRLM is outside my realm of knowledge, it sounds
> > so much more powerful.
>
> Ah. I'd assumed you had chosen to use H-ANIM because it was a standard
> designed for VRML.

Nope.  I had chosen it, because there was a standard, and it defined geometry of
the skeleton.   When all said and done, 1:8 ratio human model I have heard in my
art classes would have been sufficient.  Oh well.  I like standards, they
represent product of many brain powers coming to a consensus.

> <...snip...>
> > I left it to POV-RAY to generate the
> > additional in-Betweens posses.
>
> I think that this is your main problem. POV-Ray doesn't retain any knowledge
> about the objects in the previous frame when it is parsing a subsequent
> frame. The only information it passes between frames is the frame number,
> the clock variable and other stuff to do with the animation cycle. If you
> need it to know anything about your objects or variable definitions from the
> previous frame then you have to tell it.

Thanks Chris.  After our discussion, I have beginning to see this.


> There are various approaches you can take to do this. You can use the IO
> functions to write information out to a file from one frame so that you can
> read it in when you generate the next frame. Alternatively you can add
> conditional statements to accumulate positional or rotational information up
> to the point required.

Back to POV_RAY help to see how it does IO.  I likes the other idea better
anyways.
>
> > 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.
>
> I think you'd have to call your macro each time to set the required
> variables, but your macro seems to just add a bit of rotation to the initial
> pose each time. Your examples seems to show the keyframe position/rotation
> information all mixed in together with an interpolation calculation:
>
> >      #declare IBP = clock - 4.0;  // In-Between Position counter
> >      #declare l_hip_ctl = <-21*IBP, 0, 0>;
>
> Your 'IBP' variable changes from 0 and 1 as the clock progressively passes
> from 4 to 5 in successive frames. This effectively interpolates in a linear
> fashion between 0 and -21 for the 'x' rotation of the hip. This could be
> seen as defining a keyframe at clock=4 where all of the rotations are set to
> 0 (the initial/default pose)

Duh!  Now I am feeling rather stupid.  Sorry for taking this much of your time
for such a stupid mistake.
> and a key frame at clock=5 where the rotations
> are set to their required values.
>
> What you really want to get to is something like:
> l_hip_ctl = LeftHipFromPreviousStage + <-21*IBP, 0, 0>
>
> You're likely to find this quite difficult to achieve with everything mixed
> in together like this.
>
> One hack would be to effectively accumulate the rotations.

well,  not all rotations go up and up, for accumulations to work.  Initially, I
have much fewer key-frame 1 for Stride-Left, next for CrossOver Right, third
for Stride Right and last one Cross over left.  The moves looked so jerky I
went back and added many transition frames, took me forever.  For example, all
transition Frames from Stride-Left to CrossOver Right could work with
incrementation hack.  Since all joints continue swinging in the same direction.
Right leg swings from all the way back left to cross over pos, arms swing in
same direction etc.  At CrossOver Right move things change.

> You could
> initialise all of your variables then replace the #range specifications with
> a series of #if statements and cap IBP to 1 through each stage definition.
> For example:
>
> // Initialise all variables
> #declare l_hip_ctl = 0;

Did you mean
  #declare l_hip_ctl = <0,0,0>;

or is POV-RAY more variable type neutral?

> ... replace the #range definitions with an #if clause for the start of each
> keyframe ..
> #if (clock>=4)
>   // Limit IBP, so that it goes from 0 to 1 then stays at 1.
>   #local IBP = min(1,clock-4);
>   // Accumultate the rotations by adding to the existing values
>   #declare l_hip_ctl = l_hip_ctl + <-21*IBP, 0, 0>;
>
>   ...
> #end
>
> However, this is a bit of a 'quick-fix' solution. If you want to go much
> further you're likely to want to move towards a different approach to make
> life easier down the line. I'd recommend considering using a seperate
> include file for each pose, using arrays to store the rotations and a macro
> call to do the interpolation.

For the first go around getting poses into separate files, and using arrays are
wonderful ideas.  Doing interpolations with POV-RAY could come as an
enhancement.  As I am too new to POV-RAY to know how.
>
> Your current approach effectively hardcodes the interpolation mechanism into
> the pose definition structure. A linear interpolation of this kind gives a
> very jerky animation as one rotation in mid-flight could stop immediately
> and an alternative rotation, maybe at right angles, could commence. To get
> smooth transitions between key frames you're more likely to want to do
> non-linear interpolation to accelerate into a motion and decelerate at the
> end. If everything is mixed in together in a single file, you'll find
> yourself having to do a lot of unnecessary editing to achieve this.

I hear you.  It makes perfect sense.  Now let me make an uneducated guess, what
if we played with clock so it does not advance linearly.  Say, I like to raise
my right arm:
   #declare myClock = a*clock*clock + b*clock + c;
   r_shoulder_ctl = <180*myClock, 0, 0>

> > 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.
>
> The other advantage of splitting everything out is that it becomes
> terrifically easy to build composite poses. For example: You could have a
> walking animation keyframe containing the normal positions for arms and
> hands while walking. In a separate file you could define just the right arm
> positions for holding a cup in the right hand. To combine the two you can
> just do:
>
> #include "WalkingKeyFrame4.inc"
> #include "CupInRightHand.inc"
>
> and the default arm positions from the first file get overridden by the
> second.
>
>
> > Well, I was not brave, I was uninformed and I was driven.
>
> There's not really a whole lot of difference in my experience :-)

The more you start learning about anything new, the more you realize there is to
know. I need to remember not to get owerwhelmed. I just want to get my person
walking for starters, then I can change tracks and go see what POVperson is
upto.

Story telling, and research awaits me.  Could PovPerson be used in both?

========================= Had there been endless time I would have liked to
reorganize like:
o  Skeletal_animation.pov  defines geometry, hiararchical relationships among
moving body parts. (It should also define maximum allowed for joint rotations)
For each kind of vertabrate there would be one file.
   - human
   - horse (using two human skeleton can make horse, I was so thrilled when
     I came across that tid-bit)

o  Now I love and add the idea of pose=key-frame definitions to be moved to
their own seperate files.  Thank you Chris.  How wonderful.   Poses will define
the rotation vectors of joints involved in the movement. Did you execute poses
in different animation stages as I had done?

o  3D polygonal meshes defining characters, or an anthropologic databases of
vertexes.  I see some free 3D poly models poping up.  (it appears there are
lots of tools that can allow an artist to create a beautiful 3d mesh + texture.
 There are actually laser scanners that could be scanning actual people to
create those meshes.  Whatever their origin..)
   Here I have an extra step planned:
     SAS software can do nearest neighboorhood clustering so I can feed my
skeletal vertexes for body parts, and 3d polygon vertices, the purpose is to
assign 3d polygon surfaces to skeleton segments and joints.  That would be
mathematical way of rigging.  If polygon mesh is defined translucent and both
H-ANIM skeleton and polyperson is overlaid, there would be visual verification
of rigging.
-  One representative of various age groups, genders, ethinicities could be
prerendered to provide a selection.
-  well I was thinking characters would be wearing their birth suits.

o Biomechanical layer: Once a polymesh is rigged around skeleton, it defines a
volume and mass for each segment that knows how to move.  As body segments are
moved in the air, I could start calculating, forces, moments, work done, energy
expanded in the move, all sorts of mechanics.

o Well with the creation of skeletal, animation loop, and pose file we got
forward kinematics under our belt.  almost in my case.

o How about inverse kinematics?
Well SAS Non Linear Programming, Optimization procedures to the rescue.  In the
biomechanical layer, I would calculate energy expanded in moving joint A vs
joint B.  Now I can ask SAS to solve a minimization problem and calculate which
joints should be involved in the move by how much.  It will return the set of
joints that minimize the kinetic energy expanded. Assuming, I could formulate
possibilities.  These are all rough ideas, a dream.

My gosh you got facial expressions, hair, clothing items all added to your
PovPerson?  I guess with face skeletal animation does not work?  Jaw is the
only movable joint, while there are numerous muscles moving facial organs,
generating expressions?!

I hope there is doc with POVPerson, could it be used in research?

Could it be used in story telling?

Thanks,

Meltem

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47a94d403df0d7073c0d56f20@news.povray.org...
> "Chris B" <nom### [at] nomailcom> wrote:
>>
>> What you really want to get to is something like:
>> l_hip_ctl = LeftHipFromPreviousStage + <-21*IBP, 0, 0>
>> One hack would be to effectively accumulate the rotations.
>
> well,  not all rotations go up and up, for accumulations to work.

You can accumulate any mix of positive and negative rotations.

>> // Initialise all variables
>> #declare l_hip_ctl = 0;
>
> Did you mean
>  #declare l_hip_ctl = <0,0,0>;
> or is POV-RAY more variable type neutral?

It's not quite neutral, but it does promote floats to vectors if it needs 
to.

> I hear you.  It makes perfect sense.  Now let me make an uneducated guess, 
> what
> if we played with clock so it does not advance linearly.  Say, I like to 
> raise
> my right arm:
>   #declare myClock = a*clock*clock + b*clock + c;
>   r_shoulder_ctl = <180*myClock, 0, 0>

That is the sort of thing, though I've found trigonometrical functions like 
the sine function are often more handy than quadratics for smoothing out the 
start and end of movements.

> My gosh you got facial expressions, hair, clothing items all added to your
> PovPerson?  I guess with face skeletal animation does not work?  Jaw is 
> the
> only movable joint, while there are numerous muscles moving facial organs,
> generating expressions?!

Indeed! Skeletal animation is just the first step. Muscle deformation comes 
next. I started work on deforming the upper and lower eyelid meshes as they 
opened and closed and had started splitting out the mesh around the mouth to 
implement something like the lipsync macro that Rune 
(http://runevision.com/3d/anims/) developed. I also have a deformable mesh 
for each finger segment, but never got round to integrating my muscular 
finger code back into the main deck of POV-Person SDL.

> I hope there is doc with POVPerson, could it be used in research?
> Could it be used in story telling?

There is documentation on the web site. I also have further documentation 
for bits I developed since V2. I think there are many things it could be 
used for. The SDL and the documentation is licensed to encourage reuse.

Regards,
Chris B.

Post a reply to this message

>>I haven't developed
>> very much after publishing the V2 code that's on that site
>> ...
>> I have a couple of diagrams on how the structure builds
>> into an animateable figure that I could probably find if you're 
>> interested.
>
> Absolutely.  Where are you based Chris?
>

I've found a copy in PowerPoint format. If you have PowerPoint I'll email 
you a copy.
Otherwise I can save as a JPG or PNG.

I'm UK based. How about you?

Regards,
Chris B.

Post a reply to this message

"Chris B" <nom### [at] nomailcom> wrote:
> "melo" <mel### [at] coxnet> wrote in message
> news:web.47a94d403df0d7073c0d56f20@news.povray.org...
> > "Chris B" <nom### [at] nomailcom> wrote:
> >>
> >> What you really want to get to is something like:
> >> l_hip_ctl = LeftHipFromPreviousStage + <-21*IBP, 0, 0>
> >> One hack would be to effectively accumulate the rotations.
> >
> > well,  not all rotations go up and up, for accumulations to work.
>
> You can accumulate any mix of positive and negative rotations.
>

Well, I was so excited that I might find a solution, I started implementing the
array approach right away with slight modifications and simplist approach that
came to mind.  Even with that I managed to shut myself in the foot:

1. Declared the array as a 2d array
  #declare AVAR = array[23][23];
                         //  first dim is for Key-Frame id, goes by odd numbers
                         //  1..23, second is for Animation control variables
                         //  whose indeces are defines as
  #declare HumanoidRoot_ind = 1;
  #declare neck_ind = 2;
  #declare lower_back_ind = 3;
  #declare l_hip_ind = 4; //
  #declare l_knee_ind = 5; //
  .. snip goes all the way to index 23

2. Initialized its element to be all 0 rotation vectors
#declare Frame = 1;
#while ( Frame < 23 )
   #declare AVarIndex = 1;
   #while ( AVarIndex < 23 )
      #declare AVAR[Frame][AVarIndex] = <0, 0, 0>;
      #declare AVarIndex = AVarIndex + 1;
   #end
   #if ( Frame = 5 | Frame = 6 | Frame = 17 | Frame = 18 )
      #declare Frame = Frame + 1;
   #else
      #declare Frame = Frame + 2;
#end


3. Changed my code in my Range stmts to something like, to simulate simplest
linear interpolation

   #range( 2.0, 3.0 )
      //== FRAME 5 page 113 in Caharacter Animation
      #declare Frame = 5;
      #declare IBP = clock - 2.0;  // In-Between Position counter
      #declare Action = 1.15; // "Stride.Left.Frame5
      // Now create linear combinations of joint locations from prev key-frame
      // and current key frame.  Contribution from prev key-frame linearly
      // disappears from 1 ->0, while current pose's contribution
      // increases    from 0 -> 1. I WANT SOMETHING BETTER!!
      #declare AVAR[Frame][l_hip_ind] = AVAR[Frame-1][l_hip_ind]*(1-IBP)  +
            <-25, 0, 0>*IBP; // Target: <-25*IBP, 0, 0>;
      #declare AVAR[Frame][l_knee_ind] = AVAR[Frame-1][l_knee_ind]*(1-IBP) +
      <25, 0, 0>*IBP;  // Target: <25*IBP, 0, 0>;
      // Some poses are the same between this frame and prev frame.  So, just
      // define it.
      #declare AVAR[Frame][l_ankle_ind] =  <0, 0, 0>;
      #declare AVAR[Frame][lower_back_ind] = <-10, 0, 0>;
      #declare AVAR[Frame][HumanoidRoot_ind] = <10, -60, 0>;

      #declare Human_Trans_1_1_05 =
      transform {
         //scale 5 // <5, 5, 5>
         translate l_step_size*clock*z
         //rotate <10*IBP, -60, 0>
         };

      Move_Humanoid( Frame, Action )
      #declare Humanoid_1_1_05 = Humanoid;  // make a copy with transformations
                                            // for Stride.Left.Frame5 move
      object{ Humanoid_1_1_05 transform Human_Trans_1_1_05 }
   #break

4. I changed rotation specification in Move_Humanoid( Frame, Action )
macro to something like:
      #if ( VZero( AVAR[Frame][l_hip_ind] ) )
      #else
         Rotate_Around_Trans( AVAR[Frame][l_hip_ind], JOC_l_hip )
         //Rotate_Around_Trans( l_hip_ind, vtransform( JOC_l_hip, Human_Trans )
)
      #end

Well, I have not finished making all the changes to see if he moves smoother.

AND, As oppesed to linearly switching between previous and current poses in each
of my animation stages, I would appreciate your input as to what worked the best
..  In initial frame of the current stage, just repeat the last pose of the
previous stage?  Then use some trig funtion to move into current pose?

My Key-Frame counter corresponds to Animation Stage each of which have a target
pose.

I hope to reduce the number of key-frames I am defining and come up with a
better interpolation methodology.  Since you have been at skeletal animation
far longer, I would value your input there.

I'll report on how this approach goes..

Is there some info on how I can get POV-RAY dump the values of all variables
declared whenever it reports an error during rendering, and I have on darn clue
as to what I might have done wrong.  That is how to debug ones' code with
POV-RAY.

WOW, you have started playing with muscles.  Once skeletal animation is done, I
need to map it to muscular animation.  See in human beings joint rotations
happen to be the end result of muscle contractions.  That step would be what
will be needed for movement studies in vertabrates.

I love to write/chat with you how you were able to get muscles manipulated.

Thanks,

Meltem


> >> // Initialise all variable
> >> #declare l_hip_ctl = 0;
> >
> > Did you mean
> >  #declare l_hip_ctl = <0,0,0>;
> > or is POV-RAY more variable type neutral?
>
> It's not quite neutral, but it does promote floats to vectors if it needs
> to.
>

So good to learn short cuts.

> > I hear you.  It makes perfect sense.  Now let me make an uneducated guess,
> > what
> > if we played with clock so it does not advance linearly.  Say, I like to
> > raise
> > my right arm:
> >   #declare myClock = a*clock*clock + b*clock + c;
> >   r_shoulder_ctl = <180*myClock, 0, 0>
>
> That is the sort of thing, though I've found trigonometrical functions like
> the sine function are often more handy than quadratics for smoothing out the
> start and end of movements.
>
> > My gosh you got facial expressions, hair, clothing items all added to your
> > PovPerson?  I guess with face skeletal animation does not work?  Jaw is
> > the
> > only movable joint, while there are numerous muscles moving facial organs,
> > generating expressions?!
>
> Indeed! Skeletal animation is just the first step. Muscle deformation comes
> next. I started work on deforming the upper and lower eyelid meshes as they
> opened and closed and had started splitting out the mesh around the mouth to
> implement something like the lipsync macro that Rune
> (http://runevision.com/3d/anims/) developed. I also have a deformable mesh
> for each finger segment, but never got round to integrating my muscular
> finger code back into the main deck of POV-Person SDL.
>
> > I hope there is doc with POVPerson, could it be used in research?
> > Could it be used in story telling?
>
> There is documentation on the web site. I also have further documentation
> for bits I developed since V2. I think there are many things it could be
> used for. The SDL and the documentation is licensed to encourage reuse.

Could you define what you mean by licensing here?

I will start playing with POVPerson, see what I can do with it, not before I get
my person moving.  The learning curve has been steep, exponential even, but hey
I like to think/hope I learned better by doing it myself than trying to get
someone else's code working for my purposes.

Thank you Chris,


Meltem
Laguna Beach, CA USA

>
> Regards,
> Chris B.

Post a reply to this message

"melo" <mel### [at] coxnet> wrote in message 
news:web.47aa51553df0d7073c0d56f20@news.povray.org...
> 1. Declared the array as a 2d array
>  #declare AVAR = array[23][23];
>                         //  first dim is for Key-Frame id, goes by odd 
> numbers
>                         //  1..23, second is for Animation control 
> variables

The array index starts at '0' so 'array[23]' gives you elements 0..22.

> 2. Initialized its element to be all 0 rotation vectors
> #declare Frame = 1;
> #while ( Frame < 23 )
>   #declare AVarIndex = 1;
>   #while ( AVarIndex < 23 )

You're only using 22 elements (1..22). You're skipping element '0', but then 
you seem to be staying within the bounds of the array, so it shouldn't give 
an error, so long as you don't try using AVAR[23], which would tell you that 
the index is out of range.

I think the name 'Frame' is potentially misleading as it may get confused 
with the constant 'frame_number' and you're using it for quite a different 
purpose. I'd recommend changing it to 'KeyFrame'.

> 3. Changed my code in my Range stmts to something like, to simulate 
> simplest
> linear interpolation
>
>   #range( 2.0, 3.0 )
>      //== FRAME 5 page 113 in Caharacter Animation
>      #declare Frame = 5;
>      #declare IBP = clock - 2.0;  // In-Between Position counter
>      #declare Action = 1.15; // "Stride.Left.Frame5
>      // Now create linear combinations of joint locations from prev 
> key-frame
>      // and current key frame.  Contribution from prev key-frame linearly
>      // disappears from 1 ->0, while current pose's contribution
>      // increases    from 0 -> 1. I WANT SOMETHING BETTER!!
>      #declare AVAR[Frame][l_hip_ind] = AVAR[Frame-1][l_hip_ind]*(1-IBP)  +
>            <-25, 0, 0>*IBP; // Target: <-25*IBP, 0, 0>;
>      #declare AVAR[Frame][l_knee_ind] = AVAR[Frame-1][l_knee_ind]*(1-IBP) 
> +
>      <25, 0, 0>*IBP;  // Target: <25*IBP, 0, 0>;

I think there are a number of things wrong with this. If you're using clock 
in a range like this, then I don't see that AVAR[Frame-1] would ever get set 
to anything but 0 when you're processing Frame=5.

This is where I suggested using '#if (clock>=2)' (and '#if (clock>=1)' for 
the previous chunk of code) instead of the #range statements. You would then 
have to cap IBP, so  'IBP=min(1,clock-2)',  would take IBP from 0 to 1 as 
clock goes from 2 to 3 and then sticks at 1 in this section of code for all 
values of clock > 3. This section of code would be used whenever clock is 
greater than 2, so, in the following sections of code where clock>3 and 
where you process Frame 6, the Frame 5 data will be available to you because 
all of the SDL for frames 0 thru 6 would be run.

I would think that your calculation should be
#declare AVAR[Frame][l_hip_ind] = AVAR[Frame-1][l_hip_ind]  +  <-25, 0, 
0>*IBP;
You shouldn't need to alter the value from the previous stage once clock>2. 
You just need to add the increment for the current stage.

The whole first dimension of the array becomes a little unnecessary as you 
could just accumulate AVAR[l_hip_ind]'. Remember you're only ever processing 
a single frame at a time because all of the variables get wiped out for each 
new frame of the animation, so for each frame you need to start accumulating 
values again from 0.

It's best practice to start all of your variable names with an uppercase 
letter, because built-in functions and settings use lowercase letters. Using 
uppercase letters for your own identifiers (e.g. variable and macro names) 
should reduce conflicts with future versions of POV-Ray.

> 4. I changed rotation specification in Move_Humanoid( Frame, Action )
> AND, As oppesed to linearly switching between previous and current poses 
> in each
> of my animation stages, I would appreciate your input as to what worked 
> the best
> ..  In initial frame of the current stage, just repeat the last pose of 
> the
> previous stage?  Then use some trig funtion to move into current pose?
>

The simplest way is probably to stick with what you've got. This can take 
you quite a long way. You could always add a pose at the end of one stage or 
the start of the next if the transition does not look smooth enough.

> I hope to reduce the number of key-frames I am defining and come up with a
> better interpolation methodology.  Since you have been at skeletal 
> animation
> far longer, I would value your input there.

The 'walking' animation on the POV-Person home page uses a very small number 
of keyframes, I think it was 4 hand-posed keyframes mirrored from the left 
of the body to the right of the body for the second half of the cylcic 
sequence. The other frames were just interpolated using linear 
interpolation. If you get the keyframes in the right place you can use them 
to smooth acceleration and deceleration.

If you get to using captured motion data you'll get lots of keyframes and 
you won't need to worry so much about interpolation. When you get onto sharp 
turns with an arm swinging out in an arc, or the movement of hair as someone 
walks, then you may need to get more sophisticated, but I think it's likely 
to be a while before you'll need that and I suspect that the structure of 
your SDL will look a fair bit different by the time you get there.

> Is there some info on how I can get POV-RAY dump the values of all 
> variables
> declared whenever it reports an error during rendering, and I have on darn 
> clue
> as to what I might have done wrong.  That is how to debug ones' code with
> POV-RAY.

You need to write out information into the message stream using the #debug 
or #error directives. I usually use #debug. The most useful statements are:

#debug concat("My label: ",str(MyVar,3,3),"\n")
#debug concat("Or for Vectors: ",vstr(3,MyVar,",",3,3),"\n")

I'd recommend being selective, but if you really need to write out lots of 
values you could code a macro to do that. I don't know of any way of 
trapping the error and writing out the variables when the error occurred. 
You generally need to track it through manually and add a bebug statement 
just before the failure occurred.

> See in human beings joint rotations
> happen to be the end result of muscle contractions.

I knew that ;-)

> I love to write/chat with you how you were able to get muscles 
> manipulated.

I didn't do it in a very scientific way, I assigned the points from a mesh 
to a 2D array and applied transformations at either end of the array. I then 
used a macro to stitch the arrays for successive body parts together and 
called another macro to transform the points back into a mesh (generating 
the normals). I was quite pleased with the results though.

Regards,
Chris B.

>> There is documentation on the web site. I also have further documentation
>> for bits I developed since V2. I think there are many things it could be
>> used for. The SDL and the documentation is licensed to encourage reuse.
>
> Could you define what you mean by licensing here?

Yes. Another big and very complex area which takes us well off-topic. You 
mentioned Public Domain and there are some problems with the definition of 
Public Domain.

Some countries don't recognise the concept and there have been some attempts 
in the past to effectively 'acquire' copyright over such materials. All 
countries (so far as I know) acknowledge the existence of licenses and they 
can last in perpetuity (however long that is).

The open source community therefore tends to issue licenses to try and 
prevent unscrupulous individuals and organisations from using legal jiggery 
pockery to circumvent the intent behind making stuff freely available. See 
GPL, LGPL and the set of licenses from Creative Commons.

Post a reply to this message