Alan is right, the parameters wont be locked. Also in 2013 there seem to be 2 UV to Location Nodes,
One is a conversion and the other is a geometry query If I use the geometry query one it wont actually update my UV location at all. If i use the conversion one it works properly Its working fine on this end as long as I dont touch the global kinematics after the ICE tree starts driving it On Wed, Feb 6, 2013 at 10:17 AM, Alan Fregtman <[email protected]>wrote: > You're not doing anything particularly wrong. > > There is nothing that locks the parameters that are ICE driven. It's weird > and annoying. Don't touch them or you'll be asking for funkyness. > > Your tree looks fine and is correct so to speak, but you may wanna use the > "Add Constraints" compound and work off "Constrain Pose" for your custom > constraint base. All those compounds do is write the old kine in > self.__TmpConstraintPose then set self.kine.global. For some reason it's a > bit more stable that way. Don't know why. > > > > > On Tue, Feb 5, 2013 at 9:09 PM, Jeremie Passerin <[email protected]>wrote: > >> It's been a while since I tried to do stuff on kinematics with ICE and I >> thought I would give it another shot. >> >> Just a quick test, I'm using the UV to Location to recreate a surface >> constraint and I plug that in the global kinematics of a null. >> It behaves properly. >> >> Then I go check the Global Kinematics of my null, just to see if they are >> locked or anything. Nope... they don't seem to be locked and I can >> even manipulate them. It's acting crazy though. >> And now my simple ICE setup isn't working properly anymore... instead of >> that I have a null moving all over the place every time I changed a UV >> value. >> >> So first question. Am I doing something wrong ? See attached ice tree >> and then, who's using ICE kinematics in Rigging ? Was it successful ? >> >> Jeremie >> >> >
