[Closed] Negative scale does not work

Multiplying just the x ($.scale.x *= -.5) flips the other axes as well. scale $ [-0.5,0.5,0.25] does work as expected.

I guess there’s a reason for this to happen, but I don’t know it

Cheers,
Martijn

Not completely actually. Check this out (thanks to zeboxx for the code)

$.scale = [2,1,1]
Result: [2,1,1]
$.scale
Result: [2,1,1]
scale $ [-1,1,1]
Result: OK
$.scale
Result: [-2,-1,-1]

But if you look at the object in the viewport or in the Transform Typein, it’s correct. So using that method messes up maxscript’s view of the object’s true scale.

• Neil

Interesting.

box isSelected:true
$Box:Box01 @ [0.000000,0.000000,0.000000]
scale $ [-.5, 1, 1]
OK
$.scale
[-0.5,-1,-1]
$.transform.scale
[0.5,1,1]
$.scale.controller
Controller:Bezier_Scale
$.scale.controller = scalexyz()
Controller:ScaleXYZ
$.scale.controller[1].value
-50.0
$.scale.controller[2].value
100.0
$.scale.controller[3].value
100.0

rotation ans scale are mixed, and when you rotate an object like this :
$.rotation

it rotates using the world coordinate system
then :

$.rotation.controller.value

or
$.rotaion * inverse (transmatrix $.pos)

$.transform = ( ((scaleMatrix [-.5,1,1])*(scaleMatrix $.scale)) *($.rotation as matrix3) ) * (transMatrix $.pos)

or something like that

Yep, keep in mind MAXScript DERIVES the .pos, .rotation and .scale properties based on the transformation matrix of the node, which on the other hand is described by the transform controller and its sub-controllers (if PRS) that store the data in PARENT space. So if you want to know the real values of scaling or rotation in parent space, you have to grab them from the controllers.
The node TM (.transform) shows completely different values in its rotationpart and scalepart because that’s how the maths work – the scalepart is always positive, while the quat describing the rotation is different. The final result is the same, but you cannot make assumptions about how the object was scaled and rotated based on them, because there are multiple possible Euler Angle rotations and Scale values that lead to the SAME Quaternion, but exactly one Quaternion describing an orientation in space (which is the reason Max uses Quats internally).
That’s why MAXScript cannot tell you exactly what was scaled and what was rotated based on the final matrix (.scale and .rotation attempt to do just that) – you have to go to the SOURCE data in the controllers and peek inside to know what led to the final transformation values, and possibly take into account the transforms of all parents (if any). The .scale property notifies you that there was some negative scaling going on, but cannot tell you which axis exactly – it just tells you one or more axes have negative length.

Of course, one should NEVER scale negatively in Max, but that’s another story.

Thanks for the explanation Bobo, even though 99% of that went right over my head. I should not be allowed to make scripts

Do you believe the way the transforms are handled in max are messed up? Or is the problem so complex that you need something contorted in order to do the job?

Alas, it’s the only way to mirror an object without messing with the modifier stack. But I understand fully the consequences of that action, and the horrible things it can do to the normals.

• Neil

LOL! To quote a friend of yours, “Anyone can cook” Or better, “Anyone can script”.

Do you believe the way the transforms are handled in max are messed up? Or is the problem so complex that you need something contorted in order to do the job?

There might be some decisions at different levels that make things more complicated than they are already (just read the “Using Node Transforms” topic in the Help which was written by people who know more than I do), but the maths behind orientations in space, esp. the ROTATIONS are indeed complex matter and I try to stay away from them when possible. After all, I don’t have a PhD in mathematics and I don’t want one!

Hehe, I’m living proof of that. The only saving grace I have is I use the scripts that I produce in production, which tend to lead to more useful and user friendly tools. My scripts certainly won’t win any cleanliness or coding style awards

Yes, I avoid rotations at all costs. But I didn’t realize scales were sorta complex as well, at least when you try and go negative. Now I know, and as a friend of mine also once said, “knowing is half the battle”.

• Neil

Neil, it is more then just normals that get it inverted. It is also the transform matrix. If you try to align a right handed matrix and a left handed one you can’t, one axis will always be wrong. Scale values are tied into rotations for a couple of reasons, one being they share the same set of numbers in the matrix that does all the final hierarchy math, second they are local to the object so when it is rotated this is rotating the scale values. Realy this is the same as the first reason. So scale affects rotation as much as rotation affects scale.

I don’t think that Max is all that different from other packages in the way the math is done, how ever I think that in other packages there are other layers of matrixs that handle the different transforms. In Max there are really two, the objectTransform and the transform, in Maya I believe there are several layers and one that just handles the scale. For this reason the scale doesn’t affect the rotations as much.