Forum Moderators: Staff
Poser Technical F.A.Q (Last Updated: 2024 Nov 13 12:50 am)
Welcome to the Poser Technical Forum.
Where computer nerds can Pull out their slide rules and not get laughed at. Pocket protectors are not required. ;-)
This is the place you come to ask questions and share new ideas about using the internal file structure of Poser to push the program past it's normal limits.
New users are encouraged to read the FAQ sections here and on the Poser forum before asking questions.
Interesting! I'd noticed this intuitively but hadn't thought about it
mathematically. A little experimentation shows that the legs aren't
special; arms do the same thing. When you IK the hands and then
move the hip around, the hands go up when the arms hit a stretch limit,
leaving the little outline behind exactly as the feet do. When the hip
goes down, the feet AND hands never go below the original Y.
Presumably this is done for the sake of quadrupeds, where all four
feet are expected to rise off the ground but never sink below it.
My python page
My ShareCG freebies
Upon a little further investigation, there is a natural way to accomplish this with a secondary goal (both legs and hands). Since the hip is naturally 'above' the legs, one cannot possibly start with the hip below them (there is a relative positional relationship that exists between the hip and feet in FK). So, all one has to do is watch for the primary goal (the foot's endPoint) to become coincident with the goal position. Then one considers the foot's origin to start to reach for the secondary goal. This makes it easy to replicate the behavior.
I'll have to investigate the arm IKs more, but it appears that their origin will go beyond in the hip Y direction if enough translation is applied to the hip - but it may be that the secondary goals are set to activate when the primary goals are in proximity (same for the legs). One arm or the other definitely locks when translating the hip side-to-side (X) so that the hand origin does not rotate.
So, basically, it seems that if the EndPoint coincides with the 'goal', then the Origin is maintained as long as possible (while the chain rotations don't disrupt this coincidence).
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
Content Advisory! This message contains nudity
The attached animation is a zeroed Jessi with limits for Bend and Side-Side on the thighs and shins set to zero.
Content Advisory! This message contains nudity
It seems to me that hands work the same as feet, and that IK works the same irrespective of wether you move the hip up or down. The goal actor will maintain its orientation untill the connecting limbs are stretched tight, then the goal actor will start to bend.
I'll agree that the hands work the same as the feet.
But I disagree about the second goal. I'm testing in Poser 4 ProPack, so maybe IK changed in later versions - will need to test. But the stock figures plant first the normal goal (the tip of the foot) and then the secondary goal (the origin of the foot). Same for the hands actually. And they remain planted until the direct distance from start of the IK chain to the secondary goal exceeds the length of the links (body parts) inbetween. At which point, the secondary goal loses traction and then the primary.
I don't see the feet in P4PP doing what Jessi is doing at all. And testing Jessi in Poser 6, the feet still plant! I'd upload a video but then I'd need to do the video capture on the Mac. Is this some modification - yes - turn off 'Use Limits' and try again, please. :) Even with it enabled, there is a slight planting before the heels or wrists will lose grip.
To see how this works more clearly, rotate one leg up more than 90d (like a kick) and then enable leg IK. Note that as you translate the hip, the feet (no matter the position/orientation in space) always go right back to that initial position when IK was enabled. Maybe the foot goal is considered in totality - not just the tip (endPoint) but the only way to do that is to consider another point in my case. Poser's strange IK (with reparenting the goal object, different rotations stored for IK and non-IK) might be allowing just the goal's position and initial rotation but I won't be doing it this way.
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
Perhaps I am misunderstanding your original post. You seemed to me to be saying that the foot acts diffrently when when it is pulled up than it does when it is pulled down. This is not so.
Quote: "The question arises as to why the foot origin never goes past this. It is allowed to translate in one direction but not the other. Is this possibly some 'Up-Vector' (+Y for the most part)?"
Under the same conditions the foot origin It is allowed (or disallowed) to translate in in any direction, there is no diffrence between up and down, there is no "Up-Vector" that I can discover.
I have tried your "kick" position, but fail to see what it demonstrates. Yes the feet will maintain their position and orientation untill they are forced to abandon it by being stretched too far by the connecting limbs, that's what IK does!
I can't help feeling that I am missing your point here. Perhaps a restatement of your point, and perhaps couple of static screen shots would help.
P.S.
I am using P6 (as my HDD with P4 has become corrupt), but doubt they have changed the implimentation of IK.
When the direct distance to the goal from the IK chain start is less than the summed lengh of the chain links (body part lengths), the goal body part is 'planted' to its original position and rotation. Not just the tip of the foot.
IK doesn't work like this! You have a goal point. You have a tip/end-effector point. These two points are in a continual process to be coincident as the goal is moved. When coincidence is not possible (when the distance to the goal from the chain start is greater than the total lengh of the chain links), the chain just 'points' toward the goal. When the hip is translated, the goal and tip will remain aligned as long as that distance relationship is maintained. In other words, the example video for Jessi - that is how basic IK works in all systems.
But Poser, with 'Use Limits' disabled it seems, the entire foot or hand (not just a single point) will remain aligned as long as the distance relationship is such that the goal-start distance is less than the total links length.
Here is the default stance:
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
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
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
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
For IK to do this, it requires two goals or something that acts similarly. Look at any other 3D application leg IK system where the foot plants for, say, walk cycle foot falls. There are two goals (at the least) or a control box that acts similarly to constrain the foot from penetrating the 'floor'.
Some applications actually implement a 'constraint' that can be applied to links in the IK chain. Some may go for physical dynamics or collision detection. It is assured that Poser isn't going to these extremes or levels of implemention.
What do you think?
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
I can certainly agree with you on what you call the "planting" of the goal actor, the prefference of the actor to maintain its position and orientation. As Poser is the only 3D app I have ever used to any appreciable extent, I just take this for granted as normal and self-evident behavior.
There were two things I was taking issue with. The first is any sugestion the the behavior of IK is varient with respect to direction (anisotropy), I am fairly certain that this does not happen.
The second issue, and I am far less certain on this point, is how Poser impliments the planting or bending of the goal actor. Once IK has been turned on the goal actor is (by default) parented to the BODY, it will translate and rotate with the BODY. Taking a shave with Ockham's rasor I would expect the goal to fixed (planted) with respect to the BODY, (to my mind) this requires no explination, it is normal Poser behavior to be expected, it does not require any secondary goal. The only thing that requires an explination is the bending once it does start to bend, not the planted behavior.
Of course just because this is the simplest explination does not mean that it is the correct explination, there may be good reasons for implimenting a secondary goal, rather than relying on standard Poser behavior that are not evidant to a none-programmer like myself. It would be interesting to see if there is some experiment that would confirm or refute the existance of a secondary goal, but I can't think of one at the moment.
It is that parenting of the goal body part to the BODY that has me suspicious as well as this should allow for the rotaiton to be maintained as global - otherwise (if parented as usual) the bending of the other IK body parts would require update of the apparent rotation of the goal object so as to counteract the other rotations.
Since I'm not reparenting the goal body part to the BODY when IK is enabled this may require a comparison of my two goals for equivalence with their end-effectors and then an update of its rotations with respect to any rotations of the other IK chain body parts. Fun. :)
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
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
Here's an interesting observation. We've all used Poser IK with the legs to translate the hip body part so that the figure, say, sits or kneels. With some observation, it appears that Poser treats leg IK as special and sets up a so-called 'secondary goal' which would be the Goal (foot) origin (whereas the Goal body part's endPoint is the primary goal). So, as you translate the hip upwards the secondary goal is allowed to 'translate'. But when you translate the hip downwards, the foot origin eventually 'coincides' with the secondary goal (the foot origin stored when IK is enabled) and the foot is 'planted' to this position.
The question arises as to why the foot origin never goes past this. It is allowed to translate in one direction but not the other. Is this possibly some 'Up-Vector' (+Y for the most part)?
My visual model seems to be that the local Y is used as such and determines which direction (+/-Y) determines translatability or not. This would mean that when the delta tries to go negative (relative to the secondary goal), the secondary goal is 'limited' so as to be planted whereas when the delta is relatively positive it is allowed to translate.
What do you think?
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