My question to Microsoft Copilot around this topic, was the relationship between a given dem.png in pixels and the units per pixels set in stone inside the XML code of map.i3d. I asked:
“Can you tell me the relationship between a dem.png and units per pixel? My dem.png is 2049×2049 pixels, and units per pixel is a value of 2, which would be 4098 units in length and width?”
The response it gave was pretty accurate:
The DEM (Digital Elevation Model) image (dem.png) serves as the heightmap for your terrain. In your case, a 2049 × 2049 pixel dem means you have 2049 height values (or vertices) along each side.
When the terrain is built, what really matters is the number of intervals (or cells) between those height values. Since there are 2049 vertices, there are 2048 intervals per side. The units per pixel value tells you how long each interval is in game units.
So if your units per pixel is 2, then the overall dimension of the map is calculated as follows:
Total Length (or Width) in Units = (Resolution – 1) × units per pixel
Substituting your values:
(2049 – 1) × 2 = 2048 × 2 = 4096 units
That means your map will be 4096 units in both length and width—not 4098.
The common mistake is to multiply the total number of pixels by 2, but since the edges only define the boundaries, you lose one pixel’s worth of spacing when calculating the intervals.
This relationship is fundamental:
- DEM Resolution: Defines the number of vertices.
- Units Per Pixel: Scales how far apart each vertex is.
- Overall Map Size: (Resolution – 1) × (units per pixel)
Looking at the DEM (dem.png) with Blender googles (from 2D to 3D)
So I responded with a follow-up question, which probably makes some sense:
Microsoft Copilot gave the following response back:
Exactly. The concept is very similar to working with a subdivided plane in Blender. Your DEM (heightmap) is essentially a 2D grid of pixel values that represent height data. When this data is translated into 3D, each pixel becomes a vertex in a grid, and the spaces between them form the edges and faces (or triangles) that make up the terrain mesh.
To break it down:
- Subdivided Plane Analogy:
Think of it as starting with a simple plane in Blender. When you subdivide it densely—say, into a 2049×2049 grid—the resulting vertices correspond directly to the pixels in your heightmap. Once the raw 2D data (elevations) from the heightmap is applied, your flat plane turns into a 3D terrain where the height at each vertex is determined by the grayscale value at that pixel. - Edges and Faces:
In your Blender visualization, the edges are the connections between vertices, and the faces (usually triangles or quads) are generated based on these vertices. The editor does this automatically when you convert raw pixel data into a 3D heightmap: it creates the mesh topology, ensuring that every adjacent set of vertices has edges connecting them, and faces formed between these edges. - Units Per Pixel:
The units per pixel parameter scales this whole setup to the correct size in the game world. With a value of 2, every cell (or gap between two adjacent vertices) spans 2 units, so even though your grid remains 2049×2049 in vertex count, the actual physical dimensions of the terrain are controlled by this multiplier.
So yes, when the heightmap is imported, it’s very much like having a densely subdivided plane where each vertex’s Z-coordinate (or height) is determined by that pixel’s value. This visualization is handy not only in the editor but also when planning your terrain work in Blender or similar 3D software.