How to setup a quaternion based driver for multiple quaternion rotations?

Support Animation and Rigging
1

Hello guys, i have been struggling to attempt using quaternion rotation in a simple shape key setup, in this case we are going to take as example a hand/wrist bone; so, this is my workflow:

  • Setup keyed poses of the hand in the timeline/dope sheet all in one action or separate actions per pose to begin the corrections of those deformations.

  • Start adding 4 empty shape keys (and later 4 more for separating them in .R .L sides) and then make one corrective shape key for each symmetrical pose to correct its deformation in sculpt/edit mode. Also the Hand bone is being rotated in its local coordinates and set as Euler rotation mode temporally for easier reading of the transformation applied but later converting that into quaternions (or not necessary at all if you know what values you did setup and or instead wrote down in case you forget) or also instead of that what i did was to simply store that information in the names of each pose action with the specified values setup, e.g. wrist-up-60deg.R or just the number without deg knowing is obviously already posed in degrees anyways or also without .R/L suffix taking into account the pose actions are already keyed symmetrically, and the suffix only matters for the shape keys that would be separated by .R/L out of a single symmetrical shape key created per each corrective pose.

  • Test animated poses and see how it interacts with every shape key and corresponding pose to find any issues or do more tweaks to the deformation.

  • Start adding the first driver: using a single variable set as average value and the single variable is either one x/y/z rotation input (here is missing the W input since i don’t know how to use it for a quaternions setup) of the Hand bone and then is tweaked the values of the linear curves (or non-linear if you want that kind of output) in the drivers graph editor. And repeat for X/Z rotations in their positive and negative directions (up/down and left/right, and the Y axis usually used for Twist deformation is not being used here)

  • Pose hand bone in its local rotation in its rest pose, drivers execute and works as expected in their specified values from its graph editor…except one problem occurs; when the Hand bone is rotated 90 degrees in the Y axis, the drivers fail because of the change of local orientation, and the values flip in their opposite directions: the up/down direction triggers instead left/right drivers and left/right direction triggers instead up/down drivers…

So how do how i make the drivers have a second variable or other workaround that still triggers the poses properly as if it was in rest pose but in 90 degrees orientation in the Y rotation that is ignored of course, because it flips the driver values and changes how the drivers work…

Thanks in advance for any help given, fellow blenderheads :grin:

2

Hello;

This is a bit complicated issue to only put in words, isn’t it? Maybe some screenshots/clips can help.

But, there’s a good chance it’s a Space issue? So, perhaps, if you’re using Local Space inside the Driver for the Target Bone (Target’s Space), for a certain Driver it might not be being sufficient in that particular Setup. Have you tried Transform Space? If I’m not wrong, it can bypass the limitation of ‘indirectly Transforming a Bone’ in a more compound Setup. I don’t think it is the same as Target Space set to Local With Parent (for Bone Constraints), which is dangerous btw (works as if the Owner Bone of the Bone Constraint had Child of Bone Constraint or Armature Bone Constraint: i.e., cannot be Parented to the Skeleton’s main hierarchy, or can provoke Double/Stacking Transforms). The Transform Space might be safer, but for some reason this only exist for Drivers.

1 Like
3

This is how the Hand/Wrist looks like, and then after the bone is rotated by 90 on Y axis, the drivers don’t work properly…

and no, the transform space doesn’t work since the FK Controller is a parent through constraints and/or parent of the DEF bone of the Wrist (the transform space ignores parents or constraint transformations)

1 Like
4

Thanks for the updates!

All right, now I can see the case of the Y Axis Rotation, and how it seems to be messing up the Drivers’ outputs into the Shape Keys’ values.

I was originally thinking it could be a Local Space issue --if only there were the Local Space (With Owner Orientation) in the Drivers, that could be a quick test also in that sense; but since it’s not the case…

Now, I believe more likely that the core issue, is related to Stacking Transforms: exactly, for that Y-Axis Orientation of the Bone(s) along the Wrist Region.
Basically, my hypothesis is that, as you Pose-Rotate the CTL-Wrist Bone, Twisting it around its Y-Axis, you get instant Stacking Transforms to Child/Bone-Constraint/Driven Bones (at least one dependent Bone) on the Wrist/Hand. Because of this, the Y-Axis Rotation is compromised, and hence plenty of Axes, Space reference, for the Driven Bones’ Target(s), get messed up.
In this hypothesis, you cannot allow this or those dependent Bones to Stack-Transforms regarding the CTL-Wrist Bone Rotation on Y-Axis. :face_with_monocle:

It’s a very interesting case. But I can’t dig much more.

If you haven’t done so, I believe it’s also good to double-check all the Drivers to check it they’ve got the correct Target (including the Rotation Axis) and Spaces… and Scripted Expression, etc. There’s a chance everything you did conceptually is accurate, but there would be tiny mistake somewhere compromising this part of the Setup.

If you still can’t solve it, feel free to bring more samples later on. :hear_no_evil:
Good luck!

EDIT: Btw, just in case, should check for the Toggle System Console < Window < for Dependency Cycles.

1 Like
5

I can’t really imagine what would work in this case, specially because I’m a zero with armatures…
But, adding a second variable to a driver is really simple… In the Driver panel, just ‘Add Input Variable’. (you can add as many as you like)

And in the expression, if it’s a simple thing, you can do it right there; like for example:
var0.rotate(var1).angle, for var0 and var1 being two different quaternions.

For something more complex, you can create a Driver Function, and use that instead.

1 Like
6

@Secrop

here is a small sample of the rig if you want to dig in :smiley:
Dummy-Rig-2.blend (1.3 MB)

1 Like
7

What is exactly the objective?
I can see the rig, and rotate its bones… but I’m not understanding what exactly is the problem… :roll_eyes:

8

the problem appears after the FK-wrist bone is rotated 90 degrees in Y axis then rotated again to the up/down sides after that rotation, i don’t know how is not clear that part in both the description and video lol …

9

I get what you are trying to do, that part is clear to me.

I had an idea but I can’t get it to work. The rotations are acting strange to me. I don’t want to post anything up about it until I’ve had a chance to look at it again. I have been looking at this problem a couple of times.

Anyway, I look at this again after work today, and if I can’t figure it out, I will at least post my experiment up. Maybe someone else will figure out my mistake…

Randy

2 Likes
10

Hi, @MichaelBenDavid;

Yesterday I’ve made some tests, but I was just able to find the culprit(s).

At least in Quaternions Rotation Mode, Locking Rotation Axes, or similar, such as trying to Rotate only the Y Axis (from the Copy Rotation Bone Constraint on the TAN-Forearm1.R, causes ‘malfunction’, because there is this spontaneous, combined Rotations behavior, and W Axis will interfere.

I think I’ve never applied this Option before, but this seems to work? You get to change the Order: ZXY Euler on the Copy Rotation Bone Constraint, this will make the ‘Fake-Lock’ and allow you to decide (most importantly) which remaining Axis to ‘Fake-Lock’. Now, I don’t get why it’s the ZXY Euler that works (for preventing Z Axis Wrist Rotation to interfere) and not XZY Euler… From the Euler Rotation theory you know; the third Axis listed is the ‘freeer’ one, the first Axis listed would be the second one in Order of priority, and the middle one the most sacrificed one in the name of Gimbal-Lock. The fact is that this seems a good case scenario to use this Option, without even touching the Bone property itself (it may remain Quaternions Rotation Mode).

Oh, btw, be careful about those Key Frames. I believe they are for prescribed Actions under control, but they can mess up the Rigging process if the rigger is unaware of their existence, in certain cases.

Captura de tela 2024-12-15 113103
Captura de tela 2024-12-15 1131031367×697 256 KB

We can see that, after Y Axis is Rotated sufficiently, the Z Axis Rotation (whole Hand Rotating Up/Down) is not causing any more additional Rotation to the Bone-Constraint Wrist; instead, the X Axis Rotation (whole Hand Rotating Left/Right) is causing that, however, in an ‘Aligned’ fashion, let’s say.

This adjustment Setup, which seems clean to me (according to the limitations of the system; so it’s still not ideal), yet should be thoroughly tested, if you haven’t got any other solution.
But in the end, it was not a Space issue, it was also not a Stacking Transforms issue… well, maybe a ‘Stacking Transforms’, yes! but in what regards the mathematical madness involving those limited Rotation Modes, applied to… 3G Rigging. But, we could just say: it is just a Rotation Mode issue. With this Order Setup in mind, this shall help solving (well… not solving entirely, but improving at least) similar issues. A very good, didactical case.

2 Likes