OSDev.org

What I'm saying is, I don't see how this code provides any rotation. Maybe it works for small angles (since, for x in radians, and for small values of x, sin(x) = x) but I don't think it will in the general case.

You probably missed the point, but here it is:

(The game's angles are - so they are opposite)

If rot.y is 0, then you move foward 1, and 0 to the side. If rot.y is 90, then you move foward 0, and 1 to the side. With that in mind, you can see that there is a pattern of 90's. BTW, the problem I was having is not my code. I isolated it to the Dev-C++ OpenGL code's pixel descriptor. It's something to do with it. Nehe's is bloated so I don't want to use that one.

I see. So you're effectively interpolating between a right vector and a forward vector. If you plot this on a graph (i.e. x and z for values of y), you'll end up with a diamond shape instead of the circle you'd get if you used sin and cos. If this is enough for you (and there's no point doing too much work if it is) then fine, just don't expect to be able to do true rotations using this method.

Yup, you've got it. But don't worry about the diamond rotations. I will divide the 90 into 45 so it is more smoother. I fixed the big problem of the day, the vertices no longer disappear. My method seems to risky because when I divide the stuff by 2 getting 45s, I will have 8 degrees then. But that still won't be enough so I will keep dividing till I get 360 degrees summed up in 32 degrees. At this point, I rather use a Look Up Table. So, does anyone have a tested LUT? I would really appreciate it. Some things one person just can't handle...

For the people who prefer sin/cos, I will need full rotation of axis. X, Y, AND Z too. Using cin/cos causes the Gimble Lock problem.

Quaternions.

Actually, I don't think you will be calling sin/cos often enough for it to make an impact on performance. What you can do is store your rotation in a transformation matrix; that way, you call sin and cos once each when the x/y/z rotation changes, then on each frame you multiply your vector by this matrix. I mention quaternions because they can store a full rotation without gimbal lock, and you can convert a quaternion to a matrix.

*interested* gimbal lock? The way I understand it from google, it's where two axis' overlap but isn't that just a 2d representation problem? Won't you still know where everything is in your 3d representation?

- Nick

Wrong, you deal with the 2d axis (x+y) and z when you do 3d. So you have the same problem, but more complex. I am resorting to LUTs. Anybody want to help out. On google, I just find some other LUTs.

BTW, gimbal lock and LUTs/sin/cos are two separate issues.

Gimbal lock is restricted rotation which occurs only when you apply the x/y/z rotations one after another, and can be fixed by representing rotations as quaternions. A quaternion is defined by an axis (represented by a vector) and a rotation around that axis.

A lookup table is a faster way of obtaining the sine or cosine of a limited set of values. An LUT gives approximately the same results as the real sin or cos functions but potentially a lot faster.

Tux: I believe your method of obtaining rotations is flawed as it is now, and will approximate sin/cos as you improve it. I predict that, as you refine your functions, they will evolve into the Taylor power series approximation of sin/cos.

I have been coding crazily at the rotation math. My function if improved like you said, will get better. The main problem is that it will have the same result as a LUT, but slower. And the quaternion suggestion, I have given up on it. I went to nehe.gamedev.net and I checked out the examples. They use vectors to every object. Sorry, but I am not looking to clog my code.

As somebody who writes 3D simulation software for a living, I believe that you are wasting your time trying to find replacements for basic trigonometric functions. Everybody else uses vectors, matrices, sin/cos and quaternions for a reason.

I don't understand much about this vectors and math stuff (but did some googling about it ...) It seems to me that it is nowadays a little bit irrelevant to bother about some more layers of code to ease life afterwards, due to the power of nowadays processors available for home use.

I doubt that a solution working with vectors is THAT slow and THAT clumsy to avoid it under all circumstances. I'd research further on them and use them as well as those quaternions. Fine tribbles they are in my opinion. Not even the best approaching and fine-graining of "diamond shaped rotation algorithm" which avoids trigonometry can reach the EXACTNESS you want to have.

So either build an internal LookUp Table or work with the quaternions, those neat tribbles. I don't work as a 3d-programmer, but I 'am sometimes busy with 3d animation and modeling for I am an artist and train my brushes that way. I know what curse a weird coded 3d simulator can do to someone.

Do theeself a favour: accept sinus/cosinus as your friends

I think you answered the question to why I am not using vectors or quats. I been trying to understand them since the first time I tried game dev. I hate vectors because you have to add extra values on models and objects to make the whole thing work. I also think that for newbie's, it is discouraging to see something like that. Just from my experiences I am saying all this.