4-way scrolling landscape in orthographic view
Blitz3D Forums/Blitz3D Programming/4-way scrolling landscape in orthographic view
| ||
| I am trying to scroll a landscape in 4 directions. It has orthographic view and a fixed camera, so no perspective and only land is visable. Each triangle (of a single surface mesh) represents a point in a wrap-around map, so I can only show a fraction of the whole thing. Now, how can I figure out wich triangles scroll in view and wich ones scroll out? I have tryed using camerapick and pickedtriangle, but that was too slow. I was thinking of calculating the shape and position of the triangles in 2D and than "plotting" them in 3D but that's even more mind-boggling. Any suggestions anyone? |
| ||
| Not sure what you want but one way would be to keep the entire landscape height & colour for each triangle or quad in an array. Then have a surface (of maybe 32 by 32 quads) onto which you copy the required information to. Set your camera to view this surface. Marg |
| ||
| Now, how can I figure out wich triangles scroll in view and wich ones scroll out? You check each vertex. TformPoint the vertex to world space, then CameraProject the resulting coordinates. If ProjectedX and ProjectedY are positive then this vertex is on screen. Each triangle requires three Vertices, so any one of those 3 is on screen then the triangle is visible. You may be worried about how many verts you need to check at any one time. This is where a lookup table can help as you can divide the camera x and z into a lookup table and return a list of verts that you need to check in the local area. But this step probably isn't even needed. |
| ||
| Great! This is very, very helpful. I'll try both methods. Just for the sake of argument: could the opposite of Rob's method be done? So, instead of checking the three vertices in 2D, calculate three points in 2D and then project them into the 3D-world. |
| ||
| For the sake of argument. No. ;) However.... ghalfwidth=graphicswidth()*0.5 ghalfheight=graphicsheight()*0.5 screenX# = CameraX*(ghalfwidth*Camzoom)+ghalfwidth screenY# = -CameraY*(ghalfwidth*Camzoom)+ghalfheight CameraX# = (ScreenX - ghalfwidth ) / (camzoom * ghalfwidth) CameraY# = -(ScreenY - ghalfheight) / (camzoom * ghalfwidth) Note: when I say cameraX and cameraY I mean the location in camera space, not the location of the camera, and of course you need to supply Z yourself. Depending on how you set things up you may need to tform from worldspace (or indeed objectspace) to cameraspace and vice-versa. If do not rotate or move the camera then I think the above will be to and from world space. Not extensively tested though, I do not use ortho mode much. This is based on the observation that you get a 1:1 correspondence between cameraspace and screenspace resolution if camerazoom is set to 1.0/(Graphicswidth()/2). |
   |