Transformation Constraint
Closed, InvalidPublic


Grab the Empty named Source (shaped like a Cube) 2.5 meters along X axis. Empty named Destination is properly rotated (like in Transformation Constraint - ranging from 0 to 2.5 rotates Destination -45 Degrees. Here all the fun begins, grab the Empty named Source again 2.5 meters along X axis and look wthat's happening. Empty named Destination should move 1 meter along Local Z axis as set in Transformation Constraint (Space Local Space <-> Local Space). As you can see Empty named Destination move 1 meter in Global Space instead of Local.

Voyager Voyager (voyagercgi) added a comment.Via Old WorldDec 28 2012, 2:19 PM


Windows 7 x64


Revision: r53352%%%

Bastien Montagne (mont29) added a comment.Via Old WorldDec 28 2012, 3:09 PM

Imho, this is not a bug, this is how constraints work (all constraints, not only Transformation one): they are always evaluated based on original (unconstrained) object's space – even though this might look un-intuitive…

Assigning to Joshua to see what he says about it. ;)

Voyager Voyager (voyagercgi) added a comment.Via Old WorldDec 28 2012, 3:38 PM

Truly speaking, there are many other ways to do it but it would be nice to have it properly working. It's IMHO most flexible and particuraly fast way in this situation.

Ton Roosendaal (ton) added a comment.Via Old WorldDec 29 2012, 10:34 AM

I'm not sure why "map to local" wouldn't use the constrainted previous state into account. Multiple constraints on top of each other should work like presented here...

Joshua Leung (aligorith) added a comment.Via Old WorldJan 2 2013, 2:57 AM

Ton is right. All constraints always use the result of the previous constraints, and map these transforms into the relevant spaces.

Hence, in this case, we're really looking at how "local space" is defined for objects.
* If there is a parent, we just remove the parent influence. That should now be "local" as in relative to parent.
* With no parent: Because object's don't have a "rest pose" that we can simply use as the baseline to remove from the transforms, we remove the rotation specified by the user via rotation properties (which get set using transform tools and/or buttons). This is used instead of all the rotations currently present (from previous constraints in stack) so that there's still some rotation component left to play with for some of the other constraints (e.g. for limit rotation or so, which would be completely useless).

What this case shows though is that users in some cases do want to be able to have it just take out all rotations.

Joshua Leung (aligorith) added a comment.Via Old WorldJan 28 2013, 6:47 AM

Closing. This is not really a bug.

Joshua Leung (aligorith) closed this task as "Invalid".Via Old WorldJan 28 2013, 6:48 AM

Add Comment