I wanted physical terrain models of specific places, not generic landscape art, which meant starting from real elevation data instead of a sculpted mesh. USGS publishes 3DEP LiDAR point clouds and derived DEMs that are free and accurate enough for this — the question was just how to get from a LAZ/LAS point cloud or a DEM raster to something an Ender 3 can actually print.
The pipeline has two practical paths. TouchTerrain takes a bounding box, pulls public elevation data, and exports a tile-ready STL directly — the fastest route when the location is already covered by a supported dataset. The other path is QGIS with the DEMto3D plugin, which works straight off a DEM raster and gives more control over extent and resolution when I already have a specific tile downloaded.
For the cases where I started from raw point clouds rather than a finished DEM, CloudCompare and PDAL did the heavy lifting — filtering ground returns from a LAZ/LAS LiDAR scan and rasterizing it down to a DEM before it could go through the same DEMto3D export.
The two things that actually mattered for a usable print were vertical exaggeration and base thickness. Real terrain is visually flat at any printable scale unless the vertical axis is exaggerated, but exaggerate it too much and the model stops looking like the place. Base thickness needed its own tuning pass too, since a thin terrain shell on the Ender 3's bed warps or cracks at the edges if it is too thin, and wastes filament and print time if it is too thick.
Tiling came up as soon as I tried a model bigger than the bed — splitting larger areas into multiple STL tiles that line up at the seams, which TouchTerrain handles natively and which I had to manage manually for the QGIS path.
Notes for next time: pick the data path based on what I already have, not habit — TouchTerrain when the area is just a bounding box, QGIS/DEMto3D when I already have a specific DEM or need tighter control, and the CloudCompare/PDAL detour only when starting from a raw point cloud.