"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