belt drive (gears?) / rotation problem

[kampffmeyer]

Hey guys,
as a today's ICE-learning exercise I tried to control a object's rotation with another object, in connection to it's size. Think of a belt drive, the smaller cylinder would have to rotate much faster.
I tried to translate the mathematic formular into ICE.
So depending on the diameter of the first cylinder, the second rotates accordingly.
This works great if cylinder 1 has diameter=1, cylinder 2 has diameter=2

If cylinder2 is any different (in this case I chose 1.7), cylinder1 will flip at one point from a negative to a positive value. Very strange! What did I do wrong?

Thanks for your help!

[grahamef]

There's nothing wrong. A rotation of 287.4274 is the same as -72.5726 and the same as -432.5726 and the same as -792.5726 etc. You run into this whenever dealing with angles and especially when converting rotations between Euler, axis+angle, matrix, and quaternion representations.

For straightforward keyframe animation you can turn on the "Euler Filter" option (previously known as "Make Rotations Continuous"). However for ICE kinematics, you'll need to do some more work if you want proper motion blur.

[kampffmeyer]

Hey grahamef,
thanks for the reply.
I wouldn't mind the motion blur, but what bothers me is the flipping of the smaller gear. How could I avoid this, please? It doesn't flip like 360° (that would be ok!) but 180° and THIS you might see, e.g. if it was a gear with odd-numbered teeth.

Thanks!

Wolfram

[Daniel Brassard]

Just some thoughts! You could force the values in your animation in several ways:

a. Input the frame value or a frame node multiply by an angle to feed the rotation angles
b. Use an absolute node to force the angles to always be positive (or negative if you multiply the absolute value by -1)

[kampffmeyer]

Thanks for your tip, Daniel!
When I insert an Absolute Value, the small gear is ping-ponging back and forth.
I noticed that "Matrix to SRT" is giving only positive values. Rotations are going from 0 to 180 and then BACK DOWN to 0! So there seems to be the problem. That's why it is eithe ping-ponging or flipping when the bigger gear reaches 180 degrees.
How would I find a workaround? Any ideas?

Wolfram

[Daniel Brassard]

Euler angle flipping is a common problem encounter in animation (knee flipping, gimble lock).

Have you tried quaternion rotation?

http://en.wikipedia.org/wiki/Quaternion ... l_rotation

[TwinSnakes007]

Basically, you calculate a unit of rotation based on the respective radius of the circular object.

1 Unit of Rotation = 360 / Circumference

Circumference = Pi * Radius * 2 OR Pi * Diameter

So, when building your Rotation, the Angle you would normally supply for the Rotation component, is now multiplied by the Unit of Rotation and then supplied to the SRT Matrix.

Because the Circumference & Unit of Rotation is calculated, even if the size of the objects change, their rotation will still be relative.

I'm at work so I cant post an ICE Tree but, search YouTube for: "Softimage Translation to Rotation Part 2". You should be able to piece together a tree from that.

[grahamef]

Thanks for your tip, Daniel!
When I insert an Absolute Value, the small gear is ping-ponging back and forth.
I noticed that "Matrix to SRT" is giving only positive values. Rotations are going from 0 to 180 and then BACK DOWN to 0! So there seems to be the problem. That's why it is eithe ping-ponging or flipping when the bigger gear reaches 180 degrees.
How would I find a workaround? Any ideas?

Wolfram

OK, I see what you mean. However I think the values are still OK, because you should see the axis change at the same time. A rotation of X degrees about (0, 0, 1) is the same as a rotation of (360 - X) about (0, 0, -1).

Are you just concerned about the number values, or do you see real problems with the motion?

[dwigfor]

This sounds similar to a problem I've been trying to figure out. I'm trying to rig a mechanical object's spine. 3 objects make up each joint. One objects only rotates around local X, the next rotates around local y, and the last rotates around local z. So I tried creating a null and using it's local Rotation to Euler to feed it into the other object's Axis and Angle to Rotation.

I found that if I rotate the null around in the viewport, I get all kinds of crazy values. I think first I could rotate X, then Y and it was fine. As soon as I rotated Z, it'd work fine, and then flip to really weird numbers. If I keyframed the nulls rotation (rather than dragging around in viewport), it appeared to be okay....

I'm now trying a different technique (I think I use arcSin to calculate X, then then Direction To Rotation to calculate the Y and Z) and finally got correct angles, but haven't tested it enough to see if it flipped. Trying to get my tree working with an array of points....

[TwinSnakes007]

Am I missing something obvious...because this works very plainly for me.

[kampffmeyer]

TwinSnakes007, you're not missing anything, you've just got the right nodes built together! Thanks a lot!
My problem was to extract all values out of a matrix first (Get Object.kine.global - then matrix to SRT). Then the rotation values were messed up from the beginning.
What you did was to get the ORI-values straight from the beginning and then start all the calculating stuff and in the end convert it to matrix again.
Although in your scene the gears rotated faster the bigger they were - so just the wrong way But that was no problem fixing.

Cheers and thanks to all of you guys!

Wolfram