Procedural 3D environments for training scenarios

The problem with building the world by hand

Sculpting terrain, painting ground and placing vegetation by hand produces a good-looking place and a fixed one. The first cohort through it learns the environment rather than the task: they know where the obstacle is, which way the slope falls, where the exercise usually starts.

Varying it means an artist doing the work again. So in practice it does not get varied, and the trainer quietly becomes a memory test.

Generated from survey data, or synthesised

When the training has to happen in a real place — a specific site, catchment or approach — the environment should start from survey elevation data, so distances, gradients and sightlines are the real ones. Public and commissioned elevation datasets are usually distributed as georeferenced raster files, which means positions in the environment can map back to real coordinates.

When the training is about the task rather than the place, a synthesised landform is better: it gives an unlimited supply of plausible terrain with the characteristics you ask for, and no trainee has seen it before. Most programmes want both, which is why I build the generator to take either as its starting point.

Make the land behave like land

What separates a believable environment from an obviously generated one is rarely the texture resolution. It is whether the parts agree with each other: water draining the way the slopes actually fall, erosion where it would occur, vegetation sitting where that species would grow given altitude, slope and aspect.

Doing this by rule rather than by hand is also what makes variation safe. Change the seed and you get a different valley that is still internally consistent, instead of a different valley with a river running uphill.

Determinism is what makes it an assessment tool

A generated environment is only usable for assessment if it can be reproduced exactly. The rule I build to is that the same seed and the same parameters always produce the same world, byte for byte, on any machine.

That gives you two things at once. An examiner can put every candidate through an identical environment and defend the comparison. And when the cohort has been through it, changing one number produces a fresh environment of equivalent difficulty rather than a rebuild.

Budgets, because a trainer is not a film

• If the environment has to run in a standalone headset, the performance ceiling is set by mobile-class hardware, and it is far lower than a desktop build suggests.
• Large areas need level-of-detail and streaming, so distance is paid for in complexity management rather than raw geometry.
• Vegetation density is usually the first thing to cut and the last thing anyone wants to cut, so it is worth agreeing a target early.
• Frame rate in a headset is a comfort requirement, not a quality setting — it cannot be traded away for visual detail.

Where procedural generation is the wrong answer

It will not give you a specific real building, a named landmark, or the exact state of a site on a particular date. For those you need survey data, photogrammetry or hand modelling, and generation is at best the surrounding context.

It also will not rescue a scenario that has not been designed. A varied world with nothing to do in it trains nobody, which is why the environment work and the scenario work are separate pieces that have to be specified together.

What I build with

My own terrain generator, TerraKit, is the environment engine behind this work: it plans landform, drainage, ground cover and vegetation from a written description or from survey elevation data, and outputs a terrain package for Unity. The case study linked alongside describes how it works and what it currently does.

The 3D models placed into an environment — trees, rocks, structures — are a separate question of licensing and provenance, and one I raise early, because it determines what can be shipped to a client and under what terms.