quantized-mesh terrain- some questions

Thank you very much for Cesium. It's a great product with a lot of potential.

I want to implement my own quantized-mesh terrain server as a college project. Reading the documentation, I have some questions:
1. In QuantizedMeshHeader struct there are the BoundingSphere fields. Does the sphere is supposed to bound the 3d tile (with the heights), or only the 2d tile?
2. The VertexData arrays values are encoded with zigzag encoding. Why? (given that the types are unsigned)
3. I want to avoid the usage of water mark encoding in the indices list. Does the decoding code in the createQuantizedMeshTerrainData() function in the CesiumTerrainProvider.js file is the only thing I need to take into account? Is there another place which affected by this encoding?

Thank you very much


  1. The bounding sphere should wrap the 3D tile.

  2. The vertices are delta encoded (current value - previous value) first, yielding signed values, and then zig-zag encoded.

  3. I think that’s correct, but why would you want to avoid the high water mark encoding? We implemented high water mark encoding because it significantly reduced the compressed size of the index data.


2. In the documentation the vertices data is appear as unsigned values on the scale between 0 to 32767 where 0 is the tile MinimumHeight and 32767 is tile MaximumHeight.


3. Just want to reduce the amount of calculations in order to get better performances. The size is less important for me now.
By the way, have you looked at google protobuf? It's seems to yield very small files and has a javascript port...


On #2, you’re right, the documentation neglects to mention the delta encoding. You can clearly see it in the code, though:


Notice that it’s:

u += zigZagDecode(uBuffer[i]);


u = zigZagDecode(uBuffer[i]);

On #3, I’d be surprised if you see a net performance improvement by removing the high water mark encoding. It’s a very quick computation, so you’ll almost certainly spend more time downloading the slightly larger file than you’ll save by not doing the decoding. You’re welcome to try, of course!

I’m somewhat familiar with protobuf. Compared to JSON it’s very compact. Compared to the carefully constructed format used by quantized-mesh-1.0 it’s almost certainly larger, simply because it’s much more general.


After zigzag and delta decoding, the values will be in the range of 0 to 32767. We can normalize these to 0.0 and 1.0 by dividing the decoded values by 32767 and from there we can easily extract the true height with interpolation between min and max height.

In terms of performance, the compression we apply is low overhead. In dealing with client server architectures, data transmission speeds cannot be disregarded. When rendering massive worlds, these savings add up quickly.



I’ve been looking for a quantized-mesh terrain provider and I hope your code will be available on GitHub :slight_smile:

I’m also happy to do some tests with the terrain data used in this blog post:


Bjørn Sandvik

kl. 20:58:04 UTC+1 tirsdag 25. november 2014 skrev dr.drom...@gmail.com følgende:

I have reading up on information also with purpose of doing some quantizedMesh generator and I have been thinking of putting it together with some PCL mesh generation to being able to generate a terrain from a point cloud. (I work with stereo matching of image and creating point clouds this way, and is lagging a more modern way of visualizing all my work in a browser).

What kind of framework, language are you doing your work in ? Maybe we can share some ideas. I primarily work in C#/.net but also do a lot of programming in c++ for PCL/OpenCV stuff and have alot of cloud computing experience. My goal is to create a quantized mesh terrain server running on Windows and Microsoft Azure. The project is not funded, so no timeframe for when it will be done.

Hi Poul,
Any progress made on a quantized-mesh generator ?



Nope. We had some more important things to get done, so still havent started it.

Just returned to to this thread to if anyone else have done any progress in creating one.

Hey, did you ever get around to doing this?

Hello i have implemented hegihtmap and quantized mesh (with simplification) formats generator and also server bundled all in one software. I have seen some tools for generating (heightmap only) / publishing seperately, that s something i dont like. I will notify here if and when i can go public.

However need to complete a few things first. Here s my todo list

- Heightmap generator
- Quantized tile generator
- Mesh Sİmplification
- Multithread support for faster generation
- Tile Server
- Datasource merge and updating an already generated dataset with a new data source
- Calculation review for Quantized mesh header. Seems a bit off for Bounding box or occlusion point. Works smooth tho at the moment
- Interface to manage application
- Enhancements ..etc

Interesting. Are you planning on publishing the source for this? What language? Is this something that might integrate with the existing https://github.com/geo-data/cesium-terrain-builder tool?

Hello, i will try to be as thorough as possible.

First of all code is very premature and needs almost every basic error checking. I will publish it as soon as i can. However it is still in , lets say, "early alpha". It is written in Javascript convenient with cesium itself.

I have seen cesium-terrain-builder that you mention. As well as its server part.Nice work with them.Tried geoserver terrain serving as well. But using them needs some effort and quantized mesh not yet implemented on that one. My implementation combines both parts therefore no need to integrate with them or any other tools. Also it is cross platform thanks to language. Get the software, Just load your data, generate and start using.

As much as usable but lots need to be implemented and tested

-Recheck simplification algorithm, implement a better one even
-Recheck Quantized mesh calculations and fix
-New data integration (generation) with the existing generated tile set (Working on this at the moment)
-Recheck and clean heightmap generation code
-Extensions coding(Normals and water line)(Next on todo list)
-Review entire tileset generation logic
-Interface for software control and workflow implementation
-Performance improvements

Great news!

I'm happy to help with testing this code.


tirsdag 31. mai 2016 19.49.05 UTC+2 skrev kalka...@gmail.com følgende:

I'm interessing in your works. Could you publish in a github repository. Thus some people, like Bjorn (sorry for the o) and me, could help.

Looks very promising. Out of curiosity, what source datasets did you use?

It is a single file world DEM data. Not very high resolution. Free on the internet.

Also an alpha in python. I thought it was really missing as well and wanted to improve the situation.
It's available on pypi.
Here is a link to the doc.


GitHub link https://github.com/Nymria/Cesium-Terrain-Generator-And-Server

Fantastic! Thanks to both of you for developing and publishing these tools. Much appreciated!