Terrain Screenshots

Screenshot 1 - The terrain as it stands.

Wireframe shots of the LOD when it was using the bintree algorithm that ROAM uses. I switched to using D3D PMesh simplification (it''s less restricted and I didn''t have to write my own!)
Screenshot 2a - Lowest detail
Screenshot 2b - Not-quite-lowest detail
Screenshot 2c - Little-higher-than-not detail
Screenshot 2d - High-as-a-kite detail

Screenshot 3 - Single texture, looking into sun.

These are an old screenshots. I''m working on a totally different way (non-heightfield based) of doing terrain than that, though, so it''s not very representative of what my terrain will end up as. But it''s a semi-decent screenshot.

I hated the texturing in it, though (hence the name of the first URL).

A quick rundown of what''s in that shot:

1. Geo-mip mapping (or geomorphing or Chunked LOD, I don''t remember which technique it is -- the one with the quadtree of levels). However, I used a different breakdown of LOD detail (I didn''t break it down regularly, instead I used the Progressive Meshing algorithm to remove the least-different points).

2. Sky generation - it actually looks pretty good, though not necessarily in that screenshot. No clouds yet, though. Done according to the Preetham paper, though I had to do tons upon tons of tweaking to get it right.

3. Huge draw distance - I''m going for 2 km (1.2 miles) draw distance.

The only problem with the terrain (Besides the heightfield limitation) is the sheer size of it. It''s HUGE on-disk. But it DOES take a full 5 minutes to get to the far side of it.

That''s all. Enjoy


---

Actually, to answer the questions you asked:

1. Terrain Texturing Tutorials (say it 5 times fast!) - Uh. Well, There are a few on the Gamedev.net resource page. Try there.

2. There are som LOD tutorials at that site as well. Here''s a ROAM tutorial for you. You have to register with Gamasutra, but it''s free. And there are tons of articles on terrain there too.

3. Uh, I do google searches for "free terrain textures" and look through page after page until I find some. But eventually I''m going to wander around the greater Indianapolis area with a digital camera and take pictures of the surface types I need, and make them tileable in Photoshop.

4. Done already


Okay. This time, that''s really all.


I think.

just something about lod and hardware.

i prefer geomipmapping so far, but you usually just find the "common" way of spliting your quads into 4 smaller ones.

-----
|  /|
| / |
|/  |
-----

-----
|/|/|
|---|
|/|/|
-----
  

that means every lod step means 4 times or a 1/4 of the geometry. didnt like that, so... they typical diamond-whatever-its-called way can be used.

----- -----
|  /| |\ /|
| / | | | |
|/  | |/ \|
----- -----
-----
|\|/|
|-|-|
|/|\|
-----
  

so now each step will only double or half the number of triangles and in theory youre more likely to get away with a lower lod.

geomipmapping needs linking pieces (i dont really like the skirts solution). actually you can use the same like for the "normal" approach, as as you can see two lods (1-2, 3-4, 5-6,...) will always have matching edges.

for texturing a base map and 2-4 detail textures can already look quite nice. if you feel like burning a lot of fillrate you could either add normal maps for them or store a height map in the alpha channel.

random screens
screen1
screen2
screen3
screen4

screen5
screen6
screen7

dont take the last one seriously, nobody would brute force render a 4096x4096 terrain at highest detail (but its fun to see how many polys a rad9800 can push with cheap texturing).

[edited by - Trienco on May 30, 2004 4:54:57 AM]

Screenshot

That''s a shot from my old terrain engine. It was loosely based on the Gamasutra tutorial that somebody already linked to.

The texture is one large 4096^2 texture. It was created by blending 4 basic textures ( water, grass, mountain, snowy mountain ) into a single texture based on designer specificed height ranges. This was done offline.

Clicky
Clicky #2

Another old terrain engine. Covers 66x66km2 with per-meter detail using controlled noise (takes 6 MB in storage space ). It takes about 44 mins to go from one side of the map to the other with a car going at cruising speed. The terrain in the screenshot has a viewing-distance of 2 km I think. Uses a quad-tree with geomorphing and run-time generated chunks. Textured by having one grass texture, one rocky texture and one detail texture. The color textures are interpolated based on terrain slope only.

EDIT: As for other terrain resources, check vterrain's game-terrains page and search in the GDnet forums.

EDIT2: My hands are trippy...

[edited by - coelurus on May 31, 2004 5:24:52 AM]

[edited by - coelurus on May 31, 2004 5:25:39 AM]

i''ve posted these shots on other threads but as i''m quite proud of it i''ll post em again



another
and aother another

engine runs in d3d or openGL (currently openGL is faster, no LOD info in it yet planning on adding ROAM sometime soon. No sky yet but i''ve writen a perlin noise cloud program which i will make into a texture generator at some point i swear.

terrain rendering is a great place to start with graphics algorithms - i also messed around with a few some time back...

these are two screenshots from a roam-based engine i put together - of particular interest is the second screenshot, which shows a top view of the rendering.
its more whats not rendered that i find cool!

flymode
godmode

geniet!

---
craig(at)cod3rz(dot)net

Clicky

Its a geo-mipmapped procedural terrain. Pretty much infinite. ("Pretty much" because at the high range of floats things start to explode)

Gots trees, plants/grass, rocks...and Butterflies!

Waramp.

Before you insult a man, walk a mile in his shoes.
That way, when you do insult him, you''ll be a mile away, and you''ll have his shoes.

to drillian:

how big is that landscape? You said it takes 5 minutes to cross it.

I am doing an airplane simulator for fun and I was impressed with your screenshots. What technique do you use? I am using ROAM at this point but I got alot of problems with popping and huge cpu usage. Any suggestions?

And last but not least, how did you generate that sky? my sky it''s just a blue color and yours looks pretty nice. Any tutorials or code on that one?

Joaquin

quote:

---

Original post by creative1
I am doing an airplane simulator for fun and I was impressed with your screenshots. What technique do you use? I am using ROAM at this point but I got alot of problems with popping and huge cpu usage. Any suggestions?

---

I strongly recommend against using the typical ROAM error metric of checking the height of ''wedgies'' in screen space. The screen space projection costs way too much for reasonable sized terrains. What I am currently doing is determining likely error level in object space. If you take the ratio of distanceOfPlayerToNode-:-deltaHeightFromApexOfNodeToBaseOfNode in object space you can get a very decent looking LOD that requires ''much'' less CPU work.

I also recommend against using split/merge lists. I have had much better results using an exclusively split/based implementation.

As far as popping goes I tend to tweak the above object-space formula until popping is not really noticable. You could also simply smoothly interpolate the splits rather than immediately splitting.

haro,
can you elaborate a little more on that LOD formula?
I don''t think I understood what you meant.

Also, I forgot to mention that my implementation is ROAM 2.0 (not the old clasical roam).

Btw, for huge landscapes (i want to be able to fly for 20 minutes at least from side to side) do you think ROAM is the best or it will be too slow?

Right now in my p4 at 2.5ghz with radeom 8600 it works perfectly fine. But this is not a good ''testing'' system. When I move to a pentium 3 with an average card the simulator goes at the speed of a snail.

I want this to work in p3 computers and I thought ROAM 2.0 was the fastest. It doesn''t look like unfortunately.

Joaquin

quote:

---

Original post by craigatcod3rzdotnet
terrain rendering is a great place to start with graphics algorithms - i also messed around with a few some time back...

these are two screenshots from a roam-based engine i put together - of particular interest is the second screenshot, which shows a top view of the rendering.
its more whats not rendered that i find cool!

flymode
godmode

---

dude it has cracks in it

i would post some of mine but i don't have anywhere to host the images

as for where i learned it all,
i learned ROAM from here
and geomipmapping from here
and i learned rottger and another split-only quadtree algo from a course at gameinstitute.com.
as for where i get my textures, i usually just download other peoples terrain engines and use theirs

by the way, anyone using SOAR for their terrain engines?


[~aussie]

[edited by - James Sioutis on June 1, 2004 2:52:22 AM]

i would say there is no way around ROAM 2.0, i have never seen better results. with and also without vertex shaders it is really impressive, but i also think it is not very easy to implement.

if you just want a terrain but the quality does not count so much, use geomipmapping or e little bit more difficult ulrich thatchers chunked lod.

Noone's talking about Chunked LOD by Ulrich Thatcher? This is the terrain algorithm that I use

http://www.tulrich.com/geekstuff/chunklod.html


[edited by - WhileTrue on June 1, 2004 7:32:37 AM]

quote:

---

Original post by James Sioutis

quote:

---

Original post by craigatcod3rzdotnet
terrain rendering is a great place to start with graphics algorithms - i also messed around with a few some time back...

these are two screenshots from a roam-based engine i put together - of particular interest is the second screenshot, which shows a top view of the rendering.
its more whats not rendered that i find cool!

flymode
godmode

---

dude it has cracks in it

i would post some of mine but i don't have anywhere to host the images

as for where i learned it all,
i learned ROAM from here
and geomipmapping from here
and i learned rottger and another split-only quadtree algo from a course at gameinstitute.com.
as for where i get my textures, i usually just download other peoples terrain engines and use theirs

by the way, anyone using SOAR for their terrain engines?


[~aussie]

[edited by - James Sioutis on June 1, 2004 2:52:22 AM]

---

Soar is what I used mainly. If you want to find working technique, look for awu-terrify, its pretty decent and source is copy-pasteable (its excellent for gamedevers).

As an implementation it is a liquid failure. It works great when your data does not change, but it is almost impossible to utilize VBOs.

Currently I'm working on my own topology sensitive irregular triangle reduction system that works well with tiled terrain. It saves memory, although it easy to use with VBOs because the triangulation is irregular and only meanigful points of the topography are recorded.

I store multiple topographies of the terrain (not retarded x^2 * x^2 strips, but irregular arrays of triangles) and then build indices runtime. It is excellent for paging and even better for fast triangle reduction. I get high bandwith because i use 16-bit indices.

The greatest downside is collision detection and the fact that sometimes models go under the terrain. However, the terrain looks excellent because no triangle is wasted for useless detail as in geomipmapping.

The models disappear only in fps mode and is not visible when doing third-person view, which is exactly for which this made for. When i get home i post the references. Some hoppe, etc.

This x^2 * x^2 stuff is horrible. So many triangles are wasted on useless detail or you get flat ugly maps as in BF1942.



[edited by - captian goatse on June 1, 2004 8:32:04 AM]

quote:

---

Original post by creative1
haro,
can you elaborate a little more on that LOD formula?
I don''t think I understood what you meant.

---

Here is a thread I started on the error metric idea. It includes screenshots. I received no relevant replies unfortunately so a discussion never emerged.

quote:

---

I store multiple topographies of the terrain (not retarded x^2 * x^2 strips, but irregular arrays of triangles) and then build indices runtime. It is excellent for paging and even better for fast triangle reduction. I get high bandwith because i use 16-bit indices.

---

I''m doing something similiar, because it gives the added flexibility of having a single "map" object handle any type of geometry, be it terrain, buildings, or boulders, and to share vertices for adjacent faces, even if they have different textures. I ran into a sort-of bottleneck when it came to the 16-bit index limitation, though, as you''re capped at 65,536 vertices, which is only a 256x256 terrain (and that''s not even including non-terrain geometry). I was thinking about just using multiple VB''s, but that would require saving the size of each node in the map file as well (or doing some rather costly loading algorithm to determine the exact vertices actually used by a given node). I''m still doing benchmarking to determine if multiple VB''s would be faster than transferring 32-bit indices over the bus.

Then again, I''m pretty sure most video cards cap out at 1048576 indices per call anyway (1024x1024), so multiple VBs may be the way to go anyway.

The one drawback to that that I can see is the need for duplicating vertices at the edges of each node...but that may be a minor thing anyway.

quote:

---

Original post by Etnu
I'm doing something similiar, because it gives the added flexibility of having a single "map" object handle any type of geometry, be it terrain, buildings, or boulders, and to share vertices for adjacent faces, even if they have different textures. I ran into a sort-of bottleneck when it came to the 16-bit index limitation, though, as you're capped at 65,536 vertices, which is only a 256x256 terrain (and that's not even including non-terrain geometry). I was thinking about just using multiple VB's, but that would require saving the size of each node in the map file as well (or doing some rather costly loading algorithm to determine the exact vertices actually used by a given node). I'm still doing benchmarking to determine if multiple VB's would be faster than transferring 32-bit indices over the bus.

---

not all video cards can handle 32 bit incidies at least not in d3d. my engine was using 32bit indicies (tho only using low numbers) and i was getting wierd corruption (tris not where they should be and some missing altogether). this was on a gf4mx card, it ran fine on my gf4ti4200.


[edited by - soddit on June 1, 2004 12:39:06 PM]

Most new cards "support" 32-bit indices, but they''re actually capped at 24 bit precision, which gives you 1048576 vertices to work with. It''s annoying, because things would be a lot easier with 1 big 32MB vertex buffer in many situations.

quote:

---

Original post by James Sioutis

quote:

---

Original post by craigatcod3rzdotnet
these are two screenshots from a roam-based engine i put together - of particular interest is the second screenshot, which shows a top view of the rendering.
its more whats not rendered that i find cool!

flymode
godmode

---

dude it has cracks in it


[~aussie]

[edited by - James Sioutis on June 1, 2004 2:52:22 AM]

---

no cracks - just that i dropped the resolution on the screenshots to make viewing easier.
now it looks sh1tty



---
craig(at)cod3rz(dot)net