PDA

View Full Version : Terrain Scale Recommendation



IndioCOLIFA
12-28-2007, 01:52 AM
I've developed small OpenGL applications in the past but my ambition now is to generate a terrain to place some objects on it (trees, buildings, etc).

I want to know which scales are you using on your terrains for displaying objects accordingly or what methods are using (glScale ?)

At last, what is the fastest manner to throw a detailed terrain geometry to the card? VBOs?

Thank you very much.

zed
12-28-2007, 02:46 AM
(btw im ignoring LOD)

scale depends on the terrain size u want to display, a reasonable number of verts displayed per frame for terrain is perhaps a million thus ~1000 x ~1000 verts (of course if u gonna have trees etc then u may want to reduce this number)

divide the 1000 verts by view distance eg 10km == 10meters between the vertice spacing

for performance the most important, is to subdivide the terrain up into smaller terrain blocks/patches eg each patch consists of 65x65 vertices (thus the whole terrain has about 16x16=256 patches) stick a bounding box around each pathc + each frame only draw the onscreen patches.

each patch can be stored as a VBO or DL or a VA

Zengar
12-28-2007, 02:46 AM
Why would you need glScale? Just draw the terrain and align the objects to it's surface. There are different methods of drawing the terrain, it mainly depends on the needs of your application. Clipmaps are nice, but would ideally require vertex texture fetch. Otherwise, a brute-force approach works just fine with modern cards, if your terrain isn't to large. With heightmaps, you may use a "working set" (for example, a 256x256 field that is maximally visible from any camera position) and just render it as one batch, updating the VBO as your camera moves.

Edit: zed was faster :)

IndioCOLIFA
12-28-2007, 10:22 AM
The approach i'm taking is:

1. Generate a 1024x1024 surface heightmap painted with some fractal terrain algorithm.

2. Build up vertices from the bitmap.

With this I've 1 MB vertex data (I should decide on vertex separation).

Now my question is suppose I give the user the option "Terrain Geometry Quality" : HIGH and LOW. My approach is to generate also 512K or 256K terrains and use a *2 or *4 vertex spacing respect to the original 1MB vertex map (this way the terrain aspect should stay similar but at lower resolution).

I don't know if this is a good approach, it's the first idea that comes into my mind.

k_szczech
12-28-2007, 12:39 PM
It all depends...

My terrain has size of 2048x2048 texels, so I have over 8M polygons (triangles). I'm using nested grids at different level of detail. Runs fast even on old hardware.

Using just one level of detail over entire terrain wouldn't work too well. My far clip plane is 2,5Km away, but I intend to move it further away since high mountains look bad if they fade into fog in front of distant clouds.

This means I can now see about 250000-300000 polygons at a time. I need to render that 3 times per frame (water reflection and refraction). That would give up to 1M polygons per frame. If I move that far clip plane away, things would get even worse.

If my terrain was 512x512 then I would use just one or two levels of detail with frustum culling, but the thing is, once you get it running with dynamic LOD, you can use it for whatever you want.

What's my point?
Even if your grid is only 512x512 and you're running on modern hardware, it's still good to put at least some sort of dynamic LOD there.
With fixed LOD I couldn't even think of moving that far clip plane 2x further because that would increase polygon count 4 times. With dynamic LOD I can move it 10x further and I pay only 15-20% of performance for that. And at close distances I get full detail (like my grid was 2048x2048).

One thing we shouldn't do is to get used to wasting computing power :)

Korval
12-28-2007, 04:59 PM
dynamic LOD

Define dynamic LOD. Do you mean where you generate the terrain every frame from an internal representation, or something where you simply swap meshes for distant portions of the terrain?


One thing we shouldn't do is to get used to wasting computing power

Not should we spend it frivolously. Less computing power means more people who can run the software.