Jump to content
  • Advertisement
Sign in to follow this  
AfroFire

Camera Idea

This topic is 4606 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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!

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!