Skip to main content
GameDev.net gamedev.net
🔒 Locked

Outdoor level rendering/management

Started by Structural Jan 21, 2003 at 3:15 AM 5 replies 300+ views
Original Post
Structural
Structural
I''ve got this neat idea for a game in the back of my head, but it requires me to render a big outdoor level. I have never written a landscape generator or heightmap loader or anything like that, so I''d like to inform what techniques are often used in rendering and managing outdoor levels. I''d like to know what I''m getting myself into before I start cursing and hitting my computer screen if it doesn''t work I''ve just read the "is BSP dead?" thread and the term quadtree caught my eye. I have a basic idea what it is, but is it used a lot in outdoor levels? If so what for? For rendering or actor-management? Are the quadtree sections a static size? What techniques are used for occluded terrain culling? Or do you render everything up to a certain distance and have the API handle the culling? Any tips/linkage/answers are very appreciated Thank you!
STOP THE PLANET!! I WANT TO GET OFF!!
d000hg
d000hg
Hey there. I differ slightly from the last poster''s thoughts but only in detail.
Here are some thoughts...
1)A basic landscape is easy to render - just a 2d array of vertices at different heights, where you store the heights as a bitmap or some other way.
2)The sizes of the polygons are NOT normally 32 - in fact the spacing between vertices makes no difference as you can scale them to whatever you want - I use the distance as a value in metres and have points at 1m spacing.
3)Both quadtrees and Octrees are popular. A quadtree divides the map into 4, then each part divides into 4 and so on until you get to a region of the map which is some size e.g 16x16, 32x32, called a leaf - the leaf stores a small section of the map. This means when you render you quickly find out which sections need drawing. An octree is the same idea but you divide a cube into 8 so you divide the map by volume rather than area. I assume which is best depends on how flat your maps are.
4)Typically the quadtree sections (I''d recommend this not octreee personally) are static size but they don''t have to be. For instance you don''t have to have each section having 4 children - if there''s nothing in one section (ie your terrain is not square) you can leave it empty. You can also keep subdividing different sections to different levels so not all leaves are equally big, if you can think of a good reason to (I''d avoid this initially though but maybe leave the design open to this possibility)
5)LOD is typically used to decide for each leaf in view, what detail to draw it at. This choice can be done in different ways, the main problem is where two leaves join it must be at the same detail or you get nasty gaps, so you need to make the rendering code more complex.

I''d advise initially making a quadtree but drawing everything, then do quadtree culling, then lastly implement LOD.
Other occlusion techniques exist but they are a lot more complicated and you''ll probably find you don''t need them. You can also stop drawing leaves which are far enough away - it''s noticeable but not if you introduce a bit of fog.

Helpful?



Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor



John 3:16
Structural
Structural
Thanks, I got quite a few answers here...
A bit of a technical question:
How do you split up the leaves of the quadtree? Do still keep your 2D array, and do you determine each leaf by the index of the array (leaf 1 starting at [0][0], leaf two at [0][10], etc) of do you sort them in a particular way? each leaf in it''s own array for example.
STOP THE PLANET!! I WANT TO GET OFF!!
d000hg
d000hg
Well It depends. If your map is always going to be small enough to fit all of it in memory, then keeping your heightmap as one big 2D array makes access potentially easier (checking the height at (x,y) is much easier this way). However if you want really big terrains then you''ll need to keep loading different sections of the map. Now it makes much more sense to store each leaf (or maybe a small quadtree which is a sub-level of the map but still contains 4 children each with 4 leaves for example - so you don''t have too many sections to keep loading) somehow with it''s own minature heightmap so that you can load one part of the map without having to check which other bits are loaded. You''d have to make sure not to call GetHeight() for somewhere not loaded, but since you only load the sections you need that shouldn''t be a problem.
Structural
Structural
Thanks d000gh...
I shall continue my questioning
I have also been looking at collision detection with terrain.
I have read on OpenGL.org that a common way of detecting an objects collision with the terrain is checking a point of the object against the y-value of the array entry that the point is over. Now, to smoothen this detection I read about interpolating the points around the collision point, and checking it then. How accurate is this?
More over, how do I interpolate? I do know what it is, but do not know a formula.

Another thing, is it common to smoothen the terrain amongst points between the array entries? Or does is each entry exactly one vertex?

To summarize:

1) Is interpolating for collision detection accurate?
2) what is the formula for interpolating four (or three) points?
3) Is it common a terrain is smoothed between the array entries?
STOP THE PLANET!! I WANT TO GET OFF!!
d000hg
d000hg
Well, I''ve not implemented collisions yet so on accuracy I''m not sure. Also, do you mean linear interpolation (drawing a plane between the 3 points of a triangle) or higher order (finding a curved surface that fits well over the points and smooths out the boundaries)?

The latter is more taxing but certainly possible, it''s much more computationally expensive too. For the linear version you just find the plane eqn for the 3 points of the triangle and stuff in the x/z coord to get the height.

Feel free to email me if you have any further questions.



Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor



John 3:16

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.