I found an old thread pertaining to my problem, but with no answer. Simply having a position constraint seems to change how maxscript views the numbers.
Why does a position constraint ruin maxscript’s position values, and if there isn’t a workaround, then is there any alternative?
My hunch is that as constraints work in parent space, it is essentially passing the inverse of the targets transform respective of the nodes parent.
Does the node have a parent?
If not then doing $.pos should give you the object world space position.
Hey eek I’m just curious about this - does $.pos ALWAYS give the position in world space? I got in the habit years ago of always using the ‘in coordsys world’ syntax before getting anything but wonder if this is overkill if I’m wanting world…
Matt, you are correct, by default the worldspace is in world. “in coordsys world” is unnecessary code, unless you want to use it to override a different coordsys view.
Eek, I’m afraid the node does have a parent, and the bone it has a position constraint on. That might explain our different results, because $.pos in world space can still be messed up, although I am primarily aiming to get the parent view.
Perhaps Link constraints might be a different story?
I don’t have an explanation for this beavior but here’s the workaround I use:
Instead of $.pos, you can use $.controller.value.pos
Sorry for the late reply - Previously i should of said $.pos.controller.value
Generally calling $.pos will return its position in world space - crucially .pos can be queried and set. Where as $.transform.pos - although returning the same value is not settable.
Here is the ‘basic’ assumptions:
$.pos - can be assumed to return the objects position in world space it can be queried/set
$.transform.pos - ALWAYS returns the objects transform in world space. It can only be queried.
$.pos.controller.value - Returns the total value of the objects position in parent space. Controllers work in local space…generally…
Now what breaks this:
Position/Orientation basically do the inverse - i.e the parent space multiplied by the objects world space transform. If it has a parent calling $.pos will return the objects parents space relative to the world multiplied by the its current world space transform.
In coordsys context wont apply, so to get the objects ‘actual’ world transform you should call $.transform.pos. Else you could do some complex math like so:
$.pos = (inverse (transMatrix $a.parent.transform.pos) * (transMatrix $a.pos)).pos
My hunch is the relative offset may be easier to store… not sure.
Both of you are right, $.pos.controller.value and $.controller.value.pos give the total value that you see in Max, as opposed to initial values from $.transform.pos and $.pos values. Thinking of them as factors or layers that affect each other makes it much easier to understand.
Now to get in the habit of using the right value. Thanks for helping me out!
EDIT: A useful thing to know, pos.controller.value is in world view, while controller.value.pos is in parent view. But position seems to be a different case from rotation and scale, still a little off.
$.pos $.rotation and $.scale are special cases, obscure, maybe MAX old stuff…
$.pos returns the original position of the object in parent space, before the constraint was applied(the initial offset against the parent), if the constraint is removed, this initial offset stops being overriden…
to return the pos in parent space == $.inode.posInParent
…constraints use world space.
all controllers are in parent space, but because some use world space for it’s math, they return a value in world space overriding the parent space
.
$.inode.posInParent, $.inode.rotInParent (also $.inode.OrientInParent), and $.inode.scaleInParent pull up the correct parent values, even when constraints and frozen positions are involved. These functions apparantely have next-to-no Google search results, not even shown in the manual, what a shame.
Anyways, I can’t think of any way to delve further on this subject, unless these functions fail or if anyone is looking for non-parent values. Thanks again.
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.