Hi folks,
I’ve been out of MaxScripting for a while, but now I’m back it’s all very exciting again! However, there are a few things that I’ve forgotten / was vague on in the first place.
One of them is matrices and setting rotations.
Is anyone in a position to explain to me why when you set a rotation value directly on an object (without using its contoller) it can suddenly jump in position elsewhere?
And, importantly, how to overcome this.
I seem to remember having to extract the rotation part of the matrix, edit, and re-apply. However, my calculations at the time were mainly based on trust, and not full-understanding!
Thanks,
Dave
i’ve often wondered this myself so I played around with some ideas and came up with this:
(
-- create teapot with random pos on xy plane
t = teapot pos:[(random 0 100),(random 0 100),0]
-- create a rotation matrix for the desired rotation
rotMatrix = ((eulerangles 0 30 0) as quat) as matrix3
-- create a new matrix from the scale and position of the old matrix
tm = scalematrix t.transform.scalepart
tm.pos = t.transform.pos
-- assign the newly rotated matrix to the teapot
t.transform = rotMatrix * tm -- rotation matrix MUST be the first term
)
as you can see from my comment on the last line, the rotation matrix MUST be the first term (ie. rotMatrix * tm NOT tm * rotMatrix) otherwise the object will be moved for reasons unknown to me.
I still have no idea why using the .rotation property moves the object though.
If anyone knows a better way to set an object’s rotation, i’d be quite interested
I just thought I’d put this post back on the first page for a bit.
Thanks Joel for your input. Yeah, I also set position last to “reset” the object, but I hate doing things when I don’t know the reasons behind the correct results.
I have a suspicioon that it’s something to do with the offset from [0,0,0], as I learned in another thread recently that rotation affects position intrinsically (ie, if you rotate your elbow, your hand moves position quite wildly).
Some theory / maths (even links) on the subject would be great though. It’s one of those 3D conundrums that I’ve been shrugging my shoudlers to for years (and I hate doing that!).
Thanks,
Dave
Accessing rotation by $obj.rotation (or as quat) is very dependant on the orientation (forth) component of the quat value i.e. (quat 0 0 0 1) so when assigning a ew value as quat it will very likely change the position also. The best way, as far as I’ve found, to overcome this is to access the individiual x,y,z parts like this:
$.rotation
(quat 0 0 0.684356 0.729148)
$.rotation.z
0.684356
[color=#fffffe]$.rotation.z_rotation
86.37[/color]
in other words the second row returns the angle as radians which is quite a pain in the a***, so the third row returns the angle in degree, which is the most suitable IMHO 🙂
hi dave,
the reason when you set the rotation directly with rotate you are setting in a coordinate system context of world… easily solved…
in coordsys local $.rotation = (eulerangels 0 90 90)
it just so happens that the default coordinate system (the point you rotate about) is world
mark
Thanks chaps.
Sadly I’m not on max for the next few weeks, but I’ll jump in and test again as soon as I get a chance.
Cheers!
Dave