<p>I'm not familiar with different motion capture file formats and exactly what they contain, but I have done some work on animating skeletons of life forms so here's my take on it.</p>

<p>When you draw something using a skeleton to animate it, you start with a "root" bone which will obviously have a position as can be seen in this <a href="http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/walk.asf" rel="nofollow noreferrer">example walk.asf file</a>:</p>

<pre><code>:root
   axis XYZ
   order TX TY TZ RZ RY RX
   position 0.0 0.0 0.0
   orientation 0.0 0.0 0.0
</code></pre>

<p>The next <code>bonedata</code> section defines all the bones:</p>

<pre><code>:bonedata
begin
   id 1
   name hips
   direction 0.000000 1.000000 0.000000
   length 0.000000
   axis 0.00000 0.00000 0.00000 XYZ
   dof rx ry rz
   limits (-180.0 180.0)
      (-180.0 180.0)
      (-180.0 180.0)
end
# other bone definitions follow
</code></pre>

<p>There is then a hierarchy of bones starting from this root bone:</p>

<pre><code>begin
   root hips
   hips hips1 hips2 hips3
   hips1 chest
   chest chest1 chest2 chest3
   chest1 neck
   # ...
   hips2 leftupleg
   # ...
   hips3 rightupleg
end
</code></pre>

<p>(by the way, this is the kind of information I asked for in my comments and that you should have provided for a clearer question.)</p>

<p>Each "child" bone is connected to the endpoint of its parent and it defines its own orientation relative to that parent. This picture helps (taken from <a href="http://help.autodesk.com/view/MOBPRO/2017/ENU/?guid=GUID-C42E4E6A-5149-4128-873C-08B2353A44B9" rel="nofollow noreferrer">Autodesk Motionbuilder's doc</a>)
<a href="https://i.sstatic.net/ZqUhU.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ZqUhU.png" alt="enter image description here"></a></p>

<p>To position any given bone, you need to go up the bone hierarchy to the root bone and combine all their transformation matrices together. For example, to position bone <code>chest</code>, the following sequence is used: <code>root -&gt; hips -&gt; hips1 -&gt; chest</code>. Each of these bones has its own transformation (rotation, stretch) based on the motion capture data which affects the position of its children. The <code>root</code> bone is a special case that has no parents and represents the position and orientation of the whole model.</p>

<p>Motion capture data cannot contain only bone positions because rotation in the axis of the bone cannot be expressed otherwise. Finally, it makes more sense to have motion capture data in terms of rotation and stretch because these values can be interpolated more easily than position and it's what is used anyway to render the skeleton.</p>

CC BY-SA 4.0
2018-12-21T09:18:32.913Z
2018-12-21T09:18:32.913Z
bernie
<p>This might sound stupid for you but I really don't know how it works in the domain of 3d animation and motion capture, but I need to work with ASF/AMC files at the moment and I find it a little bit complex to understand (being a non-native english speaker does not help).</p>

<p>So the question is, why motion captures main file types don't use simple joint coordinates for the skeleton? </p>

<p>Edit: I am particularly thinking about Acclaim ASF/AMC format mainly because I need to use it with an imlementation of an algorithm that use joint vertex positions and deltas from initial position for the motion part. Having looked at how the data are represented it makes more sense to me to represent skeletons as joint vertex and motion as deltas between the intial skeleton and the new moved one. </p>

CC BY-SA 4.0
2018-12-18T16:07:39.513Z
Your question looks interesting, but it's missing a key element. What does your MOCAP data actually use then instead of "simple joint coordinates"?
bernie
CC BY-SA 4.0
2018-12-18T16:18:10.770Z
I have edited the question to provide this information, I can give little explanations about the format if needed.
Nicolas Scotto Di Perto
CC BY-SA 4.0
2018-12-18T16:39:47.060Z
I'm not familiar with that format and I bet many others are not either. If you explain what it contains perhaps someone who knows mocap in general will be able to answer.
bernie
<motion><capture>
Why MOCAP data don't use simple point coordinates?
Nicolas Scotto Di Perto
# Why MOCAP data don't use simple point coordinates?

(Asked by: username_0 on 2018-12-17)

This might sound stupid for you but I really don't know how it works in the domain of 3d animation and motion capture, but I need to work with ASF/AMC files at the moment and I find it a little bit complex to understand (being a non-native english speaker does not help).

So the question is, why motion captures main file types don't use simple joint coordinates for the skeleton?

Edit: I am particularly thinking about Acclaim ASF/AMC format mainly because I need to use it with an imlementation of an algorithm that use joint vertex positions and deltas from initial position for the motion part. Having looked at how the data are represented it makes more sense to me to represent skeletons as joint vertex and motion as deltas between the intial skeleton and the new moved one.

**Tags:** motion, capture

> **Comments:**
> **username_1**: Your question looks interesting, but it's missing a key element. What does your MOCAP data actually use then instead of "simple joint coordinates"?  
> **username_0**: I have edited the question to provide this information, I can give little explanations about the format if needed.  
> **username_1**: I'm not familiar with that format and I bet many others are not either. If you explain what it contains perhaps someone who knows mocap in general will be able to answer.  

---

## 1 answers

### Answer by username_1 on 2018-12-21. Score: 2

I'm not familiar with different motion capture file formats and exactly what they contain, but I have done some work on animating skeletons of life forms so here's my take on it.

When you draw something using a skeleton to animate it, you start with a "root" bone which will obviously have a position as can be seen in this [example walk.asf file](http://research.cs.wisc.edu/graphics/Courses/cs-838-1999/Jeff/walk.asf):

```
:root
   axis XYZ
   order TX TY TZ RZ RY RX
   position 0.0 0.0 0.0
   orientation 0.0 0.0 0.0

```

The next `bonedata` section defines all the bones:

```
:bonedata
begin
   id 1
   name hips
   direction 0.000000 1.000000 0.000000
   length 0.000000
   axis 0.00000 0.00000 0.00000 XYZ
   dof rx ry rz
   limits (-180.0 180.0)
      (-180.0 180.0)
      (-180.0 180.0)
end
# other bone definitions follow

```

There is then a hierarchy of bones starting from this root bone:

```
begin
   root hips
   hips hips1 hips2 hips3
   hips1 chest
   chest chest1 chest2 chest3
   chest1 neck
   # ...
   hips2 leftupleg
   # ...
   hips3 rightupleg
end

```

(by the way, this is the kind of information I asked for in my comments and that you should have provided for a clearer question.)

Each "child" bone is connected to the endpoint of its parent and it defines its own orientation relative to that parent. This picture helps (taken from [Autodesk Motionbuilder's doc](http://help.autodesk.com/view/MOBPRO/2017/ENU/?guid=GUID-C42E4E6A-5149-4128-873C-08B2353A44B9))
[![enter image description here](https://i.sstatic.net/ZqUhU.png)](https://i.sstatic.net/ZqUhU.png)

To position any given bone, you need to go up the bone hierarchy to the root bone and combine all their transformation matrices together. For example, to position bone `chest`, the following sequence is used: `root -> hips -> hips1 -> chest`. Each of these bones has its own transformation (rotation, stretch) based on the motion capture data which affects the position of its children. The `root` bone is a special case that has no parents and represents the position and orientation of the whole model.

Motion capture data cannot contain only bone positions because rotation in the axis of the bone cannot be expressed otherwise. Finally, it makes more sense to have motion capture data in terms of rotation and stretch because these values can be interpolated more easily than position and it's what is used anyway to render the skeleton.


---

