@Gabby_Getz
Thank you for your reply.
My explanation was not enough, so there may have been a misunderstanding.
I will try to explain it again, so please take a moment to check again.
Does this graph need to be constantly updated according to the camera position?
This graph needs to be constantly updated “independently” of the camera position.
Screen freeze issue.
When two points in space are specified by a user operation, the ground altitude directly below the line segment connecting the two points is determined.
Normally, we would like to update the graph immediately at that moment, but this process is very heavy and causes the UI to freeze.
As I told you in a previous message as follows.
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.
Limit the number of times “synchronous sampleHeight” can be executed in one animation loop
The UI freezes seemed to be caused by updating all interior points in one animation loop.
Our idea was to split the N endpoints and limit the number of “synchronous sampleHeight” calls in one animation loop.
This part corresponds to the following part of the previous message.
(I wrote “sampleHeightMostDetailed”, but please interpret it as “synchronous sampleHeight”.)
Limit the number of sampleHeightMostDetailed to be executed in one animation loop
For example, if we call “synchronous sampleHeight” 5 times per animation loop, it means that we can update all N interior points in N/5 animation loops.
In this way, the cost per animation loop would be reduced and freezes would be avoided as the process would be returned to the system.
This plan worked, and we were able to avoid screen freezes while updating the graphs.
However, a problem arose with this specification.
The user could freely move the camera while updating the graph.
This caused the “synchronous sampleHeight” result to change during the graph update.
This is problematic because the altitude above ground should be constant regardless of the camera position.
Application of sampleHeightMostDetailed
So far, we have used the “synchronous sampleHeight” method.
We thought, “Maybe the problem is that we are using a synchronous function.”
So we tried the asynchronous version of sampleHeightMostDetailed as well.
As we told you in a previous message as follows.
Use asynchronous sampleHeightMostDetailed
We decided to limit the execution to one animation loop, basically the same as “synchronous sampleHeight”.
However, considering that this is an asynchronous function, we added a process that waits for additional execution when the function executed in the previous animation loop is in the “running” status.
As a result, the same problem as with “synchronous sampleHeight” occurred.
This is the current situation.
As I mentioned in my first message,
For only terrain, Cesium.sampleTerrainMostDetailed(terrainProvider, positions) will solve the problem.
The problem is that we have a system with Terrain + tileset.
If we want to get the altitude information including tileset information, we would use sampleHeightMostDetailed,
However, due to the aforementioned problem, it cannot be used.
I expected a function like Cesium.sampleTilesetMostDetailed(tileset, positions), but I could not find it in the CesiumJS documentation or source code.