Melo, sorry about my slow response....

It's nice to know there are a handful of people on here who're 
interested in animating characters in code.

melo wrote:
> Describing movement of each bone segment in relation to its immediate parent
> bone.  Could you explain the reason behind that design decision?  Oh Darn,
> rereading your notes, and thinking about joint constraints, I can see that,
> joint constraints are specified in local terms.  If so, why not use the same
> local reference frame for movement specifications as well? So they could be
> easily checked against anatomical limitations to keep the being safe and alive,
> as s/he moves...
> 

I think I am...  For instance, I eyeballed that my own hand can bend 
forward roughly 90 degrees and backward say 80 or so degrees, relative 
to my forearm.  Also, some 45 degrees away from the thumb, only a few 
degrees towards the thumb and no twist (the forearm does the twisting). 
  Control values are given in the range -1 to 1, regardless of whether 
the + & - limits are the same in degrees. That's my attempt at getting 
more or less anatomcally correct limits (which can be overrided by just 
overshooting the normal range).


> And comparing how my skeletal metalic being moves, to that of Chris's PovPerson.
> I could attest to that me taking the easy way out did not work.  My metalic
> robotic humanoid walks in place like a robot, while Chris's POVPerson glides
> across the screen. I just used a simple linear interpolation, while Chris used
> spline interpolation.   Darn I need to reteach myself how to use those, I am
> afraid, I could not recall.
> 

As I said before, I'm not even to that point yet.  Spline interpolation 
can exactly replicate linear interpolation via linear splines.  When I 
implement, I think I'll be most interested in using bezier splines since 
they give so much control next to each knot.  That could help me avoid 
implementing too many 'types' of keyframes.  One feature I think will be 
useful/important is the ability to create partial keyframes/poses where 
anything not defined in that particular pose is interpolated from next 
and previous frames.  That'll make hand coded controls much easier to 
handle.

> Again, I appreciated your taking the time to share the approach you had taken.
> 

:D

> Now, your ending remarks invoked my curiosity.  Darn, you highlighted yet one
> area I have not heard of yet.  What do you mean by making systems model with
> splines?  What are we modeling here? What systems are you making model what
> with what type of splines to what end?  Sorry.  Case in point.   I'll stop
> questions, before you run out of your patience.
> 


By systems, I just meant all the design choices and macros written to 
try to make it easier to hand code.  E.g. splines are a lot easier (or 
rather possible at all) to manipulate/transform as vector arrays 
<x,y,z,t>.*  Cross sections are a lot easier to create using polar 
coordinates.  Re-sampling is ever so handy.  Turning the spine into a 
pair of splines, not turning the limb bones into splines but rather 
leaving them alone and creating specialized types of cross-sections, the 
ability/option to multiply values along two splines and a parameter or 
measurement to get a modified cross section (read muscles).... 
Treating each limb digit or body as if it had spherical coordinates. Etc.


*I've said this before in another post, but I wish POV-Ray could treat 
such an array as identical to a spline depending on what syntax you use, 
and also perform transformations on the array elements without using a 
macro.

Charles

Post a reply to this message