My customer would like to display a large amount of labeled points on the map, and i'm a bit concerned on the performance of the screenspace layout part.
We are using osgearth 2.10.2 with osg 3.6.4 .
The target device are surface pro tablets with intel HD 515/520 GPU and ipads (not the latest hardware).
His requirements are a bit harsh because he wants to see as many labels as possible and only a few priorities between elements can be defined. And we are aiming 40-60 FPS of refresh rate...
running the cities earth fil example gives me the following :
as you can see culling takes 44ms to process.
Is there way to improve performances ? I tried to add "layout" to my data with various tile size but i didn't found any setting helping me to reach an acceptable framerate ( i had 20 FPS at best ).
From my understanding here , there is a lot of CPU side processing and the data sent to the GPU has a lot of GPU calls : each placenode is a node with several drawables under it ( so for a thousand placenode, there would at least a thousand gpu call and transforms ).
Starting from there, i started to prototype a more GPU-sided approach on which i'd like feedback :
Gpu likes big batches of geometry at once, right ?
So i generated all my text as static fixed size geometry (my text would be model like geometry, tangent to the surface of the earth, with a fixed size in meters) under a single drawable with a single font texture binded.
For the layer i'm currently using, i have 90 000 point data which translate into ~350000 characters/textured quad drawn.
Given the number of texts i'm drawing, the performance seems pretty good.
To achieve a screen space rendering, i plan to add for each text vertex its point geometry origin or screen space offset and maybe orientation data using vertex attributes. With that information, i could scale and transform the text as needed in a clip space vertex shader.
I know that having that much text drawn is not realistic, just trying to prove a point . The idea would be to use a similar strategy where there would be one drawable per layout tile or something similar.
On the declutter part, it seems to me that it is a problem that could be solved in parallel on the gpu such as this example:
https://www.shadertoy.com/view/MsKBzD (i don't mean it would be easy though ...)
Do you foresee any issue with this kind of approach ?
Are you working on something similar ?
Am i diving blindly into a dark endless pit?
I'm interested to see what kind of progress you make on the prototype. Text rendering is definitely slow and sub-optimal and an innovative way to approach the problem (with the decluttering of course) would be of interest!
Unfortunately, i was a bit stuck in my prototype because i wasn't able to programmatically create layout tiles, i used the following snippet :
// Set up a paging layout. The tile size factor and the visibility range combine
// to determine the tile size, such that tile radius = max range / tile size factor.