Nesting joints and defining animations

Scripting Issues
1

When joints are nested within an egg file like this:

<Joint> JOINT_A {
    <Transform> { ... }
    <VertexRef> { ... }
    <Group> { <Polygon> ... }
    <Joint> JOINT_B {
      <Transform> { ... }
      <VertexRef> { ... }
      <Group> { <Polygon> ... }
    }
    <Joint> JOINT_C {
      <Transform> { ... }
      <VertexRef> { ... }
      <Group> { <Polygon> ... }
    }
    ...
  }

Does the motion of the parent ensure the motion of the child? (I know that sounds pretty obvious…)
If for instance joint A moves during an animation, will joint B and C inherit its motion? I know another way to make the motion of one joint affect that of another is through vertex assignment; where if for instance joint A had vertices 1-10 and joint B had vertices 6-9, moving joint A would move joint B. So is joint-nesting another way to make any changes done on a parent joint reflect on a child joint?

The next question relates to how animations are stored in an egg file using <Xfm$Anim_S$>. What does this structure represent:

<S$Anim> x { 0 0 10 10 20 ... }

?

If those entries are values at particular frames, and each frame lasts the same length of time, does that mean that the time between values is based on their position in the list? Like in the above example, would it be like this:

value: 0   0  10  10  20
      |   |   |    |   |
time: a   b   c    d    e

a->1/fps

b->2/fps

c->3/fps

d->4/fps

e->fps

value->float
time->seconds

?

I know I asked a long version of this question [url]Defining animations in a "procedural" manner.] but I’m kinda stuck and can’t continue with development…it’s been 4 days… :cry:

2

Yes, the transform of a child joint is relative to the transform of a parent joint. So it is common to parent the joint of the hand to the joint of the arm, so that when rotating the arm, the hand will rotate with it. (Note that the vertices are always specified relative to the root of the .egg file).

Your assessment of how the frame data works looks right to me.

3

Thanks,I thought that only keyframe data was stored, and not all the frame data. I thought it was stored in pairs: value->keyframe, value->keyframe etc…[where “keyframe” would be the time position of the frame in seconds] so I was having some difficulty understanding where the time value would go; turns out that things work differently. Thanks. :smiley: