camera height and world coordinates
Author
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.
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.
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.
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.
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.
Author
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
Author
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
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:
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.
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 anglefloat camera_attack; //up/down anglevoid 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.
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.
-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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
