Hi,
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?
The vertices are delta encoded (current value - previous value) first, yielding signed values, and then zig-zag encoded.
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.
Thanks.
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 #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.
Hi,
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 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.
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
DONE:
- Heightmap generator
- Quantized tile generator
- Mesh Sİmplification
- Multithread support for faster generation
- Tile Server
TODO:
- 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
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
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.
