Problem with my rotation code?

[EvBladeRunnervE]

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.



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.

[Silvercord]

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.

[EvBladeRunnervE]

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

[Silvercord]

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;
}

[EvBladeRunnervE]

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.




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

[Silvercord]

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);

[EvBladeRunnervE]

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?

[Silvercord]

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


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

[JaWiB]

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...

[Silvercord]

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 :) :) :)

[grady]

Originally posted by EvBladeRunnervE


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


In the manual (http://www.amazon.com/exec/obidos/tg/detail/-/0201657651/qid=1070139052//ref=sr_8_xs_ap_i0_xgl14/103-5736646-1616643?v=glance&s=books&n=507846) 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.

[Silvercord]

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.

[EvBladeRunnervE]

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

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)

[grady]

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.

[Silvercord]

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 :) )

[EvBladeRunnervE]

ah, I see what you are saying, sounds like a great idea. also, using velocities for rotation makes it much more smooth, cause I am just not changing a vertices position at one time, but can apply movement to it.

thanks

[grady]

Originally posted by Silvercord
(ooo, you said, *quaternion*!) . Oh, and orbits are ellipcital, meaning they never have an eccentricity of zero (that'd be a circle :) )
I admit 'quaternion' does sound rather fancy. I'm just pointing out possible things that might be cumbersome in your method, and having a discussion about vectors in general, nothing personal. If you have a nice solution or if I'm making a mistake and there is no problem just say so.

Yes &epsilon;=0 is a circle and indeed that is precisely the only trajectory that will require you to rotate the velocity without changing the magnitude: which is the situation I was referring to in that post. True enough, there are a range of values &epsilon; can have for the other conic sections the trajectory can take on. Thus in practice circular orbits are never seen. But so what? Its still the only orbit where rotations alone on the velocity are sufficient

This veers away from EvBladeRunnervE's original question, which has been answered, towards the new question which is apparently: how should vectors be represented internally. I'm just trying to point out alot of extra math operations incurred if the rule is to always normalize vectors. The only places I can think of where vectors must always be normalized is when they are used as axes of rotations, or they will be representing a 'normal to a surface' vector and used in dot products where you only need cos &theta;.

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 objectOops, i messed up here, the velocity would have to point along the axis of symmetry and the field has to point out from or in to the axis of symmetry. Not possible, so nevermind that example. I can't think of any simple situation where you would rotate around the velocity vector. However, getting cos &theta; from the velocity of a vertex and another vector sounds useful.

[Silvercord]

you really haven't done very much graphics programming, have you? Go home, program a game engine, and THEN tell me how useless normalized vectors are

EDIT: oh, also, I wouldn't compute realtime the orbit of an object in a computer game. If I wanted, say, an asteroid floating around a planet, I'd make way points for it to hit in the editing program. this means that there are no computations involved, it simply would travel from waypoint to waypoint, and *look* like it's orbiting. aesthetics are more important than 100% physically correct computations in computer games, so, fugazi

[EvBladeRunnervE]

here is a new question, when and where should I use a "Velocity" type of class, i can see it as useful in movement, but I dont see how it would be useful in the case of a rotation, where you are moving a "point" to a specific point, not constant movement between one point and the other.....feh, still can't get gametutorials stupid ideas out of my head.

thanks,

[grady]

I think you're saying you are clear about linear velocity. Rotations are caused by angular velocity, and the parameters for an angular movement are different from those of a linear movement. You can still chant the old mantra "velocity is magnitude plus a direction" but direction in angular motion is specified by an axis (normalized vector) and the sign of the degrees to rotate through. The sign tells you whether to move counter clockwise or clockwise around the axis. The magnitude can just be thought of as the absolute value of degrees you turn through. So really, if you've got this for your "velocity" data structure:


struct velocity
{
float x,y,z;
};

It just won't work for an angular velocity because you need an extra parameter:


struct angvelocity
{
float x,y,z,degrees;
};

This is all fine and good, but plugging in an axis and a number of degrees is going to rotate you around the origin of your frame. When you're writing a physics simulation and something gets thrown through the air, it is going to spin on its own local axis. So in addition to the above struct, you have to specify a point to adjust the axis away from the origin of the scene. Rotating not through the origin also makes you have to do a little pre and post processing on the vertex you are rotating.

So a velocity class that you use like so:
vtx.x += vel.x;
vtx.y += vel.y;
vtx.z += vet.z;
glVertex3f(vtx.x,vtx.y,vtx.z);
isn't going to get you anywhere with rotations, because its a linear velocity and has no relation to your angular movement. Bottom line is: you need two types of velocity class, but it all sort of ties into how you are implementing things in your physics code. There might be a more effecient way for your specific needs, but that way, whatever it is, doesn't involve linear velocity telling you anything about angular velocity.

[Silvercord]

just stop posting here.

[EvBladeRunnervE]

just stop posting here.

I second that.

Believe it or not, when most people post questions, they do somewhat expect them to be answered by people actually developing/have developed a 3D engine like Silvercord, Grady.

[Bubba]

...My suggestion is to normalize the vector first, store it, then rotate the normalized vector through your equations. If I'm correct the normal will never change and will always be perpendicular to the surface pointing 'outward' So if the object rotates, everything remains the same in the relation of the normal to the surface. The only thing changing is the rotation. So theoretically if you compute the normal once and then simply rotate it later - its the same thing and its much faster.

After all if you rotate a vector and normalize it, is that not the same thing as normalizing the vector first and then rotating the normal later??

If you wish to get past the oh so slow sqrt function, there is an imprecise way to do a sqrt using a Taylor-Series power function.
It has a +/- 8% error which might give some wacky results in lighting equations. But you can also get a 3% error if you use a single and not a double, so it's up to you.




double Fast_Distance3D(double fx,double fy,double fz)
{
int temp;
int x,y,z;
x=fabs(fx)*1024;
y=fabs(fy)*1024;
z=fabs(fz)*1024;

if (y<x) SWAP (x,y,temp);
if (z<y) SWAP (y,z,temp);
if (y<x) SWAP (x,y,temp);

int dist=(z+11*(y>>5)+(x>>2));
return ((double)dist>>10));
}


SWAP is left for you to code.

Even on faster comps, sqrt() still takes a lot of clocks so I'd use any method I could find to minimize its use.

By the way, there is NO performance hit for using doubles as opposed to singles. The FPU opcode that loads a real into ST(0) FLD can both use singles and doubles - there is no extra cost for converting either one to the native FPU data type which is 80 bits - not 64 as I previously thought.

EDIT: Kudos to Fordy for pointing this fact out to me over at the assembly board on www.flashdaddee.com


This is for the 80486 - there is no clock data for the new Pentium IA-32's, but don't expect a lot of difference.

FLD m32real - 3 clocks
FLD m64real - 3 clocks
FLD m80real - 6 clocks
FLD ST(i) - 4 clocks

Float is a m32real, and double is an m64real. No performance hit.
A single is a 32-bit value or float and a double is a 64-bit value.

Clocks are a measure of how many cycles it takes to execute the instruction. Actual real-time nanoseconds might be different. A computer running at 1 GHz will definitely be able to execute faster than a 2GHz, but the base instruction clock timing remains the same - it just executes it faster.

[Silvercord]

I only offer what I do.

blade feel free to pm me with stuff too.


it is going to spin on its own local axis


There's an extremely easy way to do this. mVelocity is the ball's current direction. All you need to do, in the renderer, before you render the object, in this case it is a ball, you simply need to rotate the entire coordinate system 90 degrees about the y axis, and then rotate about the forward direction (which is now perpendicular to the forward direction), and it gives the illusion of spinning on its local axis. I just coded it up, and it works.


glPolygonMode(GL_FRONT_AND_BACK,GL_LINE); //so you can tell that the auxsolidsphere is rotating
static float degrees = 0;
degrees += 100 * Export.mFPS.TimeFrac;

glPushMatrix();
glTranslatef(ball.mCurPos.x,ball.mCurPos.y,ball.mC urPos.z);
glRotatef(90,0,1,0);
glRotatef(degrees,ball.mCurVelocity.x, ball.mCurVelocity.y, ball.mCurVelocity.z);
glColor3f(1.0f,0.0f,0.0f);
auxSolidSphere(10.0f);
glPopMatrix();
glPolygonMode(GL_FRONT_AND_BACK,GL_FILL);


EDIT:
i implemented taylor iteration, and i've got an equivalent fast_sqrt method(which I posted on these boards), and I found out that they're not really much faster than either the C standard sqrt() in math.h or the intrinsic FSQRT on the FPU (I've reprogrammed all of my math using FPU, just for fun). i.e I ran the sqrt method several million times, and it took 381 ms. that was actually faster than my taylor series iteration in 2 steps! sqrt is *not that* slow

EDIT1: in fact, the function that you should be most concerned with is the dotproduct function, because it gets called more than any other function. I was wondering why so many people are so anal retentive about getting that function to work with SIMD optimizations and fun junk like that.

[Bubba]

By the way I believe DirectX's vertex structure - at least one of them - stores the normals for vectors and then rotates them later and it seems to work fine.

Not sure how OpenGL works becuase I don't code in it, but perhaps it has similiar support. In a large 3D engine with lots of polies, I shudder to think of finding the normal for each surface and I'm sure Silvercoord is not doing this.

EDIT: Interesting info about the sqrt(). I've not coded the Taylor series in assembly but I'm sure you are correct about the sqrt() and FSQRT. I would probably use FSQRT myself being the asm guy that I am. Either way stack is going to be used for parameters - so the C function might just as well suffice.

[Silvercord]

hell no bubba :)

the normals to surfaces are pre computed for the world, and for collision detection against moving objects in the BSP the normals to the planes for bounding boxes are axially aligned :)

i.e they are simply x, y, z and their negatives.

[EvBladeRunnervE]

ok, here is a new question, how do I rotate an object around a specific point? my code works for any axis, but it is based on origin, I presume I could just glTranslatef to the point thereby making that the origin, but I would like to know, or atleast be pointed in the direction of how to do it without translating anything.

EDIT:

Silvercord:

so, the BSP has all of its surface normals stored in the file already?

[Silvercord]

translate it out, and then rotate

[Bubba]

hell no bubba


:D Didn't think so.


To rotate around a specific point in general 3D terms, translate the LOCAL origin to that point using Translate. Then when you transform to world and view the object will rotate correctly.

[Silvercord]

so, the BSP has all of its surface normals stored in the file already?


yes sahr!

EDIT: bubba, I pmed you with an asm question.

[EvBladeRunnervE]

Isn't there a more efficient way of doing things? cause basically from what you're telling is that I have to translate to where the center of my needed rotation is for every single object that needs rotated? what is the computational expense by doing it?

Also, it means I will have to restructure my math yet again, as if I had two points, <0,0,-24> and <10,0,-24> (stored in vectors)and I wanted to rotate around the y-axis, translating to <0,0,-24>, then that second point would be way off in its rotation, as it should then be <10,0,0>, as <0,0,-24> is the new origin for it(however, I could just write out my objects so that each object has a center point, and all the rest of its points are relative to that center).

P.S.

Silvercord:

thank god for you recommending that book, as it has all the collision detection I could ever need, and it leaves the implementation codewise up to the individual pretty much.

A little NOTE: I am thinking that in a little bit I might need help with some of the collision detection, as most of it uses time to predict the collision, instead of distance; however I dont know how I could implement time into consideration(unless I always solve for "t" in my equations and when "t" is almost equal to 0 count it as a collision)

[Silvercord]

I don't like the way they explain collision detection in that book, however ultimately it's very close to what i actually do.

If you plan on implementing quake3 BSP, you are going to need to learn the brush collision detection algorithm for colliding against the world. Also, collision detection was one of the more complicated things I had to code up. Ultimately the tutorials you'll read all have problems which I've had to work around or solve.

[Bubba]

You are creating your objects around 0,0,0 aren't you? In local space that is or model space? If you create a model around another point when you create it, you are asking for troubles because every rotation you do is compounded upon the fact that the original model was not built around 0,0,0.

[Silvercord]

blade i don't know what your problem is with the rotations/translations.

[EvBladeRunnervE]

blade i don't know what your problem is with the rotations/translations.

I'm trying to remake the wheel(trying to code up my own solutions) it seems....it's something I unfortunatly do sometimes(AKA making things harder than they are).

so besides the practice I get by doing this coding, is there even a real purpose for it?

[Silvercord]

what exactly are you doing, and what exactly is the problem? a little bit of intuition here and there never hurt anybody, but, like, I have no clue what you are trying to actually accomplish.

[grady]

then that second point would be way off in its rotation Right, like I said:
Originally posted by grady

struct angvelocity
{
float x,y,z,degrees;
};

[snip]
So in addition to the above struct, you have to specify a point to adjust the axis away from the origin of the scene. Rotating not through the origin also makes you have to do a little pre and post processing on the vertex you are rotating.

Bubba is right but he left out what I referred to as the post processing. first tranlate to (x,y,z), rotate, then translate to (-x,-y,-z). This puts your rotated vector back in its proper place.

There's an extremely easy way to do this....

I like that, but it only works if the velocity vector is the axis of rotation. There is no reason to assume in advance that a torque applied to your object will rotate the object about the velocity vector. The axis of rotation can point in any direction depending on where the torque is applied on the object.

[Silvercord]

grady, I'm just wondering, have you ever programmed anything? If so, post it. Otherwise, I'm just going to continue ignoring absolutely everything you say.

[EvBladeRunnervE]

I am trying to program up Rotation code for the purpose of rotating the view vector of a camera, unless one could use a combination of Translating and rotating to do that.

[Bubba]

void Translate(double dx,double dy,double dz)
{

double trans[4][4];
double result[4][4];

trans[0][0]=1.0;
trans[0][1]=0.0;
trans[0][2]=0.0;
trans[0][3]=dx;

trans[1][0]=0.0;
trans[1][1]=1.0;
trans[1][2]=0.0;
trans[1][3]=dy;

trans[2][0]=0.0;
trans[2][1]=0.0;
trans[2][2]=1.0;
trans[2][3]=dz;

trans[3][0]=0.0;
trans[3][1]=0.0;
trans[3][2]=0.0;
trans[3][3]=1.0;

MatMult(trans,master,result);
MatCopy(result,master);
}

//Would be faster for one-dimensional array
void MatMult(double m1[4][4], double m2[4][4], double r[4][4])
{
for (int i=0;i<4;i++)
{
for (int j=0;j<4;j++
{
result[i][j]=((m1[i][0]*m2[0][j])+(m1[i][1]*m2[1][j])+(m1[i][2]*m2[2][j])+(m1[i][3]*m2[3][j]));
}
}
}

void MatCopy(double source[4][4],double target[4][4])
{
for (int i=0;i<4;i++)
{
target[i][0]=source[i][0];
target[i][1]=source[i][1];
target[i][2]=source[i][2];
target[i][3]=source[i][3];
}
}



This is part of my DOS 3D engine setup. Now OpenGL and DirectX both do this stuff for you. Before you transform your object - translate it to where you want it. Then rotate it and transform it.

The -x,-y,-z comes into play when you wish to move your player through the world - translate all objects by the negative vector of the player.

[Bubba]

I'm just not sure what you are asking. I thought you were trying to rotate an object around a certain point.

Rotating the camera view vector and rotating an object around a set point are two different things.

[EvBladeRunnervE]

Rotating the camera view vector and rotating an object around a set point are two different things.

I've been needing both...

the question is, is there any advantage of making one's own rotating function(for rotation around points) over using glRotate3f()?

[Bubba]

You do not need a separate rotation function for rotating around points.


Here is what you need to determine:

In your world, what objects need to rotate around certain points?

Create a base class for this type of object that will auto-translate them to their correct position in local space and then derive from this class.

I have no idea as to your structure for vertexes, polies, complete 3D objects, etc.

[EvBladeRunnervE]

So your saying for each object, have a center point for which the rest of the object is placed in relationship to it?

[Bubba]

Essentially, yes, but you do not need a function to do this. Simply translate the entire object by the distance you want. Remember that the points are already correctly translated with respect to the origin of the object.

Imagine adding 100 to every x component of your vertexes. Those at -10 would then become 90 and those at 100 would then become 200. But the distance between them remains the same - the object is still intact.

You arm is correctly translated in relation to the center of your body. No matter how you rotate yourself or move, your arm should always remain relatively in the same place - given that you do not move it.