Terrain heightmap bitmasks

My apologies in advance. This post has a lot of questions regarding the terrain 1.0 format located here. The documentation for the terrain file’s first bitmask leaves room for a lot of interpretation, and I’m just trying to understand what it means.

The heightmap 1.0 terrain format mentions that two bitmask values follow the heightmap data. One is for additional terrain files usage and the other is for water. If a bit is set, the corresponding “.terrain” file can be expected to be found on the server as well. If it is cleared, requesting the “.terrain” file will return a 404 error. This simple description, imo, glosses over several rather important details.

These bitmasks are located at byte offsets 8450 and 8451 (assuming zero-based array indices.) The first of these indicates what child tiles are present and is the basis for my confusion.

This first question may answer all the others… Is the bitmask for child tiles used?

The lower four bits describe four quadrants of data information and whether or not it is available. Is it correct to assume that if bit 2 (NW corner) is set for a tile at say, level 13, Cesium will also assume that that tile has more terrain data for level 14’s four quadrants?

If the bit is NOT set for the tile at level 13 in our hypothetical example, what happens when the map is zoomed into (i.e. level 14)? Is the level 13’s terrain data used to approximate more zoomed in areas, or is a request still made to retrieve the level 14’s terrain data regardless of the assumed 404 outcome? If a 404 outcome is returned what data, if any, is used to render the terrain for that failed retrieval? How does a returned 404 error code affect subsequent terrain tile requests? If subsequent terrain tiles for assumed 404 responses are requested, what is the benefit of having the bit(s) set other than “guaranteeing” that the next level will contain information for four tiles even if it, by human error, for example, does not? This particular scenario has me wondering why its important to have this particular bitmask in the first place.

And going the other way (zooming out), the bitmask seems to be completely irrelevant to anything. Is that the case?


Perhaps I should add that I am needing to generate my own heightmaps based on user-supplied terrain files? In other words, I cannot simply generate the heightmaps in advance using other tools since I don’t know the source material ahead of time.


why are you using this heightmap format? From Home · CesiumGS/cesium Wiki · GitHub “This format is deprecated and should not be used. Consider quantized-mesh instead.”

Um… because its deprecation was apparently a mistake?

If I were to go the quantized mesh route, there isn’t any information on the wiki regarding the encoding of the zigzag portion as well as other information such as:

  • how min and max height values are calculated?
  • does the bounding sphere completely encompass the tile?
  • how are the occlusion points calculated?

It seems that the wiki page is written to individuals that already have terrain in the quantized mesh format. Regardless of which method I use (heightmap or quantized mesh), more information is needed.

1 Like