I would like to extract and use rotation values from an IK bone chain to drive the rotation of another bone. What would be the correct way to get this in Houdini.
I can see the Pre-Transform values when I middle click on the bone, but how do I grab the values?

So far I've been using the blend SOP but I get all kinds of flipping.

Is there a way to directly extract IK bone rotation values?

if your IK blend is set to 1
you can use chop()
chop(“/obj/chopnet/chop1/channelName:rx”)

Hi Werner,

If you enable the export flag on your kinematic solver in CHOPs, your rotation values will be populated by CHOPs on the bones. Now you can reference copy the parameters.

I'm not entirely sure how this affects IK/FK blending.

Hope this helps,
Andy

Thanks Michael and Andy!

Both options work…but only if IK blend is at 1. This is not a problem as I won't be using FK.
——————————
Just checked Michael's method and FK works as well.

On the left is the Chops flag method and on the right the chop() method.
Start off with IK and then blend in FK. The short blue bone gets 50% rotation of the 1st bone in the IK chain.
Just wanted to share…maybe this can help other new users.

you can set the blend to 1 temporarily to get the values then set it back to whatever it was
doc/tutorials on these subjects is needed

for the pythonists amongst us…
have a look at the hou.ObjNode docs
you'll find lots of methods to get/set transform parameters…

It works well, and I think you are right. Rigging need some love when it comes to documentation and tutorials.

One thing I noticed is that bones zero out when blending from IK to FK. Most other applications will keep the current orientation of the bone before the IK to FK blend. This is a bit cumbersome. :cry:

for simple cases where you just want the angle between a pair of bones, you could use the hscript expression command:
boneangle
the bones that get compared don't necessarily have to be linked.
-j

johm
for simple cases where you just want the angle between a pair of bones, you could use the hscript expression command:
boneangle
the bones that get compared don't necessarily have to be linked.
-j

Sure, but animators will not want to bother with expressions to match IK/FK bone rotations. Or were you referring to my first question?

the bones don't know about the rotations computed by the IK - so they just go back to whatever their parameters are…

I suppose you could set something up that set the rotations of the bones to the IK solution as soon as the IK/FK blend was !=1…but I think this would get weird…

most people set up buttons to do matchFKtoIK/matchIKtoFK and handle it there….

arctor
the bones don't know about the rotations computed by the IK - so they just go back to whatever their parameters are…

I suppose you could set something up that set the rotations of the bones to the IK solution as soon as the IK/FK blend was !=1…but I think this would get weird…

most people set up buttons to do matchFKtoIK/matchIKtoFK and handle it there….

Would this be something the dev's would consider changing? I will submit a RFE, as I think it would help workflow allot.

just to be clear
you want the bones to remain at their IK rotations when you blend IK off?

that doesn't seem like something animators would want to happen automatically…
unless I'm very wrong.

arctor
just to be clear
you want the bones to remain at their IK rotations when you blend IK off?

that doesn't seem like something animators would want to happen automatically…
unless I'm very wrong.

No, I don't think that's what he's asking. If one would key both the goal's position as well as bones' rotations for a IK-Fk blend, it wouldn't make sense to not have the bones revert to their keyed rotations when going towards FK.

Werner, if you could create a gif with a little more details would be great.

On thing I did find weird in Houdini is that you have an IK chain and rotate one bone, its rot. values change even though, as expected, in the viewport the bone stays fixed. Further more, the bone keep that rot value even when the goal is moved around. Is there a reason for this? I'm aware of the fact that Houdini deals with bone chains a bit differently than other apps and I'm not yet very familiar with it, so that is why I asked first before screaming “bug!”. It isn't a bug, is it?

Here's another one I don't get.

Attached is a basic IK chain with the goal animated from one position to another (frame 1 to 24). Bones have their rot. animated (also keys at 1 and 24). The IK-FK blend animated from 1 to 0.
Bones have (0,0,0) for rot. at frame 1 and the same values at frame 24. Yet they don't return to the same position they were at frame 1 when they reach frame 24 where the FK is 100%. Why?

well, if your chain is driven by IK and you grab a bone (FK rotation), then rotate it, you may change the FK rotation, but it will not drive the bone until you blend to FK or disable IK

this is like any other CHOP based workflow, if you apply motion FX you can still change original value by grabbing the handle and edit, however that flows through CHOPs where the value may get changed/overriden and exported to the parm back

FK/IK match is usually done at a rig level by some simple python scripts as you are usually using higher level control objects that need to match, not many animators animate by grabbing bones directly

McNistor
Here's another one I don't get.

… Yet they don't return to the same position they were at frame 1 when they reach frame 24 where the FK is 100%. Why?

bones, like all objects in houdini, carry around a pre-transform. When your bone rotation values are zero you are getting the pre-transform position. This isn't necessarily the same position your IK end effector was when you keyed frame 1.

tamte
well, if your chain is driven by IK and you grab a bone (FK rotation), then rotate it, you may change the FK rotation, but it will not drive the bone until you blend to FK or disable IK

this is like any other CHOP based workflow, if you apply motion FX you can still change original value by grabbing the handle and edit, however that flows through CHOPs where the value may get changed/overriden and exported to the parm back

FK/IK match is usually done at a rig level by some simple python scripts as you are usually using higher level control objects that need to match, not many animators animate by grabbing bones directly

I understand. It was a purely theoretical curiosity, because I want to understand what's going on, not because I intend to animate the bones directly.

johm, thanks.
After I made that post it struck me that it might have something to do with the pre-transforms. I've extracted them and redone the test. This time the bones returned to their keyed rot. when the Blend reached 0
It still doesn't compute in my mind why this is happening before extraction, that's probably because I haven't got the knowledge (yet hopefully) of what's going on under the hood.

edit: after some googling, it seems that extracting the pre-transforms is similar to resetting the neutral pose in Soft. This doesn't matter in XSI, the bones return to their original pose either way, but then again, XSI has a weird way of dealing with bone chains with its builtin IK glued effector… thing.

arctor
just to be clear
you want the bones to remain at their IK rotations when you blend IK off?

that doesn't seem like something animators would want to happen automatically…
unless I'm very wrong.

After having a chat with our animators, No. It is not a problem, but having an example in the docs on how to do IF/IK matching would be helpful to smaller shops without TD's. Rigging docs is on the thin side.

Anyway, I would not want to ad this to the developers plate when they could be spending more time on developing better capturing and deform methods.
Waaaaay more important in my books.

Over the last two weeks my team has rigged multiple characters and creatures, and they were blown away by the flexibility. Almost all complains came from initial capturing, weight painting and setting up Pose Library.
I will start a new thread on this soon if it would help development.

thanks Werner…
I'd be very interested in any kind of feedback you and your team have about rigging and animating…either here on the forum or through support
my primary job at SESI is to develop better rigging tools/workflows as well as help support users, and a part of than will be better docs and learning materials…
all of this is separate from actual ‘development’, which I don't do

Werner Ziemerink
…I will start a new thread on this soon if it would help development.

Yes, please do so. We're currently transitioning characters from Softimage to Houdini and have some input to give ;-)

Thanks,
Andy