A concise explanation of the challenge you’re having.
The challenge we’re are facing is to get quickly changing real-time data displayed on a 3D map, currently looking in the various levels (from API to deeper levels of integration) of Cesium to achieve this. The data we’re trying to render consists of two main parts, one part will be objects (magnitude of thousands concurrent ones) and data that’s more suitable to be projected in a texture. The latter is high density data that will be spread over multiple texture to not exceed maximum texture size. We’ve seen that using the main APIs to display to object part we run into some limits in performance.
On the rendering side we’ve seen the Rayman Ng (https://cesium.com/blog/2019/04/29/gpu-powered-wind/) wind map implementation, he dives into the lower levels of Cesium to achieve proper rendering performance. This might help us get the objects drawn quickly enough.
Getting the data effectively into the GPU, the OpenGL side suggets using buffer re-specification(https://www.khronos.org/opengl/wiki/Buffer_Object_Streaming#Buffer_re-specification) as a valid technique, would you think this could work in the context of Cesium?
While considering multiple approaches to this I’m trying to get a feeling which could be most promising, to further explore, does someone have some suggestion that could guide me in a good direction?
Looking through the Cesium code I see that there are a few buffer hints for WebGL to denote it as streaming data, but I haven’t found this on the texture side yet. Is there something similar for textures?
Context. Why do you need to do this? We might know a better way to accomplish your goal.
In our project we’re generating a constant stream of high volume data in our back-end, this data needs to be streamed towards Cesium and visualized on the map, while not impacting the performance too much. To do so if been looking into the options WebGL could offer in doing so efficiently without impacting the render loop or running in synchronization slow downs during data transport to the GPU. Keeping a high enough frame rate is essential to support our use case.
The amount of data that will be transported for the texture data alone is significant and can grow to 80 MB/s or more, does this seem a feasible number to push through Cesium?