Once more just for my tired mind to reiterate, each of those vertexes on the "sphere" is a point that gluLookAt can point to in order to move the viewport around.
Anyone, hope you understand, very tired, I want to sleeeeep.
Thank you muchos.
Camera Idea
Author
Hey Gamedevers - Getting ready to go to bed and I was thinking about creating a camera class - Thing is, I've never done it before, and havn't researched it much.
However, since I am going to bed right now, I thought I'd post this idea that I have in order to make a camera and see what you guys think about it when I wake up. If I am just totally missing something, feel free to point it out and point out some recommendation :)
Anyways, the basic summary of my incomplete idea is this:
Imagine a sphere of vertices around the player, now imagine that each vertex is a point that can be given to gluLookAt(...) in order to move the camera. So if the player moves the mouse to the left, it moves to the points to the left, and if the camera is moved right, it looks at the points to the right.
Here is a sphere I generated using sin/cos awhile back, it gives a vague idea of what im trying to aim for:
Once more just for my tired mind to reiterate, each of those vertexes on the "sphere" is a point that gluLookAt can point to in order to move the viewport around.
Anyone, hope you understand, very tired, I want to sleeeeep.
Thank you muchos.
Once more just for my tired mind to reiterate, each of those vertexes on the "sphere" is a point that gluLookAt can point to in order to move the viewport around.
Anyone, hope you understand, very tired, I want to sleeeeep.
Thank you muchos.
Is this camera for a first-person or third-person game? If it's the former, then I think it's quite OK, but you have to totally revise it if it's the latter (in that case you must move the camera around the player so the 'center' will remain same while the 'eye' changes position).
I'm guessing that all the sin/cos stuff was to make your idea clear - if it was then it's all good. But I just want to point out here that the actual implementation would be very easy if you just keep track of the player's position and direction with vector's. Then the vector you pass for gluLookAt's 'center' coordinates would be player.position + player.direction * factor, 'eye' would be player.position ... and you'd be done!
I'm guessing that all the sin/cos stuff was to make your idea clear - if it was then it's all good. But I just want to point out here that the actual implementation would be very easy if you just keep track of the player's position and direction with vector's. Then the vector you pass for gluLookAt's 'center' coordinates would be player.position + player.direction * factor, 'eye' would be player.position ... and you'd be done!
Author
Lol, to be honest - I had never looked at the gluLookAt function before so I didn't know what was required to make it point at a particular position. However, that looks to be very easy :)
What about when I push the "moveForward" button, Won't I have to use sin/cos to give what direction is really forward?
What about when I push the "moveForward" button, Won't I have to use sin/cos to give what direction is really forward?
I'm not too fond of the idea, really. It seems like you're restricting your camera rotation to an arbitrary grid, that you then have to store somewhere.
I find it a lot easier to store camera rotation as Euler angles, and just update them as the camera changes orientation. Every time they change, create a new view rotation matrix (yaw-pitch-roll order works well). Multiply by the camera-space basis, and extract your forward, right, and up vectors. I clamp the pitch to [-89°,89°], which seems reasonable for most games (except maybe flight simulators).
I find it a lot easier to store camera rotation as Euler angles, and just update them as the camera changes orientation. Every time they change, create a new view rotation matrix (yaw-pitch-roll order works well). Multiply by the camera-space basis, and extract your forward, right, and up vectors. I clamp the pitch to [-89°,89°], which seems reasonable for most games (except maybe flight simulators).
Going ahead with my vote of using vectors, the only thing you need to do is create a functions that 'rotates' your vector about an arbitrary axis. You could do this using quaternions or matrices, I have such a function of my own - if you care for it just holler.
When the user moves the mouse, rotate the player.direction vector, and your simple camera class will take care of the rest. When he moves forward, player.position += player.direction * dt, that's it ... and you update the camera position and direction as I mentioned in my first post in this thread.
I don't want you to get biased or anything - this is just the way I do it, but I can guarantee you this - it works and it's pretty easy.
When the user moves the mouse, rotate the player.direction vector, and your simple camera class will take care of the rest. When he moves forward, player.position += player.direction * dt, that's it ... and you update the camera position and direction as I mentioned in my first post in this thread.
I don't want you to get biased or anything - this is just the way I do it, but I can guarantee you this - it works and it's pretty easy.
To elaborate on what we discussed last night --
A good compromise is to store the 4 primary vectors of the camera -- look, up, right, and position. (Right can and will need to be regenerated every time these vectors change. Also, the look vector is not the look-at vector.) Then you can very easily build the matrix and pass it to OGL. Actual manipulation of the camera involves a number of matrix constructions and rotations, mainly constructing matrices to rotate the primary vectors around axes. You can have relative and non-relative rotations around world, local, and arbitrary axes very easily this way, along with absolute and relative movement.
A good compromise is to store the 4 primary vectors of the camera -- look, up, right, and position. (Right can and will need to be regenerated every time these vectors change. Also, the look vector is not the look-at vector.) Then you can very easily build the matrix and pass it to OGL. Actual manipulation of the camera involves a number of matrix constructions and rotations, mainly constructing matrices to rotate the primary vectors around axes. You can have relative and non-relative rotations around world, local, and arbitrary axes very easily this way, along with absolute and relative movement.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
