The problem I am having is that when ever I try to load in terrain data from my local terrain server I get this error "An error occurred in "T": Failed to obtain terrain tile X: 0 Y: 0 Level: 0. Cesium.js:477" for both tiles 0/0/0.terrain and 0/1/0.terrain. I have tried using both height-maps and quantized-mesh.
From the terrain server Status code is 200 or 304
Using Cesium 1.41, cesium-terrain-server v0.6.0, tested on both Firefox Nightly and Chrome
Do you have a code snippet perhaps? Here’s an example of loading terrain in Cesium. As long as you are pointing the URL to where you are serving your terrain data, there shouldn’t be an issue loading the terrain if the terrain is of the correct format.
We don’t support the cesium-terrain-server project, so if there is an error there, you will need to contact the maintainers of that project.
I do still have the some error "An error occurred in "T": Failed to obtain terrain tile X: 0 Y: 0 Level: 0. Cesium.js:8116" (reformatted Cesium.js to make easy to read)
I am using heightmap-1.0 format for terrain files. Created by Cesium Terrain Builder
I was using a full url before with a custom server but there was a problem with the response headers that the server was sending. So I switched to this other style of link to test the data and it also fixed the response headers.
I believe using a relative URL should be fine, but most of the time I see the full absolute URL, so I would go with that if possible.
If you are having problems with your response headers, this is most likely a CORS issue. The server providing the tiles will need to be configured to add the appropriate CORS headers. https://enable-cors.org/
Just to double check, when the OP says "from local host", does this mean loading from http(s)://127.0.0.1/... or via a file:// URL? If the latter, you definitely can't request "../" resources in any browser without command-line switches to disable (very important!) filesystem protections -- what you're trying to do is basically a directory-walk attack, and could just as easily be asking to read your registry file or tax returns. If you move terrain under the main page's directory (say, ~/yourproject/index.html, with terrain under ~/yourproject/terrain/), then you still can't do it in some browsers (like Chrome) without command-line switches, but it would work in e.g. Firefox.
Of course, if it's the former case, you should never have CORS issues with a relative URL -- by definition, it's the same origin. Watch your network requests in your browser's development tools and confirm that the URL that's actually being requested makes sense, and that you can open the link directly.
Ok that is good to know about the risk of using "../" style link for the final product.
I have also been looking at the network requests when I use a server (cesium terrain server: http://192.168.1.115:8200/Terrain/) and when I use the relative link (../Terrain/). For both of them when cesium requests the layer.json file and both return that file. When cesium requests the 0.terrain files the Request Method is GET and the Status Code is 200 OK so it is connecting. But cesium still errors at "T".