Reading a heightfield

A digital elevation model arrives as a grid of numbers. Each cell holds one value, metres above a datum, and nothing about the file says how far apart the cells are or what the datum was. That metadata lives beside the raster, and losing it is the most common way a terrain pipeline produces something that looks plausible and is wrong by a factor of three.

The interesting decision is not how to read the grid. It is what interval to draw contours at.

Why this matters for simulation

A heightfield destined for a physics simulator has a second constraint the cartographer does not have: the solver has to step over it. Resolution that is too fine produces contact noise — the foot of a robot finds a sub-centimetre ridge that does not exist in the real world and the policy learns to avoid a phantom. Resolution that is too coarse smooths away the features that made the terrain worth reconstructing.

There is no universal answer. There is a working one: match the cell size to the contact patch of whatever is walking on it, then verify by rendering contours and looking at them. If the contour field reads as terrain to a human eye, it will usually behave as terrain under a solver.

The thing I got wrong first

I resampled a DEM to a power-of-two grid because the texture pipeline wanted one, and did it with bilinear interpolation. That is the correct filter for a colour image and the wrong one for elevation — it invents intermediate heights along ridge lines, rounding every arête into a dome. The reconstruction looked better. It was less true.

The fix was to resample with a method that preserves local extrema, and to stop treating an elevation raster as an image just because it is stored like one.

Some of the vocabulary here shows up again in why-sim2real-is-mostly-plumbing, which is not published yet — so that reference will read as plain text until it is.