it's bounds seems to be the follow value ,and it never change
"projection": "EPSG:4326",
"bounds": [ 0.00, -90.00, 180.00, 90.00 ],

Hi,

when I follow the instructions I get the following structure:

terrain/
|-- 10
|   `-- 1113
|-- 11
|-- 12
|-- 13
|-- 14
|-- 15
|-- 16
|-- 17
|-- 18
`-- layer.json

How can I fix the numbering?

I guess that's the reason why the terrain is not displayed.

Thanks for any help

In my centos7(memory:32G):

1. docker run -it --name ctb -v "/data/maping/to3dtile/dsm":"/data" tumgis/ctb-quantized-mesh
2. ctb-tile -f Mesh -C -N -o out dsm.tif note: the dsm.tif is 82MBytes from opendronemap
3. It uses 2minutes to finish the above process
4. ctb-tile -f Mesh -C -N -l -o out dsm.tif
5. The computer memory used by ctb-tile increase to > 90% and core dump
6. Test data

Hey @BWibo ,

I am confused that the coordinates of generated tile are quite different from the Google standard or TMS standard. For example:

Tile(x=69555, y=54636, z=16) is what I got from cesium-terrain-builder-docker. However, the corresponding tile coordinates in Google standard are Tile(x=69555, y=38016, z=17) + Tile(x=69555, y=38017, z=17).

Or Tile(x=69555, y=93055, z=17) + Tile(x=69555, y=93054, z=17) in TMS standard.

In addition, each tile generated from cesium-terrain-builder-docker looks like a rectangle rather than a square. But tiles using Google standard or TMS standard are all squares.

I would like to know how to convert the tile coordinates to those using Google standard or TMS standard. Thanks a lot.

Oliver

Hello,

Thank you for the amazing work.

I have run into this issue, i was hoping someone can provide some clarity.

When i add the -l argument to generate a layer.json file i get "terminate called afterthrowing an instance of std::bad_alloc" what(): std::bad_alloc.. aborted

can anyone please help me on this?

I am new to docker and C++.

Please and thank you!

Kind Regards
Vamshi

Docker container runs successfully
But unable to find terrain tile. I used following commands on command prompt:
docker run --rm -it --name ctb -v //d/docker/terrain:/data tumgis/ctb-quantized-mesh

ctb-tile -f Mesh -C -N -o terrain dsm.tif

Following error is given:
ERROR 4: dsm.tif: No such file or directory
Error: could not open GDAL dataset

i've tried many ways to give paths. Please help.

Hi,

I think this is a great tool! I just tried it and I am wondering the following command: "ctb-tile -f Mesh -C -N -o ./output input.tif" and it is 700MB, while if I tried the original terrain it is 40 mb using "ctb-tile -C -N -o ./output input.tif". I thought quantized mesh would produce a lighter tiled model. Am I doing something wrong? Thanks

Hi,

I noticed the --profile mercator option gives an segmentation violation on Docker image tumgis/ctb-quantized-mesh but not on tumgis/ctb-quantized-mesh:alpine.

Sample on tumgis/ctb-quantized-mesh:

$ ctb-tile -v -f Mesh --profile mercator -C -N -e 0 -s 10 -o tiles test.tif
Segmentation fault

Any idea why this function works on tumgis/ctb-quantized-mesh:alpine but not on tumgis/ctb-quantized-mesh ?

I prefer to use tumgis/ctb-quantized-mesh instead of tumgis/ctb-quantized-mesh:alpine (because other tooling on that Docker image)

you outlined the overflow issues at https://github.com/tum-gis/cesium-terrain-builder-docker#handling-large-datasets

do you see a automatic or scripting solution to this issue - even if it runs rather long?

manual try and error ist just pretty tedious

• Michael

I've been trying to build ctb on a Windows machine for the last few days and keep running into this error.

For context, I've installed gdal (v3.4.1) via conda. Following are my build logs:

(geo) PS C:\Users\ash19\cesium-terrain-builder\build> cmake -G "MinGW Makefiles" ..
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/msys64/mingw64/bin/g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test COMPILER_SUPPORTS_CXX11
-- Performing Test COMPILER_SUPPORTS_CXX11 - Success
-- Performing Test COMPILER_SUPPORTS_CXX0X
-- Performing Test COMPILER_SUPPORTS_CXX0X - Success
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found GDAL: C:/Users/ash19/miniconda3/envs/geo/Library/lib/gdal_i.lib (found version "3.4.1")
-- Looking for GDALOpenEx in gdal
-- Looking for GDALOpenEx in gdal - not found
CMake Error at src/CMakeLists.txt:10 (message):
  The GDAL version must be one that implements RFC 46 (GDAL/OGR unification)
  i.e.  >= 2.0.0


-- Configuring incomplete, errors occurred!
See also "C:/Users/ash19/cesium-terrain-builder/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/ash19/cesium-terrain-builder/build/CMakeFiles/CMakeError.log".
(geo) PS C:\Users\ash19\cesium-terrain-builder\build>

Looking at the error log, it seems this is caused by -lgdal not being found. I've tried explicitly specifying the path but it didn't work. Hope someone can point me in the right direction.

Error logs

(geo) PS C:\Users\ash19\cesium-terrain-builder\build> cat "C:/Users/ash19/cesium-terrain-builder/build/CMakeFiles/CMakeError.log"
Determining if the function GDALOpenEx exists in the gdal failed with the following output:
Change Dir: C:/Users/ash19/cesium-terrain-builder/build/CMakeFiles/CMakeTmp

Run Build Command(s):C:/MinGW/bin/mingw32-make.exe cmTC_d8986/fast && C:/MinGW/bin/mingw32-make.exe  -f CMakeFiles\cmTC_d8986.dir\build.make CMakeFiles/cmTC_d8986.dir/build

mingw32-make.exe[1]: Entering directory 'C:/Users/ash19/cesium-terrain-builder/build/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_d8986.dir/CheckFunctionExists.c.obj

C:\msys64\mingw64\bin\gcc.exe   -DCHECK_FUNCTION_EXISTS=GDALOpenEx -o CMakeFiles\cmTC_d8986.dir\CheckFunctionExists.c.obj -c C:\Users\ash19\miniconda3\envs\geo\Library\share\cmake-3.19\Modules\CheckFunctionExists.c

Linking C executable cmTC_d8986.exe

C:\Users\ash19\miniconda3\envs\geo\Library\bin\cmake.exe -E cmake_link_script CMakeFiles\cmTC_d8986.dir\link.txt --verbose=1

C:\Users\ash19\miniconda3\envs\geo\Library\bin\cmake.exe -E rm -f CMakeFiles\cmTC_d8986.dir/objects.a
C:\msys64\mingw64\bin\ar.exe cr CMakeFiles\cmTC_d8986.dir/objects.a @CMakeFiles\cmTC_d8986.dir\objects1.rsp
C:\msys64\mingw64\bin\gcc.exe  -DCHECK_FUNCTION_EXISTS=GDALOpenEx -Wl,--whole-archive CMakeFiles\cmTC_d8986.dir/objects.a -Wl,--no-whole-archive -o cmTC_d8986.exe -Wl,--out-implib,libcmTC_d8986.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\cmTC_d8986.dir\linklibs.rsp
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgdal: No such file or directory

collect2.exe: error: ld returned 1 exit status
CMakeFiles\cmTC_d8986.dir\build.make:106: recipe for target 'cmTC_d8986.exe' failed

mingw32-make.exe[1]: *** [cmTC_d8986.exe] Error 1

mingw32-make.exe[1]: Leaving directory 'C:/Users/ash19/cesium-terrain-builder/build/CMakeFiles/CMakeTmp'

Makefile:139: recipe for target 'cmTC_d8986/fast' failed

mingw32-make.exe: *** [cmTC_d8986/fast] Error 2

cc @ahuarte47

Hello,

I am trying to use the mesh output with CesiumJS.

I am getting the error:
Cesium.js:452 An error occurred in "w": Failed to obtain terrain tile X: 1 Y: 0 Level: 0.
Cesium.js:452 An error occurred in "w": Failed to obtain terrain tile X: 0 Y: 0 Level: 0.

I asked this question also in the cesium-dev Google group. You can find my question at https://groups.google.com/forum/#!topic/cesium-dev/bmH_Rp4FkDY.

Are you familiar with this error? Can you guess what I am doing wrong?

I am using CesiumJS version 1.50.

Thanks.

Travis build workflow is outdated and no longer required.

• Extend Github build workflow to push to both Dockerhub and Github packages
• Test, how automatic builds on pushes to ahuarte47/cesium-terrain-builder/master-quantized-mesh
• Drop Travis build workflow

Hello, could you provide an arm64 based Docker image? If possible, thank you very much！！！

I successfully created a bunch of .terrain files. But I still don't know how to view them in Cesium. Could anyone share me some documents or examples of using the results generated by the tool?

Hello,

I have generated some quantized mesh terrain files from a GeoTIFF using this repository, thank you very much for the only codebase that just plain works for making these for Cesium!

That being said, even though the terrain files work brilliantly in every other aspect, Cesium doesn't seem to think the normals were generated, despite the fact that I used the -N flag when creating the terrain files, and I have "requestVertexNormals: true" when creating the CesiumTerrainProvider that uses these files.

viewer.terrainProvider.hasVertexNormals returns false, and this code renders the terrain all the same shade of grey (for SlopeRamp) or black (for AspectRamp):

material = Cesium.Material.fromType('SlopeRamp');
globe.material = material;

material = Cesium.Material.fromType('AspectRamp');
globe.material = material;

I may be doing something wrong, but as I have no other way to check that the normals were correctly generated other than trying to use them in Cesium itself, I'm not sure how to double check that the normals are really there.

Hi @BWibo,

I am tiling a slightly large area with 77 .tif files (around 70GB). However, the power in the lab was out yesterday and hence led to shutting down the tiling at the level 18.

The current terrain tiles at level 18 have 4500+ .terrain files and I am sure it has not been finished yet. So, is it possible to resume the tiling instead of starting it from scratch again? Because it has already taken more than 30 hours to get these .terrain files at level 18.

Looking forward to your reply and thanks in advance!

Oliver

the url is current(exist 0/0/0.terrain and 0/1/0.terrain), but it seems to failed in the createQuantizedMeshTerrainData method which vertexCount is very large and more than the terrain size. An error occurs in this line.

Hi, I noticed that GDAL 2.4.0 from 2018 in this Docker image (tumgis/ctb-quantized-mesh:latest)

$ gdalinfo --version
GDAL 2.4.0, released 2018/12/14

Is it possible to upgrade to 3.7 (2023)?

Hi, I have facing this problem where a pyramid terrain is getting created outside of dataset bounds. Any idea why this could be happening. I have attached the screenshot of the terrain loaded in cesium

I'm using Docker in windows 10

Using the following commands:

docker run -v "${PWD}:/data" -it --name ctb tumgis/ctb-quantized-mesh

ctb-tile -f Mesh -C -N -o ./tilesets/terrain/test a.tif

Sometimes it's failing, by giving the following output:

0...10...20...30...40...Killed

so I'm using the following command for resuming the terrain building process:

ctb-tile -f Mesh -R -C -N -o ./tilesets/terrain/test a.tif

It giving the following errors at the end:

root@e594ebe1722d:/data# ctb-tile -f Mesh -R -C -N -o ./tilesets/terrain/test a.tif
0...10...20...30...40...50...60...70...80...90...ERROR 2: gdalwarpoperation.cpp, 1574: cannot allocate 814172736 bytes
ERROR 1: IReadBlock failed at X offset 0, Y offset 0
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0
ERROR 2: gdalwarpoperation.cpp, 1574: cannot allocate 814172736 bytes
ERROR 1: IReadBlock failed at X offset 0, Y offset 0
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0
100 - done.

I used this cmd in windows to produced terrain tiles

ctb-tile -o D:\dem\globe d:\dem\world-16bit.tif -f Mesh -s 10 -e 0

but when load by cesiumJS ,i found a problem,there is no “metadata” extension in 0/0/0.terrain and 0/1/0.terrrain.And the "metadata" is very important for cesiumJS to create quadtree,so it's absolutely need “metadata” extension in level0 and level10.We can see the code at https://github.com/CesiumGS/cesium/blob/7d7c5d06e712e71b7002f70100da8689080a3144/Source/Core/CesiumTerrainProvider.js#L308-L354
When i searched this problem at cesium community,i also found a similar post:https://community.cesium.com/t/terrain-loading-failed-in-ctb-production/14161

Cesium for Unreal and CeisumJS currently requires that tile availability be attached to quantized-mesh tiles using the “metadata” extension.

So what should i do To add the “metadata” ?

Thanks!

There was a problem loading the terrain in cesium. The cesium globe displays normally after removing the terrain.
In cesium1.96, chrome displays the following error:
Cesium.js:85 An error occurred in "Py": Failed to obtain terrain tile X: 0 Y: 0 Level: 0. Error message: "RangeError: Invalid typed array length: 8894653434"
Cesium.js:85 An error occurred in "Py": Failed to obtain terrain tile X: 1 Y: 0 Level: 0. Error message: "RangeError: Invalid typed array length: 2017542741"

cesium code like this:
var terrainProvider1=new Cesium.CesiumTerrainProvider({
url:"http://localhost:9000/"
});
const viewer = new Cesium.Viewer("cesiumContainer", {
baseLayerPicker: false,
imageryProvider: imageryProvider,
terrainProvider:terrainProvider1
});
viewer.scene.globe.enableLighting=true;

However, in the latest cesium, chrome does not output any errors and just does not display the globe.
How can I solve this problem? @BWibo @Son-HNguyen @TatjanaKutzner @thomashkolbe