I’ve been trying to map some motion capture data to a model.
First some informations:
The motion capture data comes as local transformations of the joints in a Y-up coordinate space.
For more detail check the Biovision BVH specification: cs.wisc.edu/graphics/Courses … f/BVH.html
I wrote a parser to read BVH-data and store each frame’s x,y and z rotation to pass the values to the joints.
I defined and aligned the joints in the armature according to the joints in the mo-cap data to get best results.
I exported with chicken_export v1.0 to Panda’s egg file format. ( Blenders Z-axis is pointing upwards like in Panda, so i hopefully didn’t miss to do anything here?)
First I loaded the model into Panda and reparented it to a node which I rotated for 90 degrees around the x-axis in order
to clean up coordinate system confusion between the mocap-data and Panda’s coordinate space.
Then I controlled the joints using controlJoint. I stored the initial hpr in some list before i start animating.
I wrote a task which reads one frame of the mocap-data, adds the initial hpr from the list and applies the sum to the according joint using setHpr.
The result looks not as it is supposed to look like. Some joints rotate into the wrong direction. To me it seems I must have missed some important step(s).
I’m pretty new to using python Panda and Blender. I tried a lot of things , but I couldn’t find any solution to clean that mess up
Any help / suggestions?
This is a little bit suspicious; in general, you can’t just “add” hpr values together componentwise. For instance, a HPR of (10, 5, 2) and a HPR of (5, 15, 10), composed together, produces a net HPR of (14.5885, 20.1494, 11.6504), not (15, 20, 12).
But why do you need to compose hpr’s at all? Doesn’t your incoming data already include the correct initial offsest?
when I load the model looks like this; sorry for it’s beeing still nude ( already reparented to a node and rotated by 90 degree around the x-axis):
Listing the joints after loading the model, shows this output:
hip hpr -180 10.8893 -180 trans 0 -0.321256 0
lhipjoint hpr -101.247 45.3933 105.606 trans 0.006149 -0.310135 -0.088431
lfemur hpr 44.9437 0 -180 trans 0 1.31471 0
ltibia hpr 1.41244 -4.59426 -180 trans 0 3.83547 0
lfoot hpr 0 -76.6251 180 trans 0 3.54094 0
ltoes hpr 0 17.9692 0 trans 0 1.06592 0
lowerback hpr -180 -88.4339 180 trans 0 0.148242 0
upperback hpr 0 12.4554 -180 trans 0 2.02483 0
thorax hpr 0 -0.000171887 0 trans 0 1.36107 0
lclavicle hpr 78.8341 5.72958e-005 180 trans 0 0.016677 0
lhumerus hpr -16.3603 0 -180 trans 0 1.6436 0
lradius hpr -6.72874 0 179.999 trans 0 2.1892 0
lwrist hpr 68.6832 0.00040107 0.000114592 trans 0 2.01877 0
lhand hpr -45.7351 0 -180 trans 0 0.006281 0
lfingers hpr 24.4825 0 90 trans 0 0.724878 0
lthumb hpr -69.7443 32.0657 -90.8916 trans 0 0.006281 0
lowerneck hpr 0 0.000229183 -180 trans 0 0.016677 0
upperneck trans 0 0.969406 0
head trans 0 0.581615 0
rclavicle hpr -78.1721 0.000114592 -179.999 trans 0 0.016677 0
rhumerus hpr 17.4105 -0.000114592 179.999 trans 0 1.58438 0
rradius hpr 5.58262 0 -89.9993 trans 0 2.14653 0
rwrist hpr -179.969 -52.5966 -89.9613 trans 0 1.83116 0
rhand hpr 147.997 0.00825059 -179.978 trans 0 0.00256 0
rfingers hpr 20.5941 -0.000171887 90 trans 0 1.03823 0
rthumb hpr 131.745 -24.943 -79.7934 trans 0 0.00256 0
rhipjoint hpr 100.591 43.6939 74.8546 trans 0.006149 -0.310135 -0.088431
rfemur hpr 46.7495 -2.34245 -179.94 trans 0 1.28233 0
rtibia hpr 1.45449 0.0186211 0 trans 0 3.89529 0
rfoot hpr 0 -74.7971 -180 trans 0 3.52435 0
rtoes hpr 0 17.5645 0 trans 0 1.08261 0
what means the joints are already rotated when they got initialized.
So when I now read the data and it says for instance that the ‘rfemur’ should get rotated by 90 degree around the x-axis to point to the front, I have to add these 90 degree to the initial pitch that the models ‘rfemur’ already holds when initialized, don’t I? Eventhough I already experienced the inaccuracies with floats you mentioned.
This picture shows the alignment of joints of the data, when all joints have zero rotation for all axis.
This is why I thought I have to simply add the initial hpr that the model’s joint hold , when I use controlJoint, before I start animating.
It’s not floating-point inaccuracy. It’s a fundamental misunderstanding of how HPR angles are composed. In general, it’s just not true that (h1, p1, r1) + (h2, p2, r2) == (h1 + h2, p1 + p2, r1 + r2). In my example, the composition is only off by a tiny bit, which might look like simple inaccuracy, but as the angles get larger the result gets off by farther. Especially when you’re talking about a 90-degree angle.
It is possible to compose two HPR angles to produce a new HPR angle accurately. One way to do this would be to use a NodePath, for instance:
n = NodePath('n')
n.setHpr(h1, p1, r1)
n.setHpr(n, h2, p2, r2)
result = n.getHpr()
But I don’t recommend using this approach. Not only is it needlessly expensive, it’s not necessary. A better approach would be to avoid the coordinate-system transform in the first place. You should be able to create a model that has the same initial rest angles that your motion-capture data will be supplying for a model in the same pose.
Make sure that the entry at the top of your egg file is consistent with your expectation, too. Panda will auto-convert from whatever your egg file claims its coordinate system is, to its native right-handed Z-up coordinate, by rotating each joint if necessary.
( already reparented to a node and rotated by 90 degree around the x-axis):
