When I am using any of my terrain assets, I am getting consistently wrong terrain height values quite often for contiguous sequences, or all positions.
For example using asset ID 1679342 as terrain, calling sampleTerrainMostDetailed on a single point like
However, if that point is part of a longer track, most of the time the height of that position (longitude:0.09817040710155102, latitude:0.7867377035983536 in radians) is returned as 3192m
Sometimes the height is correct. Sometimes the whole track has wrong heights. Could you help me determine what is the problem and how to solve / work around it?
Its always the same parts of the track that have often wrong heights. The wrong heights are always the same values.
One more note: The area of the gps track is not in the area covered by the custom terrain asset (the custom raster terrain was merged with the World Terrain and this is happening in geographical area outside of the custom terrain asset)
Thanks for the report. It’d be useful if we could test with the dataset you’re seeing problems with. If you don’t mind sharing a Sandcastle code example with an access token here, please do. Otherwise if you would like to keep that data private, please send it to support via the support@cesium.com email.
Hi Gabby, thanks for getting back to me, below is a Sandcastle example. For me, it prints every time (abbreviated):
testing terrain
point elevation is 3292m
checking again
point elevation is 1060m
the 3292m is unexpected, the 1060m is as expected.
If I used Cesium World Terrain (Asset ID 1) it would print, as expected
testing terrain
point elevation is 1060m
checking again
point elevation is 1060m
I think it’s the essence of the problem. However, I am still not sure what is the best approach to solve it / work around it.
A short update, I work around the problem by finishing a camera flight to the point of interest and only then doing the rest. It looks a bit weird, aesthetically, however it seems to work.
Oh, interesting. I took it as granted that a distance between the sample point and the camera is diametrical to the errors I’ve always been seeing; the further away from a sample point, the less accurate it is, because that’s what I’ve experienced for years now. Are you saying internally that’s not the case, that sampleMostDetailed should be “bang on” no matter the camera view?
a distance between the sample point and the camera is diametrical to the errors I’ve always been seeing; the further away from a sample point, the less accurate it is
This is how sampleTerrain works. It more naively samples the terrain from the tile geometry at whatever the currently loaded LOD is at those positions, but is quick since additional data does not need to be loaded.
sampleTerrainMostDetailed should, in theory at least, request the highest LOD tile available and then sample. I believe it is sampling the geometry directly, so the distance from the camera should not be a factor.
It sounds like the user in this thread has a terrain tileset with multiple layers, and the highest LOD tiles are not being loaded consistently in all cases.
Hi, and thanks for that. Hmm, I think I was trying to say that I’ve experienced that error correlation with sampleMostDetailed as well as sampleTerrain, as if the forced loading of best tile is, hmm, somewhat random? I used to have big problems with this in calculating volumes; the distance to camera gave very different results (and of course using sampleMostDetailed), not to mention the pointcloud issue of sampling through the cloud. I ended up forcing a near flyby to kickstart loading of the tiles, and even then it varied.
Anyway, I’ll go back and do some further testing now that you say it should load the highest level. Actually, that begs the question; does sampleMostDetailed force the loading of the highest level, or just use the highest available? I did some experiments watching the various tile event listeners, can’t remember that sampleMostDetailed changed much how tiles were loaded? (There was another thread here lately about tile loading and ways to force the tiles to get going, they were using mostDetailed, I’ll go back and revisit that as well)
Do you have any automated test cases for testing this?
Thanks @Alexander_Johannesen, it would be helpful to have some additional test cases linked in the bug report. Would you be able to share the datasets you’ve seen the errors with?
We have some (fairly minimal) unit tests in packages/engine/Specs/Core/sampleTerrainMostDetailedSpec.js.
