also as a added cheeky question, is it better to rotate the ship and base the camera off of it or is it better to rotate the camera and base the ship off of that

I tend to treat them as entirely separate objects, which helps for dynamic effects (pulling the camera back when the ship accelerates, etc)

Hey guys,

On an update,I believe I now have working local axes based rotation using quats and the 3 vectors. Thanks for all of the help.

The only real thing i changed was that up = glm::cross(right,forward); instead of up = glm::cross(foward,right);

if anyone whats me to post some of the code let me know :)

Wait I thought up was positive and down was negative and right was positive and left was negative

left hand rule:

use your left hand

point your thumb in the direction of the positive axis in question (the positive x axis in this case, so point your left thumb to the right)

now curl your finders into a fist. the direction of curl is positive rotation. ie rotating down is positive x rotation in a left hand system.

so the positive rotation directions for a left hand system work out to:

down (xr), right( yr), counter-clockwise (zr).

for a right hand system, use your right hand. and you get positive rotations of: up, left, clockwise.

is it better to rotate the ship and base the camera off of it or is it better to rotate the camera and base the ship off of that

the player ship can be just another ship, or a special version of a ship that you model in greater detail.

when its time to draw, simply set the camera to the player ship's location and orientation, and draw.

so you want to move and turn the ship like any other entity, and simply set the camera to match it when its time to draw.

that also makes it easy to set the camera to match ANY ship when its time to draw, so you can see the view from ANY ship in the simulation.

treat the ship and camera as separate things. you just happen to place the camera where the ship is for drawing what the ship sees. and in general, you place the camera where an object is to draw what that object sees.

The only real thing i changed was that up = glm::cross(right,forward); instead of up = glm::cross(foward,right);

ah yes, forgot to mention that cross product is sign sensitive. do it in one order, and the resulting mutually perpendicular vector points one way, do it in the reverse order and it points the other (IE down, not up, ad so on).

https://en.wikipedia.org/wiki/Cross_product

if anyone whats me to post some of the code let me know

for those who read this thread in the future, it would be nice if you posted your code for applying the rotations using quats, and your code for the re-ortho-normalization using quats.

like i said, i know its doable. never done it myself - just with mats. as you see, once you start using the correct algos for local rotations (axis angle and re-ortho-normalize), and get everything in the right order so all your signs are correct and everything points the right way, its not really that complicated. but to tell you the truth, i've never actually seen working quat code for axis and re-orthro normal. so yeah, post some! just the few lines that do the math should be sufficient.

but to tell you the truth, i've never actually seen working quat code for axis and re-orthro normal.

That's one of the primary advantages of using quaternions: orthogonalisation is just the same as normalising a 4-dimensional vector.

i.e. normal = q / length(q)

i.e. normal = q / length(q)

but that just gives you the normal of a quat, right?

it doesn't re-ortho-nomalize the forward, up and right vectors after applying a discrete finite rotation - does it?.

it doesn't re-ortho-nomalize the forward, up and right vectors after applying a discrete finite rotation - does it?.

As far as I can tell, they amount to the same thing in imaginary number land. The only clear reference on google books would seem to bear this out.

As far as I can tell, they amount to the same thing in imaginary number land. The only clear reference on google books would seem to bear this out.

i'm unable to cut and paste the text in that link, so others will simply have to follow it and read it for themselves.

so you're saying store the orientation as a quat instead of forward, up and right vectors?

and to turn, you use axis-angle to create your discrete rotation quat (-5 degrees around local y for example), then compose that with the current orientation quat, and then normalize the quat?

as opposed to fwd,up,and rt vectors, axis-angle rotations around them, and gramm-schmidt (not gauss, my bad!) re-ortho-normalization ?

so you'd start with a quat of no rotation when the entity became active, and then simply apply sucessive discrete rotation quats to turn it, re-normalizing as you go. and when its time to draw, you have the quat at hand for use as the "orientation matrix". correct?

but what about movement? every update you take a unit vector 0,0,1, and rotate it by the quat to get the forward vector for 3d movement? and what if you need the right and up vectors for some reason, such as look left/right/up/down in a flight sim? same deal? you create a unit vector and rotate it by the quat?

why reconstruct the forward vector (and possibly up and right) every update from a quat? i think that's the reason why i finally settled on mats vs quats, 'casue once you look at all the things you need in a flight sim, they all require vectors or mats , not quats (assuming directx - it converts quats to mats and uses mats internally - OGL too, i think).

with fwd,up,rt and vectors, you have them ready to go for different camera views, movement, local rotations, and stuffing into a rotation mat. but gramm-schmidt is more complex than normalizing a quat.

with quats you have to reconstruct the vectors every update for camera views and movement. local rotations are of comparable difficulty, and dx (and OGL?) both use mats internally, so you've got conversion overhead no matter what. the upside is that normalization is simpler than gramm-schmidt, and due to how quats work, the rate of error accumulation ought to be about half as fast as it is for vectors.

its kind of a wash. i suppose one could count the adds, muls, divs etc for both methods for turning, moving, and drawing to get an idea of which was less work overall.

i've found that once gramm-schmidt is working, vectors are quite easy and intuitive to work with. and i've never had any problems with gramm-schmidt being a performance bottleneck, even with hundreds of entities and re-ortho-normalizing after every turn.