Thank you Charles.  had I not taken the time to struggle with this skeletal
animation concept as much as I had I probably would not have appreciated
hearing your story and understood the fine points such as the necessity of
incorporating some level of IK.  Darn, I feel I understand how we humans walk
much better than I would have ever cared otherwise, how else could one describe
the KeyFrames in 3D geometric terms?

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

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.

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

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.

cheers,
Mel

>
> Here's a bit on what I've done:
> My skeletal system is pretty simple, at least in concept.  My
> implementation has a tendency to grow with 'features.'  It's basically
> just a bone tree rooted between the first tail vertebrae and the first
> back vertebrae.  Each bone is a pair of vectors, one which has the
> length and direction of the bone, and a second, nominally unit-length
> vector to keep track of orientation.  All bones support twist, and
> for/aft side/side rotations to their parent bones with per-bone and
> per-rotation-type&direction limits specified in an include-file.  I'm
> using separate macros for the spine and the limbs to optimize control
> for groupings of vertebrae with a single control value for the spine, or
> specify individual digits/segments out of multidimensional arrays for
> the limbs.  (E.g: LimbVectors_POSED[LF][Forefinger][3][Pos] tells you
> the posed position of the tip of the forefinger for the left/front
> limb.)  (I also keep track of an unposed  model for texture sampling and
> spline-length measurements etc.)
>
> And what I plan to do..... later:
> So far I've purposely avoided writing any keyframing macros.  I figure
> that'll be the fun part after I get this 'dang'ed' model built. :-)  I
> plan on using a spline based interpolation of values *after* accounting
> for the fact that my positive and negative rotation limits for each bone
> may differ (else, I'll get less-than-smooth movements).  I do not plan
> on making any automatic movements sequences (walking) other than a
> couple of minor elements of IK.  They are: two bone (e.g.
> shoulder-to-wrist or hip to ankle) resolving with locked twist values,
> and where the limb just points towards the target point if it's out of
> reach.  The other item is to make it possible for a given digit/segment
> to rotate until it hits a target, such as a floor.  That should make it
> so that if the leg can't reach a given spot on the floor, the
> character's foot should roll up onto its toes.
>
> Anyway that's my story.  The real fun I've been having is in making
> systems to model with splines!  I'll tell you, there's no way to use
> splines this much without a token_counter-fixed version of POV-Ray,
> which the current release is not.
> Charles

Post a reply to this message