Ok, here's the deal. I am animating a sphere, and, of course, it is really easy to determine the appropriate amount of rotation when travelling along the x or y axis only: (Distance / Circumference) * 360 My problem is determining it for an angular translation. If the sphere is moved from, say, (0,0) to (3,5) [x,z coords], then the distance travelled is ~5.8 units, requiring a rotation in the direction of that vector... Poser does not allow for rotations along an axis perpendicular to that vector, only x,y,z! So I'm stuck. I'm trying to complete a Python script to automate it, so all I have to do is translate and the script will rotate the sphere automatically. Can someone help with devising an equation to determine the amount of rotation required? I would be forever in your debt!! Thanks! -RP

It's not clear what you mean when you say that a translation requires a rotation. Are you talking about the angle of the actual move? In that case, [0,0] to [3,5] would give an angle in radians figured by arctan2(5,3). But I suspect that's not what you mean. Can you show a Poser image with some arrows drawn on it to illustrate which rotation you're discussing?

Sure... Unfortunately, I'm away from a machine with Poser, so this sketch is the best I can do, but it will work. I'm looking for rotation as x, y and z components. In other words, what equation will determine how to rotate along x,y,z axes to simulate rotation along an arbitrary axis? -RP

Oh, now I see. First, bear in mind that you will need to limit your actions to only two angles. It doesn't matter which you choose, but you'll have to stick to those two. The Poser system using all 3 angles really can't be used. (This is the Gimbal Lock problem which has been discussed considerably around here.) Within Poser, I'd be inclined to handle the problem in a more "physical" way, sort of like this: Parent the sphere to a "platform" like a box prop. Start the sphere in 0,0,0 position wrt the box. Make the desired rotation about the Y axis on the sphere itself. Then use the "platform" to make the other two rotations. This way involves no special math, avoids the gimbal lock mess, and uses the available resources.

A couple further clarifications... 1. The platform would then receive both rotations and translations, and the Yrot of the sphere would remain independent of both. This is where the math is eliminated. 2. I showed the picture with the platform outside the sphere, hoping to illustrate the "joint" thereby. But in reality, you'd want to locate the platform inside the sphere, with both offsets (green cross) adjusted to be in the middle of the sphere.

This quickie animation might show better than language. The platform can be translated and rotated in any way, but the sphere always rotates about its fixed poles.

Let me try that... I'll let you know if it works. I still have to figure out the rotations tho... I think. Hopefully this approach will create the result I want, namely to have it appear as tho the sphere is rolling along with the translation. Thanks so much for your help. -RP

You can also use a cross product to determine the ang rotation for the sphere based on the linear vel at the radius. The problem you will come across is gimble lock which will cause axis to flip when angles exceed 90 degrees. Here you can either do the math fully with quaternions or take the matrix and added euler, conver to quaternions, multiply, convert back to a matrix then extract the up an forward vecs to get the correct rotation.

If the rolling is "frictionless", like a tire rolling on a surface, you should be able to figure by just using the circumference... Actual translation of the sphere (the hypotenuse of X and Z components) divided by 2pi gives rotation about sphere's own pole in radians; then change that to degrees. (You undoubtedly know this; I'm trying to be complete.) But if the rolling is not meant to be nicely perpendicular (like a wheel skidding partly sideways), then you will have some friction, and the rotation can't be figured from the translation in any obvious way. You could apply an arbitrary friction coefficient, I suppose....

ockham has the best (and most widely used) solution. Parenting is a great method to "isolate" coordinates systems from the world coordinates so that rotation and translation can be calculated with respect to the parent system and not the world system. Otherwise, it get's really, really complex - just try moving and rotating along a vector that doesn't have it's start on the world axis (e.g.: a camera that you want to dolly along it's Z-axis, no matter what orientation it has to the world system), but using world coordinates. BYS

Light Bulb BYS COMPLETELY made okham's approach click... whew. I just have to rotate the BOX on the y, and then let the sphere roll "around" it... like a tire on a wheel... the wheel turns left and right, the tire moves around. Is that right? (please say I finally got it.... unless I didn't.. hehe) OK, now I'm just gonna have to leave work early and try it :-) -RP

Yup, you got it. Actually, this is the central "light bulb" of Poser itself: the separation of BODY from the real body in a CR2. Without that separation of rotations, gimbal lock would prevent you from doing just about anything! Out of curiosity: the basic problem here reminds me of some old mechanical gadgets like a Planimeter, or the disk-and-ball integrator in ancient mechanical analog computers. Are you thinking along those lines?

Never heard of a Planimeter... I'm going to have to look that one up :-) Actually, its for the intro of my demo reel for a grad school... Everyone has told me that my resume is "well-rounded" (CS degree, theatre scholarship, animation hobby), so I decided to animate a sphere with a bit of personality :-) I planned it out, but at one point I need a high speed, long distance rotation in different directions, so I decided to write a python script to automate it. That way, I just move the sphere where I want it, and it will roll appropriately. When I finish it, and if it works, I'll put it in the freebies for sure. IMO, python was almost MADE for this sort of tedious task... now if only I can code it right :-) -RP

For that purpose, this "axle" method should work just fine. Be sure you figure at small increments, like once per frame, so that your dx/dt at each move will safely approximate a straight line. I had the sense that you might have been working on a surface measurement scheme like a planimeter; in that case you'd need more precise mathematics.