IK solver - preferred angle

[JP]

Hey guys,

So this isn't strictly a Python question (err..not at all) , but
there are a lot of bright minds here and I hoped someone might have
some experience with this since the rigging and python worlds often
overlap.

I'm having an issue where an ik RP solver on a leg will sort of
'freeze up' when the ik handle and the character hit a certain pose.
For instance, everything will work fine when you scrubbed up to frame
50, and then the knee joint would 'lock' to whatever the preferred
angle was set at (i.e., <<0,30,0>>). The kicker is that you could
then scrub *backwards* and the solver would still be locked. If you
changed any other inputs to the joints being solved, like the scale
for a stretchy leg, the solver would seem to 'pop' back to solving
correctly.

When rigged, the joints are oriented to a plane, the handle is
connected while the joints are bent, the pole vector is placed along
this plane, and a preferred angle on the joints is set...so I think
I've got my bases covered there.

So IMO, there's some black magic happening in the ik solver
computation that I don't understand. Another oddity is that setting
the preferred angle for the joints at, say, 30 degrees wouldn't fix
the problem, but setting it at 90 degrees would (at least for now, but
who knows when this will rear its head again?). My guess from the
scrubbing issue is that the node doesn't do a full computation unless
certain input plugs change. It's hard to say, because an ik handle is
one of those nodes that (for some reason) doesn't actually have
connections to what it's changing.

I would LOVE to get my hands on the algorithm that's used to compute
and set the joint rotation values. Any Autodesk people in the
house ? :)

Thanks all,
JP!

[Beau Garcia]

Hey JP,

Sounds like a strange one. Have you had any "Warning: Cycle on <node name> may not evaluate as expected" warnings ? . I have seen similar strangeness when a cycle in the dependency graph is present, causing unexpected evaluations.

The warnings might be suppressed with " cycleCheck -e off " .

You can access ik solver algorithms on the net, i don't know where to find the exact one that Maya uses though.

Cheers,
Beau

--
http://groups.google.com/group/python_inside_maya

[Richard Kazuo]

Popping things in place when changing attributes sounds like a cycle
to me... can you share a demonstration scene or screengrab that
replicates the behaviour?

cheers,
Richard

> --
> http://groups.google.com/group/python_inside_maya

[Jeremy YeoKhoo]

Hi JP,

Yes, I have seen this happen a few times before.

All I can say from my experience is that when you're scrubbing the timeline, the IK RP solver does not do a full calculation, similarly if you did a dynamics solve and scrub the timeline without maya doing an initial iteration for each frame. From my understanding the rotate plane is just a way to get out of the gimbal lock with the IK algorithm (Im guessing, it is because the solver uses euler angles in its maths)

Id bet it would be extremely difficult to get a hold on Mayas IKRP solver algorithm. There are a few studios out there that uses their own in-house IK solver plug-in to workaround Maya's.

But yeah, if anyone could share some light into this, that would be awesome

-Jeremy

--
http://groups.google.com/group/python_inside_maya

[Jeremy YeoKhoo]

Hi JP,

Yeah, I too had the impression that the preferred angle is based on the slightest value.

But by the way, the popping occurs only when you scrub the timeline. The popping wont occur if you allow the solver to do its necessary computations, so playblasting would be ok. So its not a major issue, just annoying when you animate

Do you have joints fully lined up straight?

Its also possible if you imported your rigs, there is another IKRP solver in there? Preferably the one scene (or the one rig) should have on IKRP solver solving for all IKRP handles

Is it a flipping issue you are having? The pole vector simply tells the rotatePlane where that plane is (eucledian space). So what my workflow is simple

(i) Set up preferred angle

(ii) Copy joints before setting up ikHandle

(ii) Point the pole vector so it works for you. (eg X=1.0, Y=0, Z=0) The joints will twist.

(iv) Play with the twist until the joints lined up with the copied joints.

It is not super accurate, but it works out for an animation context as opposed to an cad engineering context.

Hope this helps
-Jeremy

On 31 October 2010 04:27, <jspa...@gmail.com> wrote:
Thanks guys,

I'm pretty sure I don't have any cycle errors - but I'll double check. It does somehow seem like the node doesn't fully compute, and it only happens in very specific cases. I'm sorry I can't provide any really good examples - don't wanna get in trouble with the man ;)

I mentioned that setting the preferred angle at <<30,0,0>> wouldn't fix the problem - actually, it would look like it fixed it, then after a bit of scrubbing the problem would reappear. It didn't seem to reappear at <<90,0,0>> degrees, which seems interesting to me, as I was under the impression that setting even the slightest angle would cause the joints to bend in that direction if there weren't any other hints for how to solve.

There's a relationship between joint orientation, the preferred angle, and the location of the pole vector that I just don't fully understand. I haven't dealt with the preferred angle much - I've always set up ik on pre-bent joints, and assumed that this angle was somehow set internally, but now it seems like it does have an impact on the way the ik solves in some specific circumstances, even when joints are bent when the ik is set up.

Looks like I'm in for some research/headaches :)

[JP]

Thanks all,

I'm putting this to bed, as it seems very rare, there are some ways
around it, and there are other things demanding attention. I'm still
very curious about the *exact* role that the preferred angle plays in
the solve, as my previous assumption seems to be incorrect.

Also, just to clarify - I didn't mean to sound like I actually wanted
someone from Autodesk to slip me some code - I know it's not gonna
happen and is probably illegal...plus, I'm pretty sure it would take
me a year to figure out how it worked :P. That being said, I've
always thought it'd be nice to have some better documentation on the
impact of various inputs to ik the system and their impact on the
solve (joint orientation and preferred angles being the main two that
seem fairly undocumented).

I think I mistakenly replied to Jeremy directly, so I've pasted my
original reply below:

"""
Thanks guys,

I'm pretty sure I don't have any cycle errors - but I'll double check.
It
does somehow seem like the node doesn't fully compute, and it only
happens
in very specific cases. I'm sorry I can't provide any really good
examples -

there are good reasons :)

I mentioned that setting the preferred angle at <<30,0,0>> wouldn't
fix the
problem - actually, it would look like it fixed it, then after a bit
of
scrubbing the problem would reappear. It didn't seem to reappear at
<<90,0,0>> degrees, which seems interesting to me, as I was under the
impression that setting even the slightest angle would cause the
joints to
bend in that direction if there weren't any other hints for how to
solve.

There's a relationship between joint orientation, the preferred angle,
and
the location of the pole vector that I just don't fully understand. I
haven't dealt with the preferred angle much - I've always set up ik on
pre-bent joints, and assumed that this angle was somehow set
internally, but
now it seems like it does have an impact on the way the ik solves in
some
specific circumstances, even when joints are bent when the ik is set
up.
"""

Anyways, thanks for the help!

[j...@janberger.de]

The attribute preferred angle serves two purposes from my POV.

First, it gives the solver an idea around which angle or rather axis a joint is

supposed to be rotated about from the user. Second, during the solve the preferred angle is used as

a starting point for the solver. As usually this results in a plane defined by the

start joint, the effector and the ikHandle, the solver has a good starting point

to calculate a unique solution. Of course there are cases where this doesnt

work and for those the ultimate tool is a pole vector, ´given it is positioned properly in space.

I guess technically Point 1 and 2 are technically identical but that is how I can

make sense of this attribute. Also this may explain why when joints are at an angle

when you add IKs you do not need to set the preferred angle attribute as Maya can figure it out.

 

JP <jspa...@gmail.com> hat am 1. November 2010 um 19:22 geschrieben:

> --
> http://groups.google.com/group/python_inside_maya

[sunny]

can you put up a file which is having a problem for us to actually see
whats going wrong! i think it might be the joint orientation playing
with preferred angle..

[Richard Kazuo]

Popping things in place when changing attributes sounds like a cycle
to me... can you share a demonstration scene or screengrab that
replicates the behaviour?

cheers,
Richard

On Friday, October 29, 2010, Beau Garcia <garc...@gmail.com> wrote:

> --
> http://groups.google.com/group/python_inside_maya

[Viktoras]

We've had some problems with IK locking into straight line with no
apparent reason when character is far away from 0,0,0 point (talking
about roughly 3000-4000 units away). see if you still have this problem
with the rig if you move everything closer to coordinate center.

--
Viktoras
www.neglostyti.com

[Beau Garcia]

That sounds like a number precision issue that can arise when working with transforms that are a great distance away from the origin.

--

http://groups.google.com/group/python_inside_maya

[Todd Taylor]

I have had this EXACT same thing happen recently. RP IK locking when
the joints are straight scrubbing through the timeline. I fixed it in
the exact same way, as well : set preferred angle to 90 degrees. I
first tried a slight angle of 1 degree then 30 degrees figuring it
wouldn't matter the actual value. However, only 90 degrees worked all
the time.

Another clue,though, was that I had an expression controlling the
scale value of the joints in the IK (typical stretchy IK). This
problem went away when I broke that scale connection. So, that has
something to do with it, for sure. My assumption ended up being that
the scale was changing the inputs (joints) to the IK solver thus
triggering a re-initialize process of some kind and when the scene was
scrubbed to a frame where the joints were straight, the solver needed
the preferred angle to know what plane to use. I have no idea why it
works with 90 degrees and not with 1 degree.

How exactly the preferred angle works is mysterious with this kind of
behavior and since the docs are so light on the subject, we can only
guess.

-TT