PDA

View Full Version : .value constraint property actually doesn't work


phoelix
05-11-2008, 07:03 AM
Hi there.

Sometimes i found this problem quite frustrating. All the constraint controllers expose a wrong .value property, for example the look_at, if you add a lookat constraint to a helper's rotation controller (and append a target) then if you write in the listener $helper.rotation.controller.value as eulerangles, you get a value different from the real helper's rotation (having in mind that controllers rotation values are respect to parents). The others controllers don't have the same problem, their .value property works perfect.

The only way to get the real constraint value is by accessing the whole transform value and the parent's: ($helper.transform*inverse $helper.parent.transform). But the fact is that sometimes i need to acces the position of a node from a script controller in its own rotation (for example make my own look_At with custom behaviors). The only way to do that without falling into a circular dependancy is by using the controller's value, not the .transform.position value, neither the transform controller, neither the node.position value (it has the same problem). If the controller isn't a constraint it doesn't have any problem and the script will work succesfully.

So what do you think guys?, is there a way to get a right .value property from a constraint or it's a bug or a bad design that we have to live with?

phoelix
05-11-2008, 08:03 AM
Well, i noticed that in position controller constraints (position constraint and path constraint) the .value property stops being in respect to parent's transform, so i think i could make a multiplication there to fix the problem.

and about the rotation constraints, specifically the look_at constraint, i don't think never to be able to get its right value, i think because it's dependant to the position too. And if i want to use it inside a script controller in the position of the same node that'll be impossible because circle dependancies.

Ok, so ... nevermind :)

CGTalk Moderation
05-11-2008, 08:03 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.