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