Skip to content

Posts tagged ‘BVH’

A really, really indispensable PDF on BVH and motion capture formats.

September 16, 2009


I found this PDF on motion capture formats – funnily enough its called “Motion Capture File Formats Explained” and it is really essential if you’re trying to figure out why everything appears to work but doesn’t.

Motion Capture Formats Explained

Read on from page 16 if you like me, having built a correct matrix from the global data and offset find out that inaccuracies get past done the chain because of discrepancies in this very global matrix (due to the communicative problems of matrices). I will add this to my research page, and possibly keep a copy on my server for backup.

BVH You evil, evil little man!

September 4, 2009


BVH (Biovision) motion data is evil and I for one hate it! I wish when they had come up with the hierarchy, rotation order and transform methods they have firstly in world space, treated rotations as vectors and treated parenting as loosely as possible.

All you want for an animation format is a position of the joint, its direction and its spin – all in vectors with the position being in world space. This way any additional info like parenting can be bolted on without affecting firstly the initial pose or the animation. (as there keyed and set in world space)

The power of this is that, you could just have a set of positions and animation data without any vector info for direction or spin eg.

pos dir spn
[10,10,10] [0,0,0] [0,0,0]

And use it for raw mocap data such as TRC, or Vicom. But also by giving each joint an additional vector value for direction and spin you can use it as an intermediate format to a character rig. Parenting can still exist.

The power of this is that additionally, joints arent tied to the parents local space, and therefore you could store stretching infomation.

A ‘raw’ animation format

August 3, 2008


I was thinking over the weekend about a simplified animation format – something that takes out the two main issues I’ve been dealing with (and it appears a lot of other people have) in general: hierarchy and axis of joints.

I’ve worked on two motion capture shoots so far, and am currently helping pipeline issues on another project. The biggest problems i see with solving the data are first the hierarchy of the joints – if the aren’t exactly in the right order your BVH ends up truncated on the finally rig, or if the joint axis order is wrong (BVH is ZXY generally) rotations break.

Compounding this is that you can have different channels, different axis orders and custom hierarchies in BVH make it a nightmare solving to custom rigs. A skeleton also cant be broken – something that can be a pain to deal with in BVH.

I was thinking of an intermediate  file format possibly in XML, that would be only contain the position of a joint, its direction and twist – all store as world vectors. The format could also hold ties to a virtual hierarchy in the form of ids similar to Valves proprietary format. Something roughly like this:

<joint id=”0″>





I wrote an importer for BVH, that used a simple sorting order to work out the hierarchy ‘0’ would always be the root, followed by 1,2,3,4 etc.. if the numbering was sequential i.e 2,3,4 or 3,4,5,6 then id know they were children of the preceding numbered joint eg.


0 to 4 would be one chain but the next number 2, would become a child of the 2nd joint in the first chain and then be sequential until it broke sequence. Nifty! The format idea would only use this virtual ID if it needed to make a hierachy for BVH etc..

Outputting to this format though would still need end joints/nub bones to determine length as this is worked out using the <direction></direction> vector. Really its just a simple quaternion animation exporter using vectors for key properties.