Wed, Nov 20, 1:16 AM CST

Renderosity Forums / Poser Technical



Welcome to the Poser Technical Forum

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.



Checkout the Renderosity MarketPlace - Your source for digital art content!



Subject: Poser Leg IK?


kuroyume0161 ( ) posted Thu, 27 September 2007 at 10:21 PM · edited Tue, 19 November 2024 at 11:10 PM

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


ockham ( ) posted Thu, 27 September 2007 at 11:02 PM

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


kuroyume0161 ( ) posted Thu, 27 September 2007 at 11:59 PM · edited Fri, 28 September 2007 at 12:01 AM

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


lesbentley ( ) posted Fri, 28 September 2007 at 7:14 PM

Content Advisory! This message contains nudity

file_389335.gif

I'll stand to be corrected on any of this, but I don't buy the secondary goal theory. It seems to me that if the position of the goal can be maintained without rotating the foot it will be. If it becomes necessary to rotate the foot to maintain the position of the goal then the foot will be rotated. I don't see where a secondary goal comes into it, Ik on the feet seems to me to work the same as IK on the hands. The situation may be a bit more complax than I have painted it, but I think in essence all Poser is trying to do is avoid bending the foot, if it can maintain the goal position by bending the thigh and shin it will, if not it will bend the foot.

The attached animation is a zeroed Jessi with limits for Bend and Side-Side on the thighs and shins set to zero.


lesbentley ( ) posted Fri, 28 September 2007 at 8:26 PM

Content Advisory! This message contains nudity

file_389339.jpg

Attached is another example.

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.


kuroyume0161 ( ) posted Sat, 29 September 2007 at 9:23 AM · edited Sat, 29 September 2007 at 9:28 AM

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


lesbentley ( ) posted Sat, 29 September 2007 at 11:00 AM · edited Sat, 29 September 2007 at 11:06 AM

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.


kuroyume0161 ( ) posted Sat, 29 September 2007 at 11:50 AM

file_389405.jpg

I think that, yes, my first statement didn't express the possible full observations.  Now that I have observed this for a bit, the direction up/down here is irrelevant.  It has more to do with the direct distance of the goal from the start of the IK chain and the length of the links.  So, stated more clearly:

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


kuroyume0161 ( ) posted Sat, 29 September 2007 at 11:51 AM

file_389406.jpg

Here is the leg when the total link length is less than the goal-start distance

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


kuroyume0161 ( ) posted Sat, 29 September 2007 at 11:52 AM · edited Sat, 29 September 2007 at 11:52 AM

file_389407.jpg

Here is what I'm talking about

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


kuroyume0161 ( ) posted Sat, 29 September 2007 at 11:53 AM

file_389408.jpg

And just in case that doesn't seem odd, how about this which illustrates my point clear as glass. :)

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


kuroyume0161 ( ) posted Sat, 29 September 2007 at 11:59 AM

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


lesbentley ( ) posted Sat, 29 September 2007 at 2:20 PM · edited Sat, 29 September 2007 at 2:33 PM

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.


kuroyume0161 ( ) posted Sat, 29 September 2007 at 2:56 PM

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


Privacy Notice

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.