Problem With Quaternion Rotation Causing Random And Abnormal Motion

[jtburns]

First off I want to thank JooJaa for replying to my previous post Help Needed With Animating A Rubik, a simple way. This got me pointed back in the right direction and was extremely helpful.

However I have run into some more problems....

My new set of problems revolves around some abnormal motion when using Quaternion rotation as the default for animating the cubes 90 degree rotations. The problem occurs after I have rotated and keyed a set of blocks (side A key 1), rotated an adjacent side (side B key 2) and then keyed the original side (side A key 3) initially for another rotation so the blocks do not go out of sync. So the rotational values of the blocks of side A, that were not constant between sides A and B, have remained constant(In other words the values for the angular rotation have not change for the blocks that were not rotated with side B from key frame 1 to key frame 3). When this happens there is a good chance that one or all of these blocks will exert strange motion that is random and abnormal. Upon examination of the graph editor the subsequent curves, related to the effective blocks, look as if someone has taken a pen and scribbled over the graph. After reading through the documentation on rotational interpolation on both Euler and Quaternion I discovered that there are inherent difficulties in interpreting the graph of Quaternion rotation, however, I do not believe this phenomenon to be normal behavior.....

I did, however, discover a work around for this abnormality in the rotation. Whenever I encountered this, what I believe to be an error in the calculated rotation curve, I simply applied Euler interpolation to the whole graph for the whole cube (all 27 block) and then reapplied Quaternion interpolation forcing Maya to recalculate the curves. This method seems to work but I am growing concerned about the affects of this fix over the long-term....

On my first attempt using the method suggested by JooJaa, and my work around for the abnormality, I encountered a point where the angular measures for the rotation angles were no longer whole number values. I can't say with any certainty what caused this behavior because I had the rotation tool set to 15 degree whole number increments. It was my assumption that the rotation angles would always be whole numbers if I increment in 15 degree steps but after several increments the rotation channels showed some of the angles as other than whole number values. It seemed to me that the problem of angle creep intensified the more times I rotated any one of the sides of the cube. It seems to me that at the points where I keyed the animation the rotation channels should show angles that are integer values of 90 degrees exactly, but that's not what is happening. I'm concerned that the converting back and fourth between Euler interpolation and Quaternion interpolation, to fix the weird behavior problem for the animation, may be causing the angle creep. Is this problem always associated with converting back and forth between Euler interpolation and Quaternion interpolation? Or is this angle creep expected to happen even if you don't recalculate between Euler interpolation and Quaternion interpolation? Either way is there any way to fix this problem so that at the end of an animation that requires many rotations the rotation channels will show angles that are integer values of 90 degrees exactly?

[jtburns]

....::::EDIT::::....

After reading through my post again I discovered a portion of my explanation that may have been a little unclear. I have edited my original post to include the following

The problem occurs after I have rotated and keyed a set of blocks (side A key 1), rotated an adjacent side (side B key 2) and then keyed the original side (side A key 3) initially for another rotation so the blocks do not go out of sync. So the rotational values of the blocks of side A, that were not constant between sides A and B, have remained constant (In other words the values for the angular rotation have not change for the blocks that were not rotated with side B from key frame 1 to key frame 3).

[joojaa]

Yes i told you this si VERY error prone. This is why we prefeer to use mel. its just less work.

Thing is you must at all times ensure that ALL teh cubs are keyed at one time so every time you rotate something you MUST esure all the other ones are keyed to stay the same. even if they didnt move. Reason:

Each cube need to start rotating at the same time otherwise the others may arrive there earlier. This is a bit tedious to fix afterwards by hand, but can be done if you know where all the keyed points are. go to the previous turn. hold k down then mmb scrub to that point and key all nonkeyed cubes. repeat for all gaps.

I did point thuis out. But yes every time we have this practice and i point it out underline it on the chalcbboard 90% of the students do get exactly in this pickle. Only 1% do it right first go (and learn nothing ), and only 9% can fix it after the fact, becase they go ahaa. Rst must be manually pointed to this.

So before you animate select all the cubes and choose [animation]character ->create character set. Then let the dropdown next to autokey be set to character now when you hit the "s" key it will make sure you go right.