Objective
With 3D models (terrain and tileset) loaded into scene, we would like to obtain the altitude of the 3D model directly under the given coordinates.
The altitude to be acquired should be as accurate as possible, and should be invariant regardless of the camera position, etc.
What we tried, Part 1
First, we tried viewer.scene.sampleHeightMostDetailed.
We were able to get the altitude of the intersection with the terrain or tileset directly under the given coordinates.
However, we found that changing the camera position, zoom level, etc. returned different altitudes.
(I thought that perhaps the level of detail was changed, and thus the coordinate information in the scene was also changed.)
The behavior differs depending on whether the object directly below the scene is a terrain or a tileset.
If a terrain was directly under the given coordinate, the following values were returned depending on the camera position.
29.37 (when close)
-22979.007 (when far away)
undefined (when the earth is so far away that it cannot be seen)
If a tileset was directly under the given coordinate, the coordinate values returned were almost the same regardless of the camera position, although they shifted by several tens of centimeters.
What we tried, Part 2
Next, we tried Cesium.sampleTerrainMostDetailed(terrainProvider, positions).
It always returned a constant altitude, regardless of camera position or zoom level.
However, we found that this method only returns the altitude of the terrain and does not include the altitude of the tileset.
With the above in mind, I would like to know the best way to achieve my objective.
Hi there,
Would you mind providing a Sandcastle code example? viewer.scene.sampleHeightMostDetailed involved a pick, which can be affected by at what point in the render lifecycle the function is called.
Hi Gabby_Getz
Thank you for your reply.
I am sending you the sandcastle code example.
(If there are any usage mistakes, please let me know)
viewer.scene.sampleHeightMostDetailed involved a pick, which can be affected by at what point in the render lifecycle the function is called.
We want to get accurate altitude information no matter where on the planet the user is looking.
Maybe viewer.scene.sampleHeightMostDetailed is not appropriate for our use case.
For terrain, Cesium.sampleTerrainMostDetailed(terrainProvider, positions) is getting the right value.
A similar function for tileset would solve the problem, but I could not find it in the cesium source code or documentation.
Ah, I see the conflicting values that are occurring in scene.sampleHeightMostDetailed. This example shows the use case the function was originally designed around, and I’m not sure the drastic camera changes are fully accounted for.
We would like to obtain the altitude of the 3D model directly under the given coordinates. The altitude to be acquired should be as accurate as possible, and should be invariant regardless of the camera position, etc.
Could you provide a bit more detail about what these values are being used for? That may help narrow down any possible solutions.
I’m not sure the drastic camera changes are fully accounted for.
We feel that we are probably going beyond the expected use as well.
Could you provide a bit more detail about what these values are being used for?
I am interested in graphing the altitude on the ground directly under two points in the sky.
The graphing can be done by dividing the distance between the two given points into N equal parts and obtaining the ground altitude at each interior point.
Initially, I called synchronous sampleHeight N times in one animation loop.
However, since sampleHeight takes a certain amount of time, the screen froze when N became large.
To solve this problem, we made the following tuning
- Use asynchronous sampleHeightMostDetailed
- Limit the number of sampleHeightMostDetailed to be executed in one animation loop
As a result, the screen freeze problem has been resolved.
However, this implementation may cause the user to perform unintended camera operations during the course of updating the ground elevation of all interior points.
The resulting altitude is less reliable.
How is the current situation? If this part is not resolved, we will not be able to achieve our goal. We are very troubled. Any advice you can give me would be greatly appreciated.