Rotating an object -90° instead of 270° with constraints in 3ds Max

[Sam_Jay]

Hi all,

I would like to rotate an object and constrain other objects' rotations to that, and play with the weights, e.g. "rotate half as much as the parent object". When I set up everything, I realized the constrained objects suddenly change orientation, although the parent rotates smoothly. Looking more carefully, this happens when the parent object passes 180° rotation. When it is supposed to go to 181°, it shows me -179° instead. So it does not add the angles, it just goes up to 180 and then it goes down in negative. As for the given example: if the parent object rotates to 200° the constrained object should rotate to 100°. But 200° do not exist anymore. 200° has become -160° and the constrained object is now at -80° instead of 100°.

I don't know if that's the case since the last update or with v2024 or earlier, as I didn't rotate this much for a long time. I remember setting key frames for a rotation, then go to like frame 5000 and see the object is rotated a crazy amount of degrees and not stay within the 180° limit.

The main issue is not the orientation constraint, so I don't need a work around there. A lot of things depend on proper counting. So, is there a setting where I can change that behavior? If this has already been solved, I apologize. I didn't know how else to look that up or how else to ask about it.

Cheers,
Sam

*renamed the post for clarity

[leeminardi]

Although the Rotate Transform Type-In may switch from a positive angle to a negative angle when the angle passes 180°, the positive value can be used in a controller but you should keep in mnd that the angle may wind up.

For example, in the case below there are two teapots. When Teapot001 is rotated about its z axis Teapot002 will rotate by half the angle via a scipt controller. 

The controller assumes radians so  a conversion is necessasy.  To demonstrate how the angle builds I added a format statement t print out the anggle (in degrees) and using the modulo function mod, the angle remainder after dividing the angle (in radians) by 2*pi.

At the right is what the Scripting  Listener shows as teapot001 (t1 in the script) is rotated.

[wernienst]

All objects should have the Euler XYZ Rotation Controller assigned.

[Sam_Jay]

Hi there, thank you very much, @leeminardi and @wernienst for the responses!

I actually haven't wrapped my brain around scripting in 20 years of using Max once in a while. I keep using that Motion - Parameters - Assign Controller - Rotation - Orientation Constraint from the menu on the right side. Using that gives me jumping children when the parent rotates smoothly. This Script Controller seems to work pretty well!

I kind of hoped this is just a simple setting somewhere that I missed. I think I won't learn to script to work around a "faulty" annotation of rotation. As I wrote, Max must have changed that. It was possible to simply rotate the object and then see the final angle. Take the wheels of a car for example. The car went 20 miles and the wheels' final angle is -20°. That's not helpful at all. There is probably a workaround and initially a better way to get the info I want, but when I have 100 different examples I would need 100 different solutions just because one thing doesn't work how it should - or how I am used to 😉

I didn't quite get the Euler XYZ Controller thing. Isn't that the standard setting? That said, I haven't worked with Parameter Wiring at all yet. But aside from all the nice possibilities, I'd really like to know why Max doesn't let the angles add up and - more importantly - how can I set it up to do it the old way.

Thanks again!!

Cheers,
Sam

[leeminardi]

@Sam_Jay you have not said how  you are determing that "the wheels' final angle is -20°" and how you are using that result to affect the rotation f another object.  If not through a float script associated with another object or a Wire Parameter then how?

Note,  if you set a keyframe via Autokey at frame 100 after rotating the object 2-3/4 turns (990°) Transform Type-In will indicate an value of -90 and the result will be -1/4 turn.  YOu could edit the keyframe value of -90 to +990 and get the full 2-3/4 turns.

Alternatively, you could assign a TCB Rotation controller to the object and check the box for Rotation Windup.  Then keyframe your rotation.  Note for TCB rotation you'll want to set the tension to 50 to get linear rotations.  TCB rotaton use an axis (which may be skewed in 3D space) and an angle which is always positive.  Reverse directions of rotation are defined by the axis vector changing its direction.  TCB controller are preferred for certain animations which could suffer from gimbal lock if Euler controllers were used.

[Sam_Jay]

Hello @leeminardi , thank you again!

The wheels were just a quick example, that's why I didn't tell more about them. Isn't it illogical to drive forward 50 miles and then see the wheel turned minus 20°instead of a) a positive value and b) a very huge value? Anyway, this was really just an example with which I tried to show the difference between a simple orientation (e.g. 1°) and one that came from a little journey (e.g. 361°= 1°obviously) and the necessity of the latter.

Why would I need this? I actually didn't question that at all because that's how it "naturally" worked last time, ages ago 😉 I built clock prototypes in the past and relied on this "winding up". Thanks for that term, by the way. I'm German and I wouldn't know which was the right one to use. I would really like to solve the issue at the source, not at one example. As much as examples may help to show the problem, they also distract from the original issue. Like trying to fix an error (setting up dozens of things that work in that particular case) instead of avoiding the error (simply allowing winding up in the first place).

So, this TCB Rotation controller seems to do the job. I made a second object that rotates only half as much using an orientation constraint with the main object and the world (so basically nothing) as evenly weighed targets. No jumps there. But that's this example. For any new thing, I'd need a new solution.

[edit] Stupid me built boxes. Quick and effective, right? No. I did not see child box' jump in its rotation because around its z axis it is perfectly symmetric. A sudden 180° turn looks like 0° and 360°. I extruded one face of the box to make it asymmetric, and now I see it jumps - quick 180° turns. So even if I set up the TCB Rotation controller for the first box, it does not pass the ability of winding up to the child box. I'd ask if I can combine Orientation Constraint with TCB Rotation to allow winding up there as well, but I'd rather don't dig this deep of this particular example [end of edit]

So when I set up this TCB controller, I need another window for the rotation, which I would live with, but it seems I need to set up key frames in order to actually type something in there. Maybe I don't want to animate (that's where the example distracts from the main issue). But let's say I want to animate, because often I do. So I set up two frames inside that Controller window. Then I checked the curve editor and there is no graph. Then I scrapped that and used the good old key frame bar (official name may vary) at the bottom of the window. There is also no graph in the curve editor.
I am used to having no key frames in the child object because it does not rotate in its own, but why not in the parent object?  Complex graph behavior of the parent object cannot be done, once I set up a TCB controller? That asked, I'd rather know how rotation can wind up without any further steps that fix one problem, not avoid dozens of problems.

Definitely big thanks again, also for the images and the example file and mainly for your time!!

[leeminardi]

@Sam_Jay I'm glad I was of some help.

You lost me a bit on what you expect to happen especially with the "So even if I set up the TCB Rotation controller for the first box, it does not pass the ability of winding up to the child box" story.  Can you post a file that shows the behavior of what you are getting and describe what you want to happen?

[Sam_Jay]

Yeah, I got a little lost as well 😉

So in the attached file, the dark (left) teapots are the parents, the light (right) ones are the children.

The blue teapot was animated, how I was used to. Press Auto, go to frame 40, rotate close to 360° by hand, then enter 0° in the rotation menu. Rotating by hand defines which way it shall rotate to 360°/0° otherwise how would it know? Entering 360° obviously doesn't help, hence the manual workaround. Anyway, the light blue has an orientation constraint, half the blue teapot, half the world, so it rotates half as fast as the blue teapot. When you slide over the 20th key frame, the light blue teapot jumps from +90° to -90° instead of turning to 91° and further.

The green teapot has a key frame at 10 and is rotated by 90° (so 1/4 of the blue teapot). I set up the rotation to go on (in out-of-range-types). I tried that in my desperation, but it didn't do the trick. The rotation graph (a straight line) goes on and on in the curve editor, but numerically (in the little rotation menu) the rotation angle goes up to 180°, then turns negative and goes down to 0° again and again, just as in the blue teapot.

The red teapot uses the TCB Rotation controller. Although it counts up to 360°, the light red teapot interprets 181° as -179° and thereby has a sudden jump in its rotation. Fun fact: Although I don't see the animation in the curve editor, I can extend the animation and let it go on and on. Once I did it and checked if the menu "Key Info" keeps counting up the angles beyond the 360°. It does not. This is beyond weird.

The brown teapot is set up to rotate 90° at key frame 10 and then continue to rotate. Weirdly the angles here also count up to 360° and then down again.

Ok, once I set all that up, I made the purple teapot. I gave it the TCB controller, went to key frame 80 and rotated it 720°. I did it because I was weirded out by that counting down from 360°. Well its values restart after the 720°, so nothing hopeful to gain from here. Needless to say the light purple teapot behaves like the other light ones.

I just realized, sometimes the rotation jump is at key frame 20, sometimes at 21. I would not try to figure out why because 🙂 that would be fixing something that shouldn't be.

So, verdict: Using the TCB controller has the angles winding up for the parent object. As for the children, any angle above 180° is seen as a negative angle equal to or below 180° and THEN multiplies it with 1/2 and rotates accordingly.

Any non-script help would be nice. I don't give up the hope that this winding-up behavior is just a setting, as I didn't have this issue before. I might check if I find an old 3ds Max on an old laptop and see if it really was how I wrote it. But nevertheless, it wouldn't change the present.

Please beware - I would like to have the parent to rotate properly for any kind of future endeavor. The misbehaving light teapots are just one example, one way of revealing the weird (imho) rotation behavior of the dark teapots. Fixing the light teapots' relation with the dark teapots might not help for the next thing. Anything that helps to make the angles of the dark teapots wind up, will help in the long run.

Thanks for reading!

[leeminardi]

@Sam_Jay 
There are a variety of ways to associate the rotation of one object with another. These include wire parameters, function scripts, transform scripts, and controllers assigned in the motion panel. You used an orientation constrain to the rotation component of the transform for the teapot. It's inappropriate to refer to a child-parent relationship in this case. This is not the technique I would use to control rotation but it could work. Have you tried working with Wire Parameters? This might be the easiest approach but I think you'll need to use TCB controllers to allow for angle wind up.

You state “Rotating by hand defines which way it shall rotate to 360°/0° otherwise how would it know?” Rotating “by hand” has nothing to do with the direction of rotation. In fact, you cannot define the direction of rotation. Keyframe rotation values only store the current angle for a specific axis whether one of the Euclidean axes X, Y, or Z, or the axis associated with the TCB controller. The angle you see in the keyframe dialog is plus or minus the value from the previous keyframe. For euclidean rotation controllers the sign (+ or -) of the angle determines whether it's added or subtracted. For TCB controllers the direction of the unit vector defining the axis specifies the angle difference from the last keyframe.
Have you ever seen a movie of a spoked wheel that appears to be turning backwards? If the wheel rotation from 1 frame to the next frame is 10° in a clockwise direction then a series of 10° changes will appear to make the wheel spin in a clockwise direction. However, give the rotation or 350° for each frame, a series of frames in this case would give the appearance that the wheel was rotating counterclockwise.

Try using Wire Parameters as suggested by @wernienst  with Euclidian rotational controllers and see if that does what you want. If windup is an issue change to TCB controllers.

[wernienst]

Here is another file to play with.

The MASTER teapot performs 3 complete rotations up to frame 60 and then rolls back to 0.

The "Wired to MASTER" teapot is negative wired to MASTER and is rotating in the opposite direction.

The second teapot (top row) is constrained to MASTER and copies its rotation. The third teapot is constrained to both MASTER and "Wired to MASTER" via Target List and doesn't rotate (as expected) but changes orientation several times.

And the teapot down right is also wired to those via a Rotation List Controller. It also doesn't rotate as expected but gets mad when altering the weight values.

In conclusion, IMHO Parameter Wiring is best for simple relations.

I've also tried TCB and Smooth Rotation instead of Euler XYZ Controllers with mixed results.

Finally, I created this file in Old Max 2013 just to show that there is no change in behavior when loaded into Max 2024.

Have fun!

[Sam_Jay]

@leeminardi , thank you for taking your time, especially as this seems to be a noob topic - "The basics of rotation in 3ds Max" xD

I suspected there to be a couple of alternatives. It's great about Max or other programs that you can achieve a goal in different ways, just by logically combining methods (even if it's the own logic).

I which way is "parent-child" inappropriate? Logically, technically or in terms of political correctness?

I haven't tried more things, as I felt the original problem is that the angles are not winding up. And I am completely out of scripting. Good, when people can do that, but I suck at this and coding. Just spin, not write a novel to make it spin, hehe 😉

Before I knew about the TCB controller I animated a rotation this way: I went to a frame, say 60, hit "Auto", then manually rotated the object almost 360°in the direction I needed (CW or CCW), then entered 0°, unhit "Auto", done. Apparently my mistake was entering the number in the absolute rotation (left side) not the relative rotation (right side). Entering the absolute of 360° makes Max think, the object didn't turn. That's a bit counterintuitive. Ok, so I need to enter the relative value. But what If I only know the final rotation, not the one how to get there? Say, the object is a 93.3378° and should go to 360°. I don't want to calculate that. Of course, I enter the 360° on the absolute side. But then Max doesn't know how to get there (CW or CCW) and - in this particular case - chooses the shortest way, going from 93.3378° to 0°directly. Entering -360° does not help here. So, absolute values are a big no no, obviously. In this particular case, I need to enter another 360° on the relative side, to make the object spin who I want. So neither the manual method nor the one with more typing is perfect.

Yeah, let's not talk about how a rotation would appear 😉 Truth first, illusion later. I just want the wheel to be at angle 360.000° after 1000 turns, not 0°, which tells me nothing about its journey. If the straight line in the curve editor goes on just like that (showing me the rotation of the object around its z axis) why don't the values in the little rotation menu which show me the object's individual rotation, only the current orientation? Again, counterintuitive but, of course, one could get used to it... especially with all these suggested methods.

I guess I need to learn that wiring stuff and/or dealing with how the TCB controller works. It's just weird that the continuous rotation of object #1 is translated into a jumpy one of object #2 and that this needs fixing. No one thinks the half of 270° is -45°.

So why are my TCB controlled animations not visible in the curve editor? I'd like to edit the tangents and tweak stuff. That little graph made of + signs in the controller menu can't be it...

Thanks again for your input!!

[Sam_Jay]

@wenienst , thanks a bunch for creating this file!

Alright, I see that the orientation constraint doesn't do what I want, and I just stumbled across it with the rotation example. Looks like it took me a while to finally see its flaws 😉 Still thinking the initial flaw is the not winding up of angles in the simple rotation menu, but I am getting accustomed to the feeling that this is my personal preference, thanks to you and @leeminardi . I can see why it isn't that way in the first place.

The wiring of parameters seems to do the job. As for sucking at coding, I think it'll be worth learning about what possible expressions I can use to wire. Seems to be less complicated that scripting.

This parameter wiring reminds me of another issue I had a while ago where I had to enter a parameter again and again like "width of object A should be Shell amount of object B" and now I believe such things can be done with parameter wiring. But that's something for another day.

So can I use the same parameter for multiple wirings? Let's say object #2 rotates half as much as object #1. Object number #3 should rotate half as much as object #2. And then object #4 should rotate half as much as object #3 and so on. So, inherited behavior if you will. Let's now say I don't want it to be half, but a third. Is there a way I can set up this parameter in one place for object #1, #2 and #3 and all those that might come? Is that possible with parameter wiring or does it already require scripting?

Thanks again for the help! Made me understand Max better 🙂

[leeminardi]

@Sam_Jay 

You asked "I[n] which way is "parent-child" inappropriate? Logically, technically or in terms of political correctness?"

Looking at the properties off both objects in your file you would see that their parent object is root.  Therefore neither object is technically a child of the other.

You may think of an object as rotating in one direction of another but in fact the object is not rotating at all!  It just appears to you to be rotating due to seeig an object at different orientations from frame to frame.  As an analogy, think of an old fashion analog clock.  All the hands rotate in a clockwise direction.  Now consider a digital clock that is trying to look like an analog clock (e.g., a Apple watch).  The second hand on it may appear to be rotating but  what you are seeing is a sequence of lines (that have been rasterized) in different positions that give the appearance of rotating.  Nothing is in fact "rotating".

When keyframing rotations you can specify an absolute angle or, via the transform type-in, a relative angle.

As an example,  using Autokey set a 60° rotation for a teapot at frame 20.  You will have,

Now move the time slider to frame 10 and hit Ste Key (or k), and you will add a key at frame 10 of 30°.  The absolute value of 60 will remain at frame 20. My error if I said it would be relative.  Entering an absolute angle is not an error.  Sorry to imply otherwise. Note, you mention "the straight line in the curve editor".  Its purpose is to show how the tween frames should be calcuated based on the previous and subsequent key frames.  If you enter an angle of 1080 in frame 100 for an object that has an angle of 0 in frame zero the object will appear to make 3 complete revolutions in the positive (right-hand-rule) direction.

Since @wernienst is offline at the moment I hope he doesn't mind me answering your question "So can I use the same parameter for multiple wirings?".  The short answer is Yes.   You have a couple of options the choice of which depends on how you think you may want to change the rules later.  For example, you could:

Option A

Object #2 references the angle of #1, Object #3 references the angle of #2, etc.

Option B

Object #2 references the angle of #1, Object #3 references the angle of #1, etc.

With Option A you do not directly edit the relationship between #1 and #3.  You must edit #2's as well.  With opton B, Object #3's angle relative to #1 will not be affected by changes in the wiring equation between #1 and #2. 

[Sam_Jay]

@leeminardi
Thanks for the clarification!

I see. Good analogy with the digital watch face. A water wave is similar. It looks like the water is coming at you, but in fact it's just moving up and down (ok at the beach it is REALLY getting you).

I understood these two wiring options. I bet it can get pretty complex when you combine parameters. That'll be fun, once I played with that!

Actually, I did the example you described. Entering the 1080 as absolute value at the end made the object rotate -60° (from 60 to 0). When I enter the 1080 as relative value, it ends up at 60°, but between time 20 and 100 it spins 3 times. That said, I mean the little menu coming from right-clicking the rotation button. Now with the little menu you can summon from the key frame, the one you show in your message, you can indeed enter time 100 and value 1080 and the object spins wildly.

Writing all these messages down makes it look like a bigger topic. Usually I just do, fail, do again, fail more, do once more and succeed. Same with the next ten steps. So at least I am sensitive about entering values in places now. Trial and error remains part of any project.

Thanks once more 🙂