Thread: Problem with my rotation code?

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 ε=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 ε 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 θ.

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

Oops, 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 θ from the velocity of a vertex and another vector sounds useful.

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

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:

Code:

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

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

Code:

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.

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

Code:

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.

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.

Code:

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

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.

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?