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).

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone