Rotation @##$!#! problems!

[tAstyBITs]

I hope the people from Discreet are reading this.


:annoyed:

[LFShade]

Well, as I said, it's not just a Max problem. But let's hope they're reading it anyway;)

Incidentally, this only occurs with Euler controllers (as far as I am aware), and the stupid workaround is to change the axis order to ZYX. Figured I better mention that before the vultures start circling...

[ryankittleson]

I feel your pain :surprised

I don't have a solution for you, but I do have a related question. I'm just starting animation on a character and find big problems with the TCB controller. if you rearrange keys or add keys between keys, the rotation goes wacky. Does anyone know a way around this? I would use euler, but 3 keys per rotation just adds a lot of work. what about the Smooth controller? has anyone found that you can create good animation without the ease in/out control?

[Reality3D]

brainbutter, which version of max are you using, 4.0?. I think it was a known bug and that was adressed in 4.2 or similar

[ryankittleson]

i'm using 4.2 should I upgrate to 4.26?

[AJ]

Now grab the Z-axis handle in the viewport, start rotating, and watch in bewilderment as the transform type-in dialog shows the rotation happening ON THE F***ING Y-AXIS

Just to check... the axis you are rotating in the viewport corresponds to world axis (the one in the bottom left of each viewport)?

Because objects have their own rotation axis, which isn't always in the same order as the World axis. So depending on what view you are in, the axis handle you are using to rotate may actually be different to the World axis.

This comes from the classic layout of "Y = Up, X = Side, Z = 3rd dimension" - hence not being able to move objects 'towards you' in an orthagraphic view with the Transform gizmo.

Max automatically set the axis to the classic "Y-up" settings even if you're not in the front viewport. So even though you are moving in 'X and Y' you are in fact moving in the World axis in Z and X.

I'm not sure if this is really the problem you were stating - and as I'm sure you know it gets far more complicated when you take into account Local/Parent transforms...

Rotation - it's a pain in the arse. :annoyed:

[Reality3D]

Originally posted by brainbutter
i'm using 4.2 should I upgrate to 4.26?
Check this:

In 3ds max 4.0 the TCB controller was enhanced with the capability of performing quaternion rotations of greater than 180 degrees. This enhancement allows objects to be “wound up” interactively in the viewports. This enhancement produces a side effect when editing rotation keys in the timeline or in Track View. As a general rule, a quaternion rotation takes the shortest path between rotation poses. However, when editing TCB rotation keys via Delete, Cut and Paste, or Drag and Drop, or if keyframes are added in the middle of existing keyframes, the animation near the edited keys may rotate opposite to its original direction. That is to say it takes the long way around to arrive at the same pose at the next keyframe. If this is undesirable there are several remedies:



If Continuous Rotation (where keyframes are greater then 180 deg) is important:

· Consider assigning the new EulerXYZ controller, which now fully supports continuous rotation. Existing TCB poses will successfully translate into the EulerXYZ controller.




· Find offending keyframes (ones where the object has spun the “wrong way around” to the current pose) and edit them interactively in a viewport by rotating the object around the opposite way so that it spins in the “correct” direction.

· Viewing the trajectory of objects linked (parented) to the rotating object may be helpful when interactively editing these keyframes

[ilasolomon]

i did what you said:
made a teapot
rotate Y -90 in type-in box
grab Z axis & rotate 45
the type-in box showed 90 in X & Z axises
& -45 in Y

"who's responsible for this mess?! (©half-life)"

[LFShade]

Just to check... the axis you are rotating in the viewport corresponds to world axis (the one in the bottom left of each viewport)?

Because objects have their own rotation axis, which isn't always in the same order as the World axis. So depending on what view you are in, the axis handle you are using to rotate may actually be different to the World axis.
That's why I said "switch to rotate mode, local axis".

Note to brainbutter: for character animation, I'd seriously recommend using Euler rotation controllers. It takes a bit more work to edit the axes' curves, but once you've gained the experience you'll find you have much more control over the look of your animation than with TCB.

[AJ]

You misunderstand...

Try this,

Create an object, a box for example. Under the Utilities panel, go to Reset XForm - select the box and the press Reset Selected. This will allign the transform Gizmo to the World Coords. Now rotate it and look at the axis information...

This is what I meant, the object is rotating correctly around the World Axis - it's just that the transform gizmo is showing you the Axis in relation to the classic "Y=up" layout. That's why the letter o nthe handle changes in an orthagraphic view to perspective... and so forth.

Hope this makes sense.

[LFShade]

AJ_23:

I don't know what the heck you're talking about. An object has a local coordinate system. The world has its own coordinate system. In Max Z is up, not Y. World transforms in Max do not occur based on the Y-up configuration of other packages. The transform gizmo's absolute orientation does not change from ortho to perspective views, it does display differently whether you're operating in world or local coordinate space. No matter what your viewpoint, the axis labelled Z always corresponds to the Z-axis, either of your objects local coordinate system or the world coordinate system, depending on the mode you're working in. When you use the "reset xform" utility, you're aligning the local coordinate system to the world coordinate system, but this does not change the behavior of the gizmo, only the orientation. When you grab an axis handle and start rotating/translating/scaling, it is (supposed to be) occuring on that handle's axis, period.

I'm not trying to be harsh; I just don't understand what you're getting at. Are you trying to say that when you rotate on Z in local mode, the rotation appears different in world coordinates? Because that's a fundamental concept of which I'm aware, but it has nothing to do with what I'm talking about. Explain further.

Thank you.

[AJ]

Whoa! :surprised

My point was simply this.

As you put - in Max "Z is up"... however when you create an object - say a sphere in the top view - and the select it in the front viewport of Max, you'll notice that the Transform gizmo diplays "Y as up", this is the 'classic' XYZ formation I was reffering to. If you select the object in the top view port - this axis are the same, Y being 'up' (in that view) as it were, yet that is clearly not the same direction as in the front viewport.

When you grab an axis handle and start rotating/translating/scaling, it is (supposed to be) occuring on that handle's axis, period.

Is is rotating on that handles axis, however that axis is representing a different world coordinate altogether. Otherwise having the Move tool locked to XY would not move the object left/right in all the orthagraphic views (as it does).

So the information in the Rotation dialog is not incorrect, it's simply showing the objects translation in the World axis (the constant).

My point about resetting Xform was simply to show that if you strip away the 'classic' transform layout (y=up) you are in fact rotating the same handle, only the letter on that handle now corresponds to it's World conterpart.

Hope this makes it clear what I'm trying to say....

I was trying to point out that your example of creating an object and rotating about it's Y axis and the Rotation Dialog showing a change in the Z axis is because you have rotated that object in the World's Z axis... if you switched to the top view and rotated the object in the Y axis in that view it would not be the same Axis as you rotated before. Of course, this changes (somewhat) with Local settings, and I'm making no excuses, Max's handling of rotation is poor at best - but I'm simply saying that the reason it displays a change in the Z axis is because that is the constant... Max (by default) displays Y as up, even though that is not the case in the World Coords.

Phew, don't know if any of that rambling made sense!

[LFShade]

O.K., I see what you're saying, but now you need to try a little harder to understand precisely what I was ranting about. Follow the steps I outlined, then animate the object with some rotation on local Z using the gizmo. Then poke around in track view and observe that all that Z rotation you applied shows up in the Y channel. Then try some parameter wiring using the Z rotation of this object to drive the Z rotation of another object, and watch in amazement as you rotate the 'driver' on local Z, but the other object does nothing! Then rotate the 'driver' on local Y and watch the other object spin!

After you've played around a bit and seen for yourself what I was talking about, you'll understand that I'm not simply confusing world, screen, and local coordinate systems. I didn't make this up out of my own ignorance, and I'm not confused by it at all. It's a known behavior of Euler rotation, and I was simply saying that it frustrates me. That's all!

Incidentally, it would be nice if ZYX could be set as the default axis-order for Eulers, so that I don't have to remember to change it every time I create one of the many objects that constitute a character rig.

[Martyr]

Hi, i have a litle question it is possible than Brazil have some trouble with high-poly render with raytrace... My model is only 9100 polys and the raytrace cause my max crash, I had tried a very low scene(a plane and a cube) and its working...Why ?

[toonman]

Let me try to take a shot at this one. The phenomenon you're seeing comes from the fact that Euler controllers work based on the order of the rotation axis. This order is set in the motion panel. This is kinda hard to explain, but basically, the axis order determines which axis is evaluated first. The default axis order for Euler controllers is XYZ|. You can change it to ZYX for a more 'local euler' behavior. As a side note here, true local controllers cannot exist because of mathematical implications. The local coordinate system is just inteded to be that, a reference coordinate system. Rotations are evaluated in parent space. When you link one object to another one, the child's rotations get 'zeroed'. However, if both objects are not aligned, you get a staring offset to deal with. This can make matters a bit more obscure. Objects that have no parent, are, of course, children of the world. Since most objects in this scenario are rarely aligned to the world, these offsets are very easy to come by.
I hope this explains things a bit. This is part of the nature of Euler controllers, but I wouldn't dare to live without them... it's just a matter of careful alignment, and some forethought when starting a project. Cheers!

[CGTalk Moderation]

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.