Rotating a cuboid to span two coordinates

[Rocko Bonaparte]

I wanted to use something like a cuboid--a thin, 3d rectangle to connect between two 3d points. They idea is it would be a 3d cursor. I'm trying to manipulate the position, rotation, and scale vectors of an Irrlicht-generated cube to get this. Position and scale are easy: average the coordinates for the center point and use absolute value of diff for scaling. I'm stuck with rotation. Let's say for now I'm ignoring one coordinate plane by connected (5, 5, 0) to (0, 0, 0). Attempt #1 was to use atan2 in something like this:

X = atan2(y, z)
Y = atan2(z, x)
Z = atan2(x, y)

I end up doing a multi-axis rotation this way, when I only need to spin around the Z.

I was given some advice to just normalize the difference vector, and that is also a multi-axis rotation.

None of this factors in the order in which I apply all this stuff. I suppose if I set the position, then scale, then rotate, I'll get something goofy. So how can I enforce ordering to this?

[blAaarg]

look into:

Code: Select all

vector3df::getHorizontalAngle()
Get the rotations that would make a (0,0,1) direction vector point in the same direction as this direction vector. 
 

It should return a "rotation" vector which can be applied to the "cuboid" node with:

cuboid->setRotation( /here'sTheReturnValueOf getHorizontalAngle()/ );

the vector3df that you'll use for calling "getHorizontalAngle()" is simply taken from the difference (vector) between the two coordinates you used for calculating the position.

Avoid low level trig functions like atan() as Irrlicht already provides this functionality for you.

If that's not descriptive enough for you just ask. I'll try to simplify it. Or be more specific.

[Rocko Bonaparte]

That looks like it gives me the proper angle. Phew that was much easier. :p

My issue now is that the scaling I'm using is wrong. It does all kinds of bizarre stuff, but it certainly does not make the unit cube touch both of those points. I've tried using the normalized vector as well and gotten no good results. I don't really know how it takes scaling and rotation into consideration in the process. Am I scaling relative to the new rotated direction or in terms of my simulation space?

[blAaarg]

I don't know how you're doing your scaling or what bizarre results you get so I can only guess. The matrix rotation and scaling happen around the cube's local origin before translation (or, you could say it spins and scales around its absolute position after positioning it) but the unit cube is not centered in its own space. Its front left bottom corner is on the origin.

[Rocko Bonaparte]

I don't know how you're doing your scaling or what bizarre results you get so I can only guess. The matrix rotation and scaling happen around the cube's local origin before translation (or, you could say it spins and scales around its absolute position after positioning it) but the unit cube is not centered in its own space. Its front left bottom corner is on the origin.

Oooh that's good to know so I can adjust. It was looking okay but it's not like I had a grid up to check. What I have now is a cube that appears to span (5, 5, 0) to (0, 0, 0)--excluding that little bit about the cube's center. Your suggestion successfully got the rotation under control. What puzzled me was how I managed to scale it. I thought originally I wanted to scale the length of the cube--a kind of meaningless statement really. But regardless I tried (5, 1, 1) and would get a bizarre effect of the cuboid turning itself inside out as it spun around. With some fudging around, I found (1, 1, 5) seemed to work, but I don't understand why.

[Rocko Bonaparte]

It doesn't appear to me the cube's center is the origin. The translation looks okay, and I superimposed some 3d lines. Everything implied that it was using the center of the cube as the origin.

I figured out the scaling was taking effect before the rotation in the transformations. So I wanted to use the Z component as the length that I was expecting. I tried moving the cube around to different axes, and using the Z-axis for the scaling component always worked.