Hi dear Blender addicts,

Here is the armature that I will use to translate .bvh files into biomechanic-friendly movements.
It goes with the skeleton made by ‘BodyParts3D’ and shared in the blender anatomy atlas ‘z-anatomy’.

It has two modes, one to copy the .bvh, and the other to pose manually the armature (See Armature>Properties>Object>Custom property>Motion Capture)

There is one problem left:
The cervical vertebras are rolling around when the animation is running.

If somebody could help me on this one, I would greatly appreciate.


You have an absolutely huge number of warnings in that file. On your main menu, use Window->Toggle System Console (and then scroll up for a while.)

Now, the driver warnings aren’t that bad, unless you were planning on actually using those drivers. But the “dependency cycle” warnings are very important, and you have to fix all of those. No way around it. You need a clear hierarchy of action: if something affects another bone, it cannot be affected by that other bone, directly or indirectly.

Beyond that, this is a weird way to put together an armature. There are a ton of constraints here. I think that you’re probably trying to sprint before you’ve learned how to walk.

I’ll just talk about one issue. When I look at your cervical vertebrae, I see limit rotation->(driven) copy rotation → full influence armature → damped track → limit scale. On an unparented bone. This doesn’t look like a controller bone to me, so you need to understand that your limit rotation is probably doing absolutely nothing. All of your rotation on the bone should be coming from constraints that are evaluated after the limit rotation. (Note that I consider limit rotation and copy rotation to be extremely dangerous constraints for people that don’t understand them very well-- which is most people-- because of their reliance on Euler angles. It is very easy for people to run into issues with these constraints.)

I strongly suspect that there are other issues going on here, just because of the complexity of the armature in conjunction with so many console warnings. I would recommend that, as you run into problems, you simplify the problem as much as possible. For one thing, it will help you focus on the precise problems you’re having, without getting overwhelmed by how many other things are going on. But there’s another reason, which is just that as you work through this, and run into further problems, you’re probably going to find very, very few people willing to work through a system this complex in order to help you solve your problem.

Well received.
You are right, I am a noob and want to do something non-conventional; but…
What about this:

It’s good, in that you’ve cleaned up a lot (not all) of your errors. And I think you’ll see that already it’s working better than before.

That doesn’t mean that it’s exactly what you want. With just some basic manipulation, I didn’t see the cervical twisting you had before. But that doesn’t mean that it doesn’t exist-- maybe I didn’t do enough examination. (And yes, on an armature as complicated as this, I’m going to look for problems rather than trying to understand and analyze the whole structure.)

If you have some problems that you’re having trouble understanding, consider posing/keyframing the armature in a way that demonstrates the problems. (And, again, consider simplifying the rig into the simplest example that demonstrates the problem you don’t understand.)

I would still recommend cleaning up all of your errors that show up in the console window. This is something you’re going to have to do sometime, and it might as well be now. Whenever a rig does something you didn’t expect is a good time to address all errors, because one of them may be responsible for your problem, and again, it’s something that has to be done sometime anyways.

I try to get as close as possible to the original BVH, but bringing the proportions and biomechanical system with it, and then the skeleton(meshes).

Several points are not quite as they should:
-The radius should be the bone affected on Y rotation by Left/RightForeArm, while the ulna should only rotate in X rotation.
-same situation with the hand that has two pivot points: one for the flexion and another for the abduction/adduction.
-The Spine/Spine1 junction were creating problematic ribs movements (not much but still) sothat I prefered to connect Spine to Neck1 (and Neck does not affect anything neither).

The cervical issue was caused by the damped track; on this setup, only ‘armature’ is enough.

I’d recommend dealing with one problem at a time. I can look at another file that demonstrates any single problem you’re having. Or, you can tell me a set of transforms for bones that demonstrates a single problem you’re having, and I can type that in. Descriptions of these problems help, but they’re often too ambiguous to understand without having the problem demonstrated.

1 Like

Here is a just the right forearm, to show this problem:

What I need in other words, is to separate and send on two(*) different bones the Y/Z rotations of the bone ‘RightForeArm’.
Physiologically, one bone of the forearm only does the flexion (the ulna/cubitus called ‘rightforearm’ in this case), the radius does only the pronation/supination (Y-axis),

(*) or even three: in principle, if there is any lateral movement (X-axis) then it should go to the Y-axis of the humerus.

First, the file: which frame should I be looking at? What should radius be doing on that frame? I think I know the root of your problems anyways though.

TL;DR: Euler angle axes don’t work the way you think they do. They’re not independent of each other. There’s not really any such thing as affecting an XYZ Euler angle X axis without also affecting what you perceive as the Z axis. Use other constraints (damped track and locked track) to control the orientation of bones instead.

In this particular case, it’s exactly what I was saying about not using limit rotation and copy rotation.

Limit rotation acts on XYZ Eulers. It decomposes the transformation of the bone, which is a 4x4 matrix, into a XYZ Euler rotation, clamps the explicit numbers in that rotation, and then recomposes a new 4x4 matrix out of its new triplet. It’s a bunch of math. Not necessarily simple, and it doesn’t match your intuition, but it’s just math, and you can trace it out if you want.

The problem is that the way that Eulers work, your Z rotation is not independent of your X/Y rotation. Changing your X/Y rotation changes what you’re thinking of as your Z rotation. Euler rotations are ordered rotations, and the axes aren’t actually independent of each other. This also screws up your copy rotation constraint, which is copying only the Y axis rotation of its target, but the Y axis rotation of its target depends on the X axis rotation of the target (because it is an XYZ Euler: X, then Y, then Z.)

Typically, when I want to do something like this, I’m going to do it with damped track and locked track constraints. Think about the orientation of your bone as 2 things, rather than 3. First, the point that the tail of the bone should be pointing at. (Damped track Y that point.) Second, the point that its X (or Z) axis should be pointing at. (Locked track, lock Y track X, that point.) The third axis is fully defined from those two things.

In your structure, if you just damped track some point with Radius, it won’t really do anything, because it’s parented to the control-- it’s already inheriting the full rotation of Forearm, so it’s already pointing where you want. You may want to parent it, instead, to Humerus (or whatever.) If you don’t want a bone to copy all rotation, don’t try to use a limit rotation-- instead, parent it to something else so that it never gets that rotation in the first place.

In many situations, only one of these constraints is necessary to get the behavior you want. A damped track Y is the shortest path rotation to the direction to which you want the Y axis to point.

Copy rotation has some options to control “order”. It’s usually possible to get what you want with that, but it requires really understanding how Euler angles work-- how they’re not actually 3 independent axes. Limit rotation does not have any “order” field, however. It always limits bones as if they were XYZ Eulers.

Often, anatomical terms are not the best for thinking about these problems. When anatomy texts are talking about “pronation”, they’re talking about pronation of the hand. But the hand is dependent on the radius. We can’t talk about the radius in terms of the hand because of that dependency. There’s a lot of translation we have to do with anatomical terms. (There are other times that anatomical terms are very useful though, like for naming features.)

Note that this whole thing doesn’t make a lot of sense treating Forearm as the ulna, since ulna doesn’t inherit the full range of transforms we can give the forearm, and radius instead inherits some of them. Instead, we should have deforming bones ulna and radius, and controlling bone forearm which deforms nothing, with both ulna and radius dependent on the control.

1 Like

Well received, thank you for the explanation.

The euler system seems to make it impossible to isolate the local Y-rotation of RightForeArm, and paste it on the Radius.

Even if I add a bone as being the ulna;
-parent ‘ulna.r’, and ‘RightForeArm’ to the ‘RightArm’ (the humerus),
-make the ulna follow ‘RightForeArm’ with a damped track constraint.
-damped track contraint the radius to ‘RightForeArm’ (or another bone barented to it to get the offset)

I won’t be able to copy the Y-rotation of ‘RightForearm’ because its local meaning will change according to the pose position of ‘RightForeArm’.

Only if these rotations are base on the rest pose and sent to the rest pose coordinates, then I could approximate the result by copying the global Z-rotation from one to the other, since the radius is nearly vertical in rest position.

Edit: I’ll learn the options of the copy constraints and see if it can be done.

This seems to work, but the Y-rotation of the humerus gets locked by the driver that replaces the 'Y-Rotation of ‘RightArm’ by the Z-rotation of ‘RightForeArm’:

I tried editing the driver to add this Z-rotation of ‘RightForeArm’ to the original Y-rotation of ‘RightArm’, but it is still locked:

Edit: It works for the forearm and the wrist.
There could be another fix on the knee and one on the vertebral column, but we’re nearly there.

If the drivers are now important in the file, then the dependency cycle (loop) in that file matters. Check the console. Looks like it’s present in both files.

Note that drivers and constraints work in very different ways, that are not immediately obvious.

I will verify the system console for dependency cycles but it seems resolved thanks to your explanation. Now one control allows to pose the whole forearm and another the hand, respecting the physiological behavior.
It is not very visible because the .bvh I got do not seem very sensible to these extremities, but at least it is consistent both while playing an action and when manually moving the armature.

Second problem:
The knee has an evolutive axis of rotation, due to the shape of the femoral condyles.
It has been reproduced on the armature using two different bones.
The first one, ‘Knee.r’ creates the first part of the rotation, or rolling part (the tibia therefore moves forward in relation with the femur, but this is not what matters here), then the second gives the sliding part: ‘RightLeg’ must start rotating (a driver rotates ‘Tibia.r’ 30 degrees on its local Y-axis when the leg gets fully bent, but again, that is already done, in principle).

I need to rotate these two bones with one bone/control.
‘Knee.r’ must rotate on its local X-axis until its limit (-20°) before ‘RightLeg’ starts to rotate.

The damped track constraint does not do the trick here because the axis is the same and that one movement must start when the other is finished. I guess that a condition within a driver could do the trick, but unfortunately, I do not master the code to create such a condition and would need a hand on this.

A driver would probably work. You need some kind of control bone.

In this case, knee and right leg would be driven from the same value (doesn’t really matter what value, but presumably some bone’s X rotation), with scripted expression drivers.

I can never remember what the degrees-to-radians function is called. I’ll call it “radian” here. You can use pi*degrees/180 if you want. We’ll call the control’s X rotation “var”.

Knee’s rotation is max(var, radian(-20)). That means it uses the highest of the input and -20 degrees-- so if input is a rotation greater than -20 (which is less rotation, in this context) then it will use input, otherwise it will use -20 degrees, clamping it.

Right leg, assuming you also want it rotating negatively, can have a scripted expression of min(0, var-radian(-20)). In other words, you’re subtracting -20 degrees of rotation from (adding 20 degrees to) the input’s rotation, and then creating an upper bound at 0 radians rotation.

That’s off the top of my head, untested. I could’ve screwed something up, but it should demonstrate the kind of thinking that you need to solve the problem.

Thank you very much for your help!

I actually achieved it with your first trick and limit rotation constraints.
It works both in manual and with a .bvh, which was the objective.

Last main problem:
The spine

I added three trials for the spine in this file:

Bendy bone are great for the progressive effect that is needed to reproduce the movements of the spine. But, in order to adress students and professionals in healthcare, each vertebra must keep its offset with the next, some also have several pivot points (same principle as for the wrist, which was solved with your combination of ‘locked track’ and '‘copy rotations’) and all have rotation limits that need to be respected, (sometimes pretty different according to each level, as between C1 and C2).

My first armature(on the left/in front), that I share on the website, did not use bendy bones, and works quite well; but I do not want to abandon the idea to translate .bvh motion captures respecting the biomechanical behavior.

The objective is therefore to keep the same behavior as the first armature, but to control it with the green bones (LowerBack/Spine/SPine1/Neck1/Head), and to reach their position at the junctions.

This is a bit contradictory at first sight.
How could I keep influencing progressively and keeping the ‘fading effect’ across the .bvh jnuction (ex:Spine/Spine1) without getting any extra translation effect?

I guess that with a complex mix of partial ‘copy transforms’ and ‘copy rotations’, there must be a way to get to it, but I’d rather get the solution/advices/impressions of more advanced riggers to start with.

There’s a lot said that that I don’t understand.

The first thing I wonder, looking at your file, is if the first armature does what you want, why are the vertebrae in the second armature in a different place?

I’m not sure why the second armature has two spines. I’d suspect one is for the BVH animation and one copies transforms from the other? But I don’t see any way that one of these affects the other. If, on the “deepest” spine (greatest world +Y), you want the green bones to control the bendy bones, then the green bones cannot be parented to the bendy bones like you have.

The cervical vertebrae on the middle spine do not translate. If you draw a plane perpendicular to their bendy bone control, running through the origin of each vertebra, you’ll see that they stay exactly on that plane. The rotation limits on each vertebra create an impression of changing distance that isn’t quite accurate. (Note that this rotation limits are bad: each vertebra is unparented, so your local angle limits are not in respect to each lower vertebra, but to the armature as a whole!)

Sorry for the confusion; the two spine of the second objects were but failed trials.

Using again your first trick, It gets closer to the intended result:

It may work actually…

Edit: See the link below instead:

If only I could find a way to make the junction vertebras tend towards the end of the mocap bones (Spine/SPine1/etc.) without getting the dependency cycle, it would be it.

Something of this kind maybe…

If you’re asking me a question, I don’t know what it is.

You have to understand that we’re in two different positions. You have a problem, you think you can solve it sometime in the next month. You want to make an armature.

But from my perspective, your current goal is determining the position of every bone in the human body, from a .bvh that contains a tiny fraction of that information, without the use of a super-advanced computer that has been trained for more than a million years-- ie, the nervous system. Even discarding the fact that the human body is not some idealized machine, but a physical system, limited by things that resist squish and stretch to different extents, that’s not a realistic goal.

So my approach here is to help you understand why certain things work like they work in Blender, so you can learn, even though there are numerous problems not only with your goal, but with your implementations.

Rigging can be described pretty simply: where do you want the bone? Where do you want it to point? How do you want it rolled? How do you want it scaled? Those questions determine everything about an armature’s bone. The hard part is answering those questions. If you answer them rigorously, unambiguously, I can probably tell you how to get the bone there. But I can’t answer those questions for you.

No problem, I think that I start to find the way.
.bvh are indeed imperfect rough representations of the body movements, most have some glitches, dead parts and sometimes non-physiological bendings.

I decided to give the angle of each ‘limit rotation’ constraint of each vertebra by a driver that gives it a fraction of the one of the segment (it is not finished) -in this way it will be possible to adjust the flexibility of the armature with the segment’s limit rotation constraints-, and to simply copy a part of the rotation of the segment (Spine/Spine1/etc.) on each vertebra. The damped track will probably be useful afterwards to reproduce an automatic rotation movement of the vertebras on their vertical axis - which is opposite to the bending actually.

Sorry for all these posts; I spent too much time on this and hoped that somebody could understand the purpose and find a solution faster than me, but as it is a very specific purpose, I now understand that it can not be understood at first glance before it is finished, even for experienced riggers.

I abandoned the spine problem.
This video shows what I was trying to explain: