

Build A Terrain Engine For Video Game Development - felipemnoa
http://www.shamusyoung.com/twentysidedtale/?p=141

======
haasted
Notch posted an article a while back on terrain generation in Minecraft.
Short, but contains some interesting details. He unfortunately never seemed to
get around to writing Part 2, though...

[http://notch.tumblr.com/post/3746989361/terrain-
generation-p...](http://notch.tumblr.com/post/3746989361/terrain-generation-
part-1)

------
jheriko
This is quite old but still vaguely impressive to see the visual results -
however there is one fatal flaw, every newbie gamedev churns out a terrain
engine because they look very good with little technical investment and are
easy to implement in any tutorial copied rendering framework... in essence its
teaching newbies how to do newbie stuff.

I'm fairly convinced that distance field raytracing is the way to go for
terrain rendering - one poly and some extra overhead in the fragment shader
(which is not trivial I'll admit) vs. thousands/millions of polys and the same
fragment shading pass you use for everything else...

~~~
felipemnoa
>>I'm fairly convinced that distance field raytracing is the way to go for
terrain rendering - one poly and some extra overhead in the fragment shader

Could you elaborate a bit more on this technique. Can you use this technique
in 3D games when playing real time? I had the impression that all 3D games
used meshes for the terrain, do you know of a popular 3D game that uses this
technique you mentioned? Finally, do you happen to know a link to a good
introduction/tutorial? Thanks!

~~~
corysama
[http://wwwcg.in.tum.de/Research/Publications/TerrainRayCasti...](http://wwwcg.in.tum.de/Research/Publications/TerrainRayCasting)
Claims ~30fps @1080p on an Nvida 260GT (that's a reasonable gamer card today)

Seems like a more formal reinvention of this guy's "Quadtree Displacement
Mapping" <http://www.drobot.org/> You would be better to check out drobot's
slides first. More descriptive, less formal.

~~~
felipemnoa
Thanks!

------
usedtolurk
What a great tutorial - explained just enough to leave me desperately wanting
to try it myself.

5 years on, but I'd guess it's still relevant to mobile devices. Anyone know
if there are better accepted approaches now?

~~~
exDM69
Height maps are still the way to go for terrain. The rendering methods
themselves have changed but the basic idea remains the same. These days you
tend to push big blocks of geometry to the GPU while a decade ago it was
common that the terrain would get generated triangle by triangle every frame
to minimize the amount of geometry.

~~~
iwwr
How would you model concave terrain or terrain with "holes" (like erosion
arches or caves)?

~~~
levesque
For what I know that's still a challenge for developers, they most often seem
to make two distinct types of area:

-Outdoors, where there are no concavities in the landscape and elevation models are used.

-And indoors, where you use a different type of modeling, last time I checked binary space trees were pretty common.

~~~
jheriko
fyi the reason for using a BSP is to get a "cell-portal graph" which allows
visibility computations to be trivialised - the benefits of the BSP tree
itself for, e.g. rendering with no overdraw are not very valuable. e.g.
despite the hype otherwise this was never realised in Quake for zero-overdraw
rendering, instead the PVS (based on the cell-portal graph) was used to result
in "very little overdraw". This technique continues to be used today in every
major game engine (id Tech 4 (maybe 5?), Source, UE3, CryEngine, numerous
other proprietary engines).

