In order to follow this tutorial, you’re going to need two things. The first is Blender, which is free, open source, and available for all major operating systems. You can get Blender by visiting blender.org. At the time of this writing, 3.0 is the latest version . If that’s no longer the current version, you should probably be able to download an older version of Blender and follow along. Or, you can try your luck using this tutorial with the newest version, and hopefully not much has changed since 3.0. A lot of people use Blender for a lot of different projects — we’re just making use of a tiny fraction of its powerful abilities — if you get stuck, it’s likely that the answer to your questions exists somewhere on the Internet.
The second thing you’ll need is elevation data. Blender doesn’t read spatial files; it’s not a GIS (though there is a BlenderGIS plugin that gives it some of those abilities — I don’t use it personally, but you may want to check it out). Instead, we feed it elevations in the form of simple greyscale images in one of the common raster formats: TIFF, JPEG, or PNG. It will read in lighter areas as high elevations, darker areas as low elevations. It’s what’s commonly called a heightmap.
Below, I’ve given an outline of the steps needed to convert digital elevation data into a heightmap suitable for Blender. If you don’t feel like going through it right now, I also have an already processed heightmap that you can download and use in this tutorial.
If you grabbed the ready-made heightmap, you can skip ahead to the next step in the tutorial and get straight into Blender. Otherwise, if you’re willing to take a meandering detour through raster GIS operations, proceed.
Before you can create shaded relief in Blender, you first need to do a little GIS work to get your digital elevation model (DEM) ready. Below, I present a basic outline of the required steps. Unlike the rest of the Blender tutorial, this is more of a conceptual walkthrough than a “click this button” guide. I’ve included references to some specific tool/function names in ArcGIS and QGIS, but in general it’s more focused on what’s to be done than how. The intent is for it to be platform neutral; these are steps you can accomplish using ArcGIS, QGIS, or any other raster-enabled GIS program you choose. In general, though, I’m presuming you’ve got some familiarity with GIS methods, and specifically the ins and outs of raster datasets.
If you’re interested in automating some of the processes below, Nick Underwood has put together a script that will speed you along your way.
Step One: Get Data
There are a great many places to get digital elevation data; where to look very much depends on the area you’re mapping and what resolution of data you need — which, in turn, depends on your map scale. Huge 1-kilometer pixels will do you no good if you’re mapping at large scale, and likewise a 10-meter DEM will be way too much data if you’re mapping the US at a small scale. So I recommend first figuring out your target resolution.
As a quick example, imagine I want to make a printed map of Egypt that’s 10 inches across. A typical print resolution is 300 pixels per inch, so I need a relief that’s 10 × 300 = 3000 pixels wide. Egypt is about 750 miles wide, so we need to find a DEM that covers 750 ÷ 3000 = 0.25 miles per pixel.
That should give you an idea of how to figure things. Actually, Tom Patterson suggests using a lower resolution than 300dpi for printed relief, so as to avoid printing little tiny details that look more like noise or a texture. I often aim for 150–200dpi. If you’re doing web mapping, Tom Patterson has you covered there, too, with his table of suggested relief resolutions.
In any case, you can always download a DEM that is higher resolution than what you need, and then just simplify it later on. But it’s impossible to go the other way and add detail that’s missing from a coarse DEM. So, before you get data, have an idea of what you need.
Where to look for data depends, as I said, on what area you’re mapping. My two most commonly used sources are:
- 3DEP: this covers the United States (as well as Canada and Mexico, at least at one point) at 10-meter resolution or better.
- Viewfinder Panoramas: Global coverage at about 90-meter resolution or better. Most global elevation datasets are based on satellite data, which sometimes, especially in mountainous areas, suffer from measurement errors. The folks at Viewfinder Panoramas have manually corrected many of these errors based on surveys and topographic maps.
If those don’t work for you, many countries, states, and municipalities make elevation data available online, so you could do some searching.
(Possible) Step Two: Mosaic your Data
Elevation data often come in tiles, and you may need to download multiple tiles to cover the area you’re interested in. Before we can proceed, you’ll need to join those tiles together into one single unit.
This is known as mosaicking in ArcGIS, or merging in QGIS.
Of course, you could get lucky and have your entire area of interest covered by one single DEM file, in which case you would skip this. But it never happens to me.
Step Three: Reproject
Once we get into Blender, we’ll lose any sort of horizontal coordinate data for our DEM. It’s just going to be treated like any ordinary image file, such as a photograph, without Blender knowing where on the Earth this DEM belongs. So we need to make sure it’s properly projected.
Imagine you have a raster which has data stored in WGS84 geographic coordinates, but you want to see what it looks like in an Albers Equal Area Conic. ArcGIS/QGIS/etc. can do this for you by reprojecting on the fly. They will show you what that raster will look like in an Albers, but the actual raster file hasn’t been rewritten: it’s still stored in WGS84.
Once we get into Blender, though, there’s no more ability to reproject on the fly, so we need to do some ahead planning if we’re going to use this relief with anything else. If you’ve got other raster or vector layers, and you plan on compositing them in Illustrator, Photoshop, etc., then you want all of those layers to have the same projection and scale. That’s the only way to get them to line up easily.
So we need to make sure that the actual DEM file itself is written in whatever projection we’re going to be using for the final map. This way, even though Blender will forget its real-life coordinates, it will still line up with any other layers in our graphics software later on, when we’re no longer able to reproject.
So you’ll need to make use of your GIS program’s reprojection tools. That could be QGIS’s Warp, ArcGIS’s Project Raster, or something else.
Step Four: Clip
Your DEM will likely cover a larger area than you plan to map. This is a similar situation to the above: you can zoom in on an area in your GIS program, but that doesn’t mean that it’s rewritten the original file to delete the parts you can’t see. That stuff’s still there, just hidden.
But, if we’re going to generate a relief in Blender, and then have that relief easily line up with our other layers, we need to delete that excess. This is for the same reason we do the reprojection: if I add my final relief to other layers in graphics software, each needs to cover the exact same area, or they won’t line up.
So, look for a raster clipping function in your GIS and trim your raster to the exact extent that you are planning to use for all your other map layers.
(Possible) Step Five: Resample
If your DEM is too high resolution, you may want to adjust that. As I mentioned, it’s fine to start with more detail than you need, but those files can be large and cumbersome. So, before moving into Blender, you should use your GIS to resample the DEM to match the target resolution that you calculated in Step One.
(Likely) Step Six: Rescale
Our final output target is going to be a 16-bit unsigned integer TIFF. This means that each pixel can hold a number between 0 and 65,535.
Your starting DEM probably has much smaller values. Maybe the range of elevations you have is, say, 50.12 meters to 270.35 meters. But if you output that as an integer TIFF for Blender, it will simply round the numbers such that the range is 50–270. This results in a loss of detail, as there are now only 270 – 50 = 220 elevation steps stored in the file. This may result in a very terraced appearance, as an area which once sloped gradually from 200 to 201 meters jumps suddenly as it shifts from one integer to another.
We can’t stop things from getting rounded to integers, since that’s the data type Blender needs to read. But we can reduce the amount of rounding (and therefore terracing) that’s going on.
You’ll need to stretch your elevation range to cover the span from 0 to 65,535 (or, 0 to 60,000-ish — it need not be exact). So, let’s pretend I have a range of elevations from 120 to 1500. I need to adjust that such that the places that were once 120 become 0, and the places that were once 1500 become 65,535, and everything in between is scaled accordingly. Your quick formula for that would be:
(Pixel Value – 120) ÷ (1500 – 120) * 65,535
You can do this by seeking out your GIS program’s Map Algebra function. Obviously, that particular formula is for my example values — the values of your DEM will vary. The more general formula is:
(Pixel Value – Lowest Value) ÷ (Highest Value – Lowest Value) * 65,535
By doing this, more detail will be retained when we put this into an integer format for Blender. The elevation will still be divided into a bunch of integer steps, but each one will be quite small: 65,535 tiny steps, instead of 1380 much larger ones.
This step is also important to do if your DEM has negative numbers (perhaps you have some places below sea level). Blender (and other image editing programs) will not understand what it means for a pixel to have a negative value, and will incorrectly interpret those pixels as having a very high, rather than a very low, elevation.
If your starting DEM happens to consist only of integers, then rescaling is unnecessary. This process is about keeping detail from being lost when converting from decimals to integers. However, if your integer DEM involves negative numbers, you’ll still need to get rid of those. You can just add a constant to each pixel using map algebra.
Step Seven: Save as 16-Bit Unsigned TIFF
Once you’ve got the DEM reprojected, clipped, and rescaled, it’s time to save it as a 16-bit unsigned TIFF. If you’re in ArcGIS, you’ll need to look for the Copy Raster tool, which will let you choose the data type. If you’re in QGIS, you’ll need to Translate and manually add the -ot tag to the GDAL output to specify the data type (UInt16). Other GIS programs probably have their own ways, but I’m not sure what those might be.
(Possible) Step Eight: Re-Save
I have no idea if this is true for QGIS, but ArcGIS, at least, saves TIFF files that Blender can’t read directly. Not sure why. But, if you open the TIFF in Photoshop, then Save as a new file, Blender will be able to read that new file. Passing it through Photoshop seems to clean it up somehow; other image editing programs may fix this problem, too.
Once you’ve jumped through all those hoops, your DEM should be ready to go, and you can proceed to Blender!
Next Chapter: Blender Basics
somethingaboutmaps 