Simple question.

Hi everyone, I've been playing aroung with gamestudio for about a month and this is my first post. I have a simple question. I would like to convert my local vectors to global vectors to perform a calculation, but I'm having problems with the angle system, specifcally that different angles can represent the same vector. I can get one vector easily, but the other two elude me. Can anyone help?

???

When you convert an angle (i.e. pan, tilt and roll) to a position vector you've got an infinite number of position vectors that correspond to this angle. So I guess there is a misunderstanding here. Can you explain what you mean with "the other two" ?

Sure. It's easy enough to translate one vector from local to global by simply applying the calculation:
x = cosv(my.pan) * cosv(my.tilt)
y = sinv(my.pan) * cosv(my.tilt)
z = sinv(my.tilt)
vector(x,y,z)

This works everytime and refers to the vector that extends along the x-axis at the identity matrix. The other two vectors, the ones that point along the Y and Z axes are more elusive because the effect of roll has to be considered along with pan and tilt, and ??the order they were applied in??.

I have been combing the internet for a solution, and also the several math books I have and they all generally give me the same recommendation: these "Euler angles" are a poor choice to represent 3d orientation, choose something else. I'm using what I'm given, do I have another choice? Is there a simpler way to convert from local to global?

why don't you use vec_rotate()?

euler angles are the most intuitive representation to humans and in many cases they work just fine. if you do something like a space ship simulator where you always have arbitrary rotations about 3 axes at the same time then you have to use something else since euler angles will cause gimbal lock.

Are you aware of the engine functions vec_for_ent and vec_to_ent ?

Thanks, guys, for the suggestions...

@ventilator: the problem I'm having with vec_rotate is that it still uses Euler angles and they're so hard to predict. Some further help would be appreciated.

@Uhrwerk: no, I wasn't aware of those functions, thanks for bringing them to my attention. I'm not sure its what I'm looking for but its definately worth a look.

if you're trying to move away from Euler angles have you looked at quaternion angles?

see e.g vec_rotateaxis

vec_rotate() isn't hard to predict.
vec_for_ent() does the same but also takes position and scale into account.

you should describe what exactly you are trying to do. what do you need this for? then it is easier to help.

My character moves when the stick is pushed down, then when released it's momentum tapers off. this is fine until it hits a wall and the movement stops but the momentum calculaions continue to taper off. So, obviously, momentum in the direction of impact needs to be canceled, but not in other directions, meaning that only one or two elements of a local movement vector need to be corrected. If I can break down each element into its XYZ components I can perform a dot product comparison with hit data provided by c_move and discover how much each vector needs to be corrected.

I have to disagree about vec_rotate, I can get the rotation to work from one particular position to another, but as I try to do it dynamically thru a full range of movement it will work in certain portions of the arc and not others.

I still haven't had time to try and implement vec_for_ent yet, but I will soon.

Thanks for your interest, any help will be greatly appreciated.