I have been trying to devolve a system for a 3d game that will allow direction like in a fps. I have been able to get some of this done myself. The code below is part of it, the only thing I am having issues at it xto,yto,zto (the 4th, 5th, and 6th arguments in the function). I understand what they do in code but I have no idea how to use them to setup a 360 direction system. The code below is a test code I setup and I was wondering if that was a smart way of doing it. If not can anyone lend a idea. Thanks
Actually the first 3 arguments set the cameras location, the next 3 are the x,y, and z of where the camera is looking. For a while I have been using a code like this:
The problem with this code is that it has no direction to it. It used the variables eye_z, eye_y, and eye_z to choose the point at which the camera is looking. What I need is a step up from this kind of code, one where the cameras 360 direction is set on a variable. In other words a first person shooter style of camera. Any idea what I would need to look into to do this?
Why wouldn’t you keep a direction variable, and then add it to your eye position to find where the camera is looking? There are tons of tutorials for cameras on the net, you could check some out.
Assuming the camera angle of zero corresponds to the (0, 0, 1) direction vector; you can get the direction vector by rotating (0, 0, 1) x degrees around the up vector (0, 1, 0). The camera target is then simply camera position + direction (or compute the camera matrix yourself – see gluLookAt documentation for formula).
So pitch_rot would be for vertical direction and heading_rot is for horizontal rot?
Also how exactly would I put this into the function gluLookAt? Would dir.x, dir.y, and dir.z go in for centerX, centerY, and centerZ of the function gluLookAt?
What’s the pitch problem? remember that you have ‘stuck’ the up axis with 0,1,0, so you should expect some degenerate cases when 2 axes become almost colinear.
Edit : also make sure your pitch value is from -0.5PI to 0.5PI. To avoid the extremal cases, you can replace 0.5 with 0.4 or sth like that.
I was increasing a decreasing the variables by .1 so any change I noticed. Ah what happened when I increased or decreased the pitch was that it would move a little up, stop start moving in the other direction a very little bit then reverse.it looks kind like a nodding motion. The variables are changing at the correct rate so thats not the issue. Ah if their is another part of my code you need to see what is it?
You can stick your up axis to (0,1,0), if you don’t need some strange rotations, or to look straight up or down, which are of not much use for an fps camera anyway, so it’s ok.
The yaw & pitch are expressed in radians (you’re using sin & cos after all). For the pitch, you need to clamp your values to the ones I specified above.
The dir computation zed wrote is actually the computation of a point on the unit sphere, using spherical coordinates ( read this : http://en.wikipedia.org/wiki/Sphere )
Also one more thing : You’re setting up the camera in Modelview matrix & not in projection, right?