I'm going to write a function for the distance formula to find the directed distance from the center point, to the object, then I can write a function that calls these two express any points coordinates in referance in polar form only in relation to any center point you chose, rather then just the origin. The primary purpose of this will be used to rotate a point around an axis (the center) by first converting to polar form, adding or subtracting the angle of rotation, then converting back to rectangular from to get the new coordinates of the point.

Great minds think alike. But I have my reasons. I already have a class "point" with x,y,z member data. But this polar angle function is going to be used not just on the x,y plane. Its going to be used on x,z plane, a y,z plane, as well as the x,y plane. So if I use x and y, in somecases I'd have to use y, for x, instead of y, for y. The same reason why I didn't pass in "points" as arguements. Because sometimes I'll be using only their y,z coordinates, other times their x,z coordinates, etc. There is probably a simple way to do it with points but I haven't thought of one yet.

I'm writing a math program to calculate the location of a point (on an x,y plane) based on its x,y, z coordinates, the observers x,y,z coordinates, and the angle at which he's looking. Basicly I'm reinventing the 3d engine myself, trying to figure things out on my own. I've heard real 3d engines just use matrices but my system seems to work anyways.

Your object and origin suggestions are good, the only reason I didn't pic "origin" is because that usually means 0,0,0.

Well I guess I could just take the sine of the complement angle since thats what cosine means and the sine function appears to be working fine. (I call this sort of thing "humoring the computer")

Last edited by mikau (2005-10-11 09:49:41)

It would be much easier (and clearer) to just pass in points as arguements, rather then having to individually pass in horizontal and vertical coordinates. But then I'd have to define a new function for every plane. xy, xz, yz. I wonder if it would be worth it...

If C++ doesn't have a ready-made function for that (it really should), here's a half-baked algorthm for rounding.

First, I can't remember how C++ handles rounding when you assign a float to an integer; I think it truncates rather than rounds. If so, the algorithm (in psuedocode) looks something like this:

float number;  //The number to be rounded
p = 5;  //The precision to round to

float bumper = number * 10^p;
int chopper = (int) bumper;
int tester = (int) (bumper + 0.5);

if (tester > chopper)  { float roundedNumber = tester * (1/10^p); }
else  { float roundedNumber = chopper * (1/10^p); }

Again, my idea of C++'s rounding behaviour may be off, but I think you get the idea.

It's probably possible to do the same thing using bitwise wizardry, and such an approach may be simpler. But it would be a lot harder to implement and understand. Take your pick.

Sorry mikau, I lost track of this conversation.

How is it going now? Post code and problem if you can.

Yeah, I doubt that, with screen resolution being what it is, you'd have much of a problem.

It occurs to me that you might try writing it to the precision storable by an unsigned double. That's the ceiling on the precision of your program, right? So that should make it come out zero? I may not understand the issues but it seems reasonable to me.

Hey, wait, I was wrong--radians will not always be positive in the important physical sense of direction of motion...

(edit) oops! Wrong thread! x_x

Last edited by mikau (2005-10-17 12:55:27)