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
Shouldn’t you be more worried about the first 3 arguments?
They are the ones that determine the direction you look at.
Only thing you can do with the 4 till 6the argument is determining the camera position.
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.
Meh it works in Game Maker. If that does work what will? Or can I at least get the name of the camera system I am trying to form.
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).
First Person viewpoint
keep pitch_rot between > -90 && < 90 / -PI -> PI
dir.x = ( sin( heading_rot ) * cos( pitch_rot ) );
dir.z = ( cos( heading_rot ) * cos( pitch_rot ) );
dir.y = ( sin( pitch_rot ) );
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?
you should add this direction to your eye position to compute the “lookAt” point :
gluLookAt(eye_x,eye_y,eye_z,eye_x + dir.x,eye_y +dir.y,eye_z+dir.z,up_x,up_y,up_z)
After all, you want to look at a point which lies from your eye position in the direction ‘dir’.
thanks to babis, this is what I currently have:
dir_x = (sin(yaw)*cos(pitch));
dir_y = (sin(pitch));
dir_z = (cos(yaw)*cos(pitch));
Ok I test it out and yaw (or the horizontal direction seems to be working fine but pitch isn’t working right. Notice anything that I am doing wrong?
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?
editing at the same time can be a problem, see my previous edit
never mind I got it, the problem was that I didn’t add the height of the camera to the centerY part. Thanks for the help, that was a major help
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?
“Also one more thing : You’re setting up the camera in Modelview matrix & not in projection, right?”
nope I no better than that I edited that post above, I was able to figure out the issue myself. Thanks for your help
glad it worked . If you are using the projection for the camera, read this http://www.sjbaker.org/steve/omniv/projection_abuse.html