TerraGear is a Linux toolchain. There is no installer for Windows, no Homebrew formula for macOS, and the only Windows instructions in the repository are a README.cygwin that predates the current build system.

The route that works on both is Docker, and it is not a compromise: every figure on this site was produced that way, on an Apple Silicon Mac with no graphics card involved. If you are on Windows or macOS, this is the supported path whether or not anyone has written it down before.

What you need

Docker Desktop. Free for personal use and for small companies; check the licence if yours is not.
About 8 GB of disk for images, plus room for data. The toolchain image is 1.5 GB. If you also want to look at the result in the simulator, that image is 5.6 GB, most of it FlightGear’s base data.
Memory. Give the Docker VM at least 4 GB. A build with land cover peaked at 2.2 GB resident for one degree square, and the VM here was capped at 7.75 GB.

The toolchain

One image gets you all fourteen binaries. The full Dockerfile and build script are published with the build record; the shape of it is:

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
      build-essential cmake ninja-build git pkg-config \
      libboost-dev libcgal-dev libgdal-dev zlib1g-dev libtiff-dev \
      libexpat1-dev libcurl4-openssl-dev libc-ares-dev liblzma-dev \
      gdal-bin

Then SimGear and TerraGear are built inside it, which Installing TerraGear covers command by command. Compiling takes about thirty seconds on ten cores; building the image takes as long as your connection needs for 1.5 GB of Debian packages.

Mounting your work

The one thing worth getting right. Keep the data on your own filesystem and mount it, so a rebuilt container does not take your work with it:

docker run --rm -v "$PWD:/work" -w /work tgtools bash /work/scenery.sh

On macOS and Windows, Docker’s bind mounts cross a virtualisation boundary and are slower than the container’s own filesystem. For a one-degree build this does not matter: the whole pipeline is under a minute. For a large region, consider a named volume for the working directory and mount only the inputs and outputs.

Windows specifics

Use the WSL 2 backend rather than Hyper-V; it is the default on current Docker Desktop. Keep your project directory inside the WSL filesystem rather than under /mnt/c/: crossing between Windows and Linux filesystems is where bind-mount performance actually hurts.

Line endings matter for the shell scripts. If git checks them out with CRLF, bash inside the container will fail on the first line with an error that does not mention line endings. git config core.autocrlf input before cloning, or run the scripts through dos2unix.

macOS specifics

Apple Silicon works. The images here are arm64 and were built and run on one; nothing needed emulation, and none of the dependencies required an x86 build.

Docker Desktop’s memory limit defaults lower than you might want. Settings → Resources, and give it enough for the figures above.

Seeing the result

You do not need a graphics card for this either. FlightGear renders in the same container arrangement with a virtual display and Mesa’s software rasteriser: the recipe is here, including the two things that stop it working.

The alternative is to copy the finished .btg.gz files out to a FlightGear installed normally on your desktop and point it at them with --fg-scenery. That is the better route if you actually want to fly what you built rather than take one picture of it.

What about a native build?

Nobody has published one that works with the current source, and this site has not tried. The pieces exist; the dependencies are all in Homebrew, and MSYS2 carries GDAL and CGAL; so it is plausible rather than impossible.

If you get one working, it is the single most useful thing you could contribute here: the honest answer to “how do I build scenery on Windows” should not have to be “install Linux in a box first”, and at the moment it does.