I'm having difficulty finding a way to 'reconstitute' the Goal body part rotations when IK is OFF from the same exact pose when IK is ON (as stored in PZ3 or CR2). It is not additive/subtractive between axial rotations. It may be transform matrix application from Hip to Parent on Goal body part. But this hasn't given me any proper results yet. It is really hoped that the IK solver isn't playing a part in the IK rotation angle determination - as I'm not privy to the IK solver code used by Poser. I can place the entire chain down to the Goal without problems. Yes, the Goal is placed as a child of BODY when IK is ON. So, one would think that when IK is turned OFF, the IK rotations would be fixed by hierarchical tranforms of the intervening body parts (and vice versa). Maybe the origin of each body part needs to be considered? At a loss...

Hi kuroyume--

I'm interested in this issue too, since I've been wanting to create a library of stock PZ2s built using IK then applied with IK off. But when the saved animated poses are applied to an IK off figure, the Goal part doesn't stay put as you've seen.

I've only been able to guess at what is going on, but my first guess is that the sequential rotation solution from Body to Goal part when IK is on is a different order somehow from the rotation solution through the body part chain when IK is off. (You know, the way a 30 degree xrotation followed by a 75 degree yrotation gives a different ending position than when the rotation order is switched.)

Perhaps if someone knew the exact nature of this problem, and someone (else?) could come up with a solution, we might also find the best way to avoid those bizarre over-bending Goal part effects one sometimes sees switching IK on and off.

So... no solution here but I want to thank you for posing the question!

Tguy

I think that I have an answer - at least it works in Cinema 4D for this issue. When IK is disabled, the Goal is parented as normal in the hierarchy and its rotations reflect that. When IK is enabled, the Goal is parented to the BODY and the rotations reflect that. In order to go from enabled to disabled rotation values, you must apply a rotation transform matrix that is constructed from all of the rotations from the part after the BODY (usually Hip) to the part just before the Goal in the hierarchy. This is applied to the rotation of the Goal.

Sounds quite reasonable. I would guess it might be difficult, if not impossible, to come up with a generic rotation transform matrix since the appropriate rotation of each "downstream" part in a chain would depend on how its upstream partner interpreted its share of the simulation of the single BODY rotation. I might not be clear here, but I'm thinking it's actually kind of a Bayesian problem, or maybe even a nested Bayesian. Hmmmmm....

That's where the matrix concatenation comes in. This is how it is done for any hierarchy - the transformations of the parent are applied to the child in an accumulative sense. So, as you go down the hierarchy, the matrix accumulates the rotations. One thing to note, the rotations on the children may need to consider the coordinate system of the parents - but I'm uncertain as it didn't affect me in Cinema 4D. Coordinate frame shifts are not very difficult when using matrices.

It would be great if there was a way to do it; but I'm still wondering whether, as a practical matter, one could build a generally applicable matrix from scratch which would match up the two different rotation configurations involving IK on vs IK off.

Say you have a foot (goal) planted with IK on and in the tenth frame you rotate the hip along the x-axis by 10 degrees then the z-axis by 5 degrees then the y-axis by 20 degrees. It seems you might be able to construct a rotation matrix which reasonably reproduces the frame 10 result when IK is off, but what about all the intervening frames?

It seems to me there would be a number of different rotational sequences for the body part chain (when IK is off) which would let you arrive at the frame 10 pose, but given that the rotational sequence influences the effect of another incremental change in rotation along any given axis, how do you know what order to conduct the individual part rotations? Seems like the only way to do it would be to exactly mimic the specific rotational sequencing which occurs when IK is on.

But re-reading your messages, it seems that is what you're after: the specific rotational ordering along the body part chain which is followed when IK is on. I wonder if EF would be willing to tell you?

Here's the thing: When IK is on, the rotations of the Goal are in worldspace. When IK is off, the rotations of the Goal are relative to the rotations, etc, of the next immediate body part downthe chain... Therefore,without knowing the rotations of every single body part in the chain, there is no real way to calculate the IK on rotations of the goal.

Actually, when IK is ON, the rotations are relative to BODY. All rotations are relative to something (UNIVERSE, if nothing else). But here's a weird one. I've been using "BrainStem" to check IK on/off. I saved the CR2 with IK on and off. This works fine in my plugin. But the original CR2 (that comes with Poser and has IK enabled) - now read this carefully - doesn't work and has different rotations than the saved CR2 with IK enabled. I've done a file compare and the only differences are in channel naming (which should have no effect unless Poser responds to this difference), lack of "jointMult 1" lines in the Twist channels, and those rotation values. Any other differences are inconsequential and nonrelated. There was also the inclusion of both angles and startPt/endPt in both Twist and Joint channels in the original. But removal of the unused lines (angles 0 0 0 0, startPt 0/endPt 0) had no effect. Can anyone explain this?

Okay, I can only explain why it's happening, but not how to compensate for it. I loaded BrainStem and immediately saved as a new CR2. Same problem in both files. I loaded BrainStem, disabled IK, enabled IK, and saved as a new CR2. Now the rotations work (and they differ from the two files above). NOTE: a file compare only shows differences in rotation values in the key (and minor differences in some translations). This would explain why, in the past, sometimes enabled IK worked and other times it did not. How the hell does Poser know? As I said, there are no other differences at all. Can anyone explain this? ;)

Message edited on: 06/09/2005 01:46

I'm closer to explaining this. This path is familiar. When I first started trying to decode how enabled IK was setup in Poser files, the starting point was that the Goal was being translated. This didn't work out so well in translation to Cinema 4D. But upon closer inspection, rotation values were set (in some cases, as we know now) that could precisely place the IK chain when enabled (and it is precise!). So I disgarded the Goal translation method for the chain rotation method. Now I know why the chain rotation method fails sometimes and succeeds others. Here is what Poser is doing - Poser is using the Goal translation and putting the chain through its IK solver. This is the only explanation that makes both of these files work. This is bad for me as I'm not privy to Poser's IK solver algorithm - and from all research of its anomalies, it is, as usual, non-standard. Or at least standard with Poser's usual adaptations that causes it no longer to be standard. ;) The rotation matrix is out, at least for general compatibility. External to Poser, you are going to need to use the Goal's translation and some compatible IK solver to rotate the body parts accordingly. How sucky is that!?

This is all beyond me at this point (actually, it was probably beyond me at the beginning). But I do have one thought / suspicion about your with- and without-IK CR2 comparisons. I've noticed sometimes when I run cloth or hair simulations, that the figure is changed in some way (e.g., a body shaping magnet is altered somehow so the mesh is distorted). If I then close that PZ3 and hit "new" then reload that same figure, the distortion is still there. BUT... if I exit Poser entirely and then load the same figure into a "clean" new workspace, the distortion is gone.

How is this relevant to your tests? I'm wondering if Poser doesn't store some values in data registers somewhere, then help itself to those data again when it thinks it needs them to refresh or alter or do something to a given CR2. And maybe on closing the application entirely those data registers are cleared, so the next time that same CR2 is loaded the (in my case, distorting) data inputs are gone so they have no effect.

If something like this is going on, then perhaps some of the data which influence IK-related activities is lurking during your tests. So I wonder if you would see the same results if you compared your CR2s' behaviors after closing Poser each time you test a particular CR2.

Although that may be a possibility, I have always seen this behavior, even in Poser 4. And many of the files that are being tested are standard, original, and untouched Poser figures (that come with Poser). An IK solver is the algorithm that determines how the joints are best rotated (within any set rotation limits) to reach the Goal. In Poser's case, they have combined the Goal and the End Effector (the body part that is trying to reach the Goal). The only important thing for the IK solver is the location of the Goal - which is always given by translations. This is why you should only use Translation (dials or tool) when doing Poser IK. With that in mind, no matter what the chain rotations are set to, the important part is the Goal's translation values (transX|Y|Z). This why Poser doesn't care if the rotations meet the Goal or not. It takes the Goal's translation and churns it through its IK solver algorithm to attain the correct chain rotations. Good for Poser, bad for me! ;( When IK is disabled and then reenabled, the nonIK rotations are just retained somewhere and saved out with the PZ3 or CR2. Since they don't matter when IK is enabled, the values could really be anything. I'm just going to have to live with inaccurate IK solutions (Cinema 4D obviously uses their own algorithms which differ from Poser's).

Ah, I think I understand now. I guess this would explain why I can set up an animation that might have rotations among the body parts in an IK chain, then turn on IK, and keep the Goal part in place throughout the animation by just deleting the translation parameters for the Goal part(s) without touching any of the keyframes for the rotation chain body parts.

If I have this right now, then I could streamline the Legs Still and Hands Still python scripts ockham created so they just focus on the translation parameters for the Goal part and don't bother with the rotation chain body parts. This would be a big advantage since the current scripts purge all keyframes, including settings for morph targets among all the bpdy parts in the relevant IK chain.

Well, I guess I was no help to you in the end, but I do appreciate that this discussion may help solve a thorny python issue... so THANKS!