Problem with my rotation code?

ok, after going through and understanding more on rotational transforms, as well as going on a trip to california, i yesterday sat down and programmed up some rotation code, which probably isnt working due to how crappy my setup code is(in the program i tself), but I want to make sure the code itself is valid.

Code:

void Camera::RotateView(int degrees, float x, float y, float z)
{

	Vector3d Axis = Vector3d(x,y,z);
	float costheta = cos(degrees);
	float sintheta = sin(degrees);

	m_view = ((m_view - (Axis * Dot(Axis,m_view)))*costheta) + (Cross(Axis,m_view) *sintheta) + (Axis * Dot(Axis,m_view));
};

also, is there another way to change where the camera looks(more efficient) besides gluLookAt()?

EDIT: btw, the reason why I am not going through the vector compinents individually is I have overloaded operators in my vector class for both other vectors and also scalars.

degrees should be float. That looks like it should work, the problem could be getting degrees properly.

you can avoid using gluLookAt by translating the world in the opposite direction, and rotating about the y and then x axis in the negative direction.

edit:
axis must be normalized, view must be normzlied. check your crossproduct equation.

does it have to be kept as a normalized vector, or after all the math calculations do I "Un-Normalize" it?

EDIT: ^^like in the reflection algorithm

all vectors that you pass to math routines should be normalized all of the time.

EDIT:
to normalize:

float length = sqrt (x*x + y*y + z*z);
if( length > .00001) //rarely ever exactly zero
{
length = 1/length;//faster
x*=length;
y*=length;
z*=length;
}

yes, I know how to normalize(and from what I have seen, most of the equations for rotations/reflections/etc. I have seen require normalized vectors to hold true) , but the question remains, if I feed an equation the normalized versions of the vectors A and P, do I need to unnormalize the resulting vector(after the mathematical procedure) from the equation cause it wont be the right length(such as with the rotation algorithm, where you feed it the normalized vectors, but then unnormalize to get the right vector length).

P.S. in case you're wondering what I mean by unnormalize, i will express it in code.

Code:

Vector A = Vector(5,3,10);
Vector P = Vector(10,5,3);

A = Normalize(A);
float mag = Magnitude(P);
P = Normalize(P);

Vector R = RotateAroundAAxis(A,P,20.3); // just chosing a random number of degrees

R *= mag; //multiplying by magnitude of the original vector before rotation, to achieve the proper vector length

no, you don't do that. I have a Velocity structure in my code, which has a Vector and a magnitude. The vector is the direction, and a direction *must* have a length of 1. If it doesn't have a length of 1 it is a scalar multiple of the direction. You use the normalized direction to displace your position, i.e

Vector3d MoveDir = Vector3d (View.x,0,View.z);
MoveDir.Normalize();

//Now displace by x units this frame;

Position = Position + (MoveDir * x);

So basically what you are saying is, that, while one could use a "Vector" that isnt normalized as a unit, you recommend and use a system that all the vector's are used for is directions? how do you do vertices then of objects where the components in most cases are larger than 1 ? could I see some actual code to see what you are doing?

Position isn't a velocity, so you just store the real xyz of the position.

Code:

struct	Velocity
{
	Velocity()
	{
		Dir = Vector3(0,0,0);
		Mag = 0;
	}
	Vector3	Dir;
	float	Mag; 
};

//From my ray tracing code, this initializes an end point
	mBSPColInfo.BSPEnd = *Start + (to->Dir * to->Mag);
//Start is a real xyz position, to is the velocity, the end is the position plus the direction multiplied by its magnitude

Code:

float costheta = cos(degrees);
float sintheta = sin(degrees);

Unless you alread converted the "degrees" to radians when you called the function, I'm pretty sure cos() and sin() take radians...

lmao that's probably the problem...his code looks almost identical to mine, and I always just pass radians into the function to start with


so blade, look for that

Originally posted by EvBladeRunnervE


also, is there another way to change where the camera looks(more efficient) besides gluLookAt()?

In the manual you can read all about how glulookat works. Then you'll see how keeping track of a world position and a view direction, and updating the rotation matrix using a fast lookup table for trigs, only costs you 21 multiplications when the view direction changes where glulookat costs you 24 multiplications 2 divisions and 2 sqrt's every time you call glulookat whether or not you changed view direction. But who cares because if glulookat is the bottleneck on your "engine" that would mean you must be developing for a stopwatch. So lets talk about a real bottleneck:

I wouldn't store velocity as a normalized vector and a magnitude in a game. What happens when you have to add a linear acceleration to the velocity: convert velocity unit vector into non unit vector (3 extra multiplies), add acceleration, convert velocity back to unit vector ( 1 division, a sqrt, and 3 multiplies ). That comes to a total of 6 muls and 1 div and a fancy sqrt too wasted on every velocity in the scene, and all so you can use a velocity for a rotation axis. That would only be useful if you had radially symmetric charged objects moving through a magnetic field perpendicular to the axis of symmetry of the object (warning:you are writing a boring game if you have this), where as adding a linear acceleration to the velocity has to be done constantly in any scene.

you don't EVER change the velocity's direction into a non-unit vector...i think you dont understand how it works...and trust me, sqrt isn't *that* bad of a function, I've re-written it and it's almost impossible to write something faster than either the c standard sqrt() in math.h or the instrinsic floating point unit FSQRT

EDIT:
so, back to what you were saying, if you want to accelerate, you either rotate the direction vector, and then leave it, or you can update the magnitude, or do both...it's actually very, very easy, and logical, and it actually cuts down the number of sqrting.

ok, so your saying I should use unit vectors for everything, then for cases like vertices have something like

Code:

class Velocity
{
public:
float x,y,z;
float mag;

...

};

...

Velocity Vel;

...

glVertex3f(Vel.x * Vel.mag, Vel.y * Vel.mag, Vel.z * Vel.mag);

I understand that with velocities to always use unit vectors and a magnitude, but you are saying that with all vectors I should use a velocity-like system like in the above code?

P.S. the whole reason I seem a bit not-understanding is I am trying to get rid of those bad lessons one gets from GameTutorials.com(one of which is they never explain vector projection math, which hurts someone who doesn't have a 3D math /Vector Calculus book)

Originally posted by Silvercord

so, back to what you were saying, if you want to accelerate, you either rotate the direction vector, and then leave it, or you can update the magnitude, or do both...it's actually very, very easy, and logical, and it actually cuts down the number of sqrting.

So if I have a velocity (2,0,0) and I want to accelerate it (0,-0.1,0). You're saying that for linear accelerations (2,0,0)+(0,-0.1,0) is less logical and slower than doing a rotation and updating the magnitude? You have to do both operations unless you are in a orbit with eccentricity 0. So its not 'either or', its both: rotate and update magnitude. And updating the magnitude requires you to know the new velocity vector precisely, else all you know about the new magnitude is the triangle inequality: mag( A + B ) <= mag(A) + mag(B). So you have to computer (2,0,0)+(0,-0.1,0) anyway to get the magnitude. In addition, if you do the update with rotations you either have to use quaternions or keep up with perturbed frame axes if you have more than one acceleration on a velocity. If you have some way around all this what is it?

[edit]: Actually, there are other parameters for the rotation that can only be calculated by computing the translation first. Actually whatever you are doing as a 'rotation' that is achieving the same effect as a translation can't be a rotation at all because it isn't preserving x^2+y^2+z^2. So somewhere in your code you are sneaking in all of the operations for a translation, plus some for extracting the parameters for the rotation, and then the operations for a rotation.

blade, no i do not use a velocity for storing positions, I just store their real positions, but I also have a velocity for each object that moves. however, i'm sure grady will tell me how bad that method is, so if you dont' like it, don't use it, i dont' really give a $$$$

EDIT:

Actually, there are other parameters for the rotation that can only be calculated by computing the translation first. Actually whatever you are doing as a 'rotation' that is achieving the same effect as a translation can't be a rotation at all because it isn't preserving x^2+y^2+z^2. So somewhere in your code you are sneaking in all of the operations for a translation, plus some for extracting the parameters for the rotation, and then the operations for a rotation.

right...i just think it's funny listening to those people that think they know absolutely everything, and try to prove it by throwing out every possible term they can think of that makes them seem smart (ooo, you said, *quaternion*!) . Oh, and orbits are ellipcital, meaning they never have an eccentricity of zero (that'd be a circle )