Hi, this is a desperate attempt to understand the logic behind the 3D rotations, I have been searching and asking question at gamedev.net and in this forum aswell, so far I manage to get something working, with None understanding of what is going on, and at the end that code is wrong and I dont know how to fix it (chek it out here http://processing.org/discourse/yabb2/num_1265029882__.html

The basic problem is that most of the tutorials I found they assume you know most of the concepts already. 90% of them say with the angle of rotation and the axis, do this and that, fine but can you explain how to obtain the angle of rotation!! that sort of stuff... missing pieces I cant work out. This may sound basic to some, and reading this may think what a #%&* I am and frankly at this point I take it.

So please if you know how this works be so kind to let me know as I have all sorts of questions to ask, if you now a book that explains this from scratch do so as well I need to learn this.

All I want to do is simple, to orientate an object to its velocity.

I am one step to go loco

Cheers
rS

Every time I post, after some more browsing I found more pieces of the puzzle.

From this site http://www.essentialmath.com/tutorial.htm I found a ppt presentation about Quaternions, that help me understand where the axis of rotation and the angle of rotation are coming from, so correct me if I am wrong here:

So they say, if I want to rotate V1 to V2
Axis of rotation = crossProduct(v1, v2)
Angle of rotation = acos(dotProduct(v1, v2))

From there I can say V1 = velocity vector and V2 = up vector, am I right?

rS

This is an interesting question - one that I'm sure I'll want to answer for myself when as I start doing more 3D stuff.

Not wanting to frustrate you any further, but have you considered that for an object to be "pointing" in the direction of its velocity, it can also spin around on that velocity-direction-axis and still be pointing in that direction? Which of those orientations do you want?

Here's an idea:

think of the earth, and how we typically divide it up; latitude (the flat slices stacked on top of each other) and longitude (the beachball or orange segments that run through the poles).

Now, imagine a "unit sphere" (or earth with radius 1 unit). Your velocity vector can be normalised to be length 1 in the same direction. If we root this at the centre of the earth, our normalised velocity vector reaches to a point on the surface of the earth/sphere.

If we look at the Earth side-on, we can imagine a unit circle centred on X-Y axes. We know what the Y-value is (it is the Y value of our normalised vector) and we need to work out what the "latitude" (angle from the equator) is. If you draw a sketch, you can probably figure this out.

Then another step to work out what angle to rotate around the Y axis to get to the point on the latitude circle for the Z coordinate.

Well, that may or may not work, and may also involve doing some tests to check which quadrant of various circles you're looking at... and since it isn't an 'elegant' way using vector maths, probably isn't the best!

Your notion about V1 and V2 sounds reasonable (assuming your object is originally oriented "pointing" towards what you call "up"). The question is, though, how to use the quaternion (axis of rotation and angle of rotation) that you find?

rotateX(), rotate(Y), rotate(Z) are (I think) implemented using a rotation axis vector with some lower-level call - eg OpenGL's glRotatef(angle, x, y, z) - which isn't mentioned in the usual Processing methods.

-spxl

i was reading up on yaw, pitch and roll at the weekend, which sounds a lot like the same thing - it's how you describe how an aeroplane is oriented. getting the 'plane to be correctly oriented on screen was just a case of applying 3 matrix multiplications, one for each angle. BUT they had to be done in the right order, yaw, then pitch, then roll. (and your heading vector is just (SPEED, 0, 0) multiplied by the same matrices, assuming that x axis is forward.)

basically you spin the plane (facing along +ve X) around Y until it's pointing the right way, then rotate it up (which rotates it up against the *rotated* Z axis (Z= in / out)) then roll it in the X (which rotates it against the *twice rotated* X axis).

maths largely from here, although their axes were different (Z = up, is this an american thing?)
http://en.wikipedia.org/wiki/Tait-Bryan_rotations

Trying to build my quaternion from this
Code:

Vec3D new_dir = new Vec3D(velocity);
new_dir.normalize();
Vec3D new_up = new Vec3D(0.0, 1.0, 0.0);
new_up.normalize();
Vec3D crossP = velocity.cross(new_up);
crossP.normalize();

float dotP = new_dir.dot(new_up);
float angle = new_dir.angleBetween(new_up, true); 

Quaternion Q  = new Quaternion(cos(angle / 2.0), crossP.scale(sin(angle / 2.0))); 

from Describing rotations with quaternions @ http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation

No success

rS

Hi V,

Yes I am transforming the boids, and using the right metric notation, if I rotate by
Code:

rotate(-angle, crossP.x, crossP.y, crossP.z); 

It works fine, but there is a funny jump sort-of quick back and forward, I am not sure the cause.

I think is something to do calculating the angleBetween, when that method is set to true, it avoids getting NaN as result, and when that happens is when I can see the jump.

So I want to try a different approach.

The rotation stuff is in the Boid class at the top of the display() method

http://nardove.com/p5/misc/steering_3ex/

And here is the javadoc for the Vec3D and Quaternion
http://toxiclibs.org/docs/core/

Thanks
rS

V Quote:

Not exactly by the jump I mean, there are moments when the Agent(cone) flip back and forward very quickly, will the SLERP fix that? I will look into it

Cheers
rS

this question comes up frequently (in fact there appears to be yet another just started here: http://processing.org/discourse/yabb2/num_1265738576_.html
sometimes it's about aligning objects to their velocity, sometimes it's about building oriented cylinders, but they're all aspects of the same question:  given two points, how do you rotate around the first to orient towards the second

the problem with trying to provide THE answer is that there isn't a single answer, and it really depends on what data you're keeping track of and what aspect of the problem you're trying to solve.  often you can just cheat and apply a spherical coordinate approach - see my posts in these threads:
http://processing.org/discourse/yabb2/num_1264161510.html
http://processing.org/discourse/yabb2/num_1206925856.html

but what that doesn't account for is "roll" (to use the airplane analogy).  with only two points (well, a position and a velocity vector, if I've correctly followed your several threads) you can't nail down all three implied axes, all you can get is two. (which is enough to "point at", but not enough to determine where "up/roll" should be)

typically if you need all three axes you'll have to carry around your own pitch/roll/yaw or a frenet frame or orthonormal TNB vectors or etcetera, potentially converting back and forth to quats if you need to slerp them, and WON'T be attempting to "derive" them from velocity-position alone.  

you can try faking that third local axes ("up") by hard-coding it (perhaps as the world y-axis) sometimes.  then you can cross your "at" vector (vel-pos) with "up" to get "right" and you now have local TNB.  keep in mind that crossing only guarantees perpendicular, not WHICH perpendicular, so you typically cross back, maybe iterate, etc, yuck -- it's still only a partial solution.  so you can expect to experience problems as your velocity approaches being colinear with whatever hard-coded value you choose.

hth