Archived

This topic is now archived and is closed to further replies.

MARS_999

camera height and world coordinates

Recommended Posts

I am trying to figure out how I am to keep track of my height coordinate at any given location on the screen. Problem is when I rotate the camera my x,z coodinates become hosed. Lets say I am at terrain[512][256].y which is my height value for that location of x,z and I rotate on x and z how am I supposed to know on my 2D grid where I am now at for that y location? The only way I can think of is locking the camera from rotating but what good would that be in a 3D game? That way I would know x,y,z values because the user wouldn''t be able to rotate. Thanks for any help.

Share this post


Link to post
Share on other sites
thats the perfect time to start and seperate graphics from game. your position is your position and the camera has nothing to do with it. but without knowing how you do it and where you store what its hard to help.

in general: try and do as much of your app/game without even touching opengl/d3d.. game logic has nothing to do with display and it shouldnt matter if you rotate or not, if you use 2d, 3d, 5d or ascii output via console.

Share this post


Link to post
Share on other sites
Well, since you know "I am at terrain[512][256].y " it seems to me that if you move your camera, with or without rotating, you will eventually be at terrain[x][z].y, where x and z are known.

The heights for your terrain can be kept in a table or a bumpmap or stored by any other convenient means.

I tend to use bumpmaps with sizes [256][256] and heights [0..255]
and, if I want to stay accurate while between the main grid points, I can do a linear interpolation.

This is, of course, only one method to do what you want.




Stevie

Don''t follow me, I''m lost.

Share this post


Link to post
Share on other sites
stevie I am doing pretty much what you are doing. I use a grayscale image and map my terrain out with that. I have the entire map stored in an array. I guess now that I think about it, my units are the only ones that need to know where x,y,z is at. And so do the weapons for accurate firing. The camera can look any direction it wants to. I was just trying to have the camera follow the terrain on the Y axis so the user didn''t have to move up and down. But I am thinking I will lock the camera at a certain height and allow rotating and panning on z and x. Is this a good way? Thanks

Share this post


Link to post
Share on other sites
Ok new question. After I rotate the camera how do I overcome the problem with when I press to move -x I all of a sudden move -z, because I rotated my screen? I guess what I am asking is how do I keep my keys locked into always representing left,right,up,down no matter what the screen has rotated to? Thanks

Share this post


Link to post
Share on other sites
not exactly sure how you''re set up, but ill assume you have something like:

float camera_focus_x , camera_focus_y;
float camera_rotation; //side to side angle
float camera_attack; //up/down angle

where these represent the xy (or xz for you) coordinates of the game world focus. And If I read right you want the view to move to the left/right/front/back relative to the camera. You can use basic trig to change x/y correctly:


#include <math.h>

float camera_focus_x , camera_focus_y;
float camera_rotation; //side to side angle

float camera_attack; //up/down angle



void move_camera_forward( float distance )
{
camera_focus_x += cos(camera_rotation) * distance;
camera_focus_y += sin(camera_rotation) * distance;
}
void move_camera_left( float distance )
{
camera_focus_x += cos(camera_rotation + PI/2) * distance;
camera_focus_y += sin(camera_rotation + PI/2) * distance;
}
void move_camera_right( float distance )
{
camera_focus_x += cos(camera_rotation - PI/2) * distance;
camera_focus_y += sin(camera_rotation - PI/2) * distance;
}


note: rotations assumed to be in radians, and ''left/right'' are assumed to be sidesteps, instead of rotations.

Also note: this is horrible code, not using OOP, and preforming an un-necessary add/subtract for the sidestepping that could be taken out using basic trig rules again...

aka:
cos( x + PI/2 ) == -sin( x )
sin( x + PI/2 ) == cos( x )
and so forth.

Share this post


Link to post
Share on other sites
if your camera can only rotate left/right and your store the angle then sin and cos will work fine. still i prefer to have the camera as just another object. you need to store your orientation in a convenient way, so i usually use a transformation matrix, because:

-its nothing but right/up/forward/position vectors telling me everything i usually need (for example which direction is "right" with my current rotation)
-depending on your api you can let it handle rotations (hoping for better optimized functions that one would write himself)
-setting up the view is just a matter of transpose and three dot products.

as long as your camera motion is limited (only rotating left/right or rotating left/right around global y and up/down around local x) you might get away with just storing angles.

Share this post


Link to post
Share on other sites