That sounds like a number precision issue that can arise when working with transforms that are a great distance away from the origin.
On Mon, Nov 29, 2010 at 6:54 PM, Viktoras <[email protected]> wrote: > 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. > > > On 2010.11.28 13:58, Richard Kazuo wrote: > >> 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<[email protected]> wrote: >> >>> 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 >>> >>> >>> >>> >>> >>> >>> On Fri, Oct 29, 2010 at 4:34 PM, JP<[email protected]> wrote: >>> >>> 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! >>> >>> -- >>> http://groups.google.com/group/python_inside_maya >>> >>> >>> -- >>> http://groups.google.com/group/python_inside_maya >>> >> > > -- > Viktoras > www.neglostyti.com > > -- > http://groups.google.com/group/python_inside_maya > -- http://groups.google.com/group/python_inside_maya
