[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)?

[NickPollard]

The most common way is by having 'holes' defined in the mesh (ie. maybe use 1 bit for each point to determine whether it exists or not) and then creating extra geometry to attach to that.

Alternatively, you can try a voxel-based approach and then use an algorithm like Marching-cubes to reconstruct a smooth mesh over the top of it.

Or, you could change the heightmap data to also include X/Z displacement as well as Y displacement. This would allow some shallow caves and small overhangs, but nothing too crazy.

There will be plenty of other methods you could use too, these are just a starting point.

[stonemetal]

Erosion arches tend to be non-terrain geometry. I have seen caves done several different ways. The first was use height maps, but mark certain areas as artist owned. Then give artist tools to modify terrain, so caves are 100% hand carved. The second is to generalize height maps. Heights always come in odd numbers, even numbers are always floors, and odd numbers are always ceilings(i.e height 0 is the ground, 1 is the cave roof, 2 is the cave floor.)

[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).

[jheriko]

If you use distance field based raytracing this "just falls out" by deforming the isosurface of the terrain appropriately (e.g. with noise). The downside of using noise to do this it that you get corresponding floating bits of terrain for the indentations - one solution is to start with some y = noise(x,z) then if y > 0 subtract a noise(x,y,z) from the value...

Using polygons to solve this is highly nontrivial - despite the naive suggestions made already.

[JoeAltmaier]

Not that way.