screenspacelayout / labels performance

classic Classic list List threaded Threaded
3 messages Options
ShaderMan ShaderMan
Reply | Threaded
Open this post in threaded view
|

screenspacelayout / labels performance

hi osgearth community!

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 :

https://github.com/gwaldron/osgearth/blob/master/tests/city_labels.xml


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?


Thanks for your help,

shaderman

gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: screenspacelayout / labels performance

Shaderman,
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!
Glenn Waldron / Pelican Mapping
ShaderMan ShaderMan
Reply | Threaded
Open this post in threaded view
|

Re: screenspacelayout / labels performance

thanks glenn ,
i've heard that you upgraded the screenspace layout in osgearth 3.0 ?
Regarding this approach , i've found the following ressource about labels rendering and decluttering on GPU which drove me into this idea.

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.
    osgEarth::Features::FeatureDisplayLayout layout;
 
    layout.maxRange() = 15000000.0f;
    layout.tileSize() = 50000;
    layout.minRange() = 0.0f;
    layout.cropFeatures() = false;

    osgEarth::Features::FeatureModelLayerOptions layerOpt;

    layerOpt.layout() = layout;
    osgEarth::Features::FeatureModelLayer* la = new osgEarth::Features::FeatureModelLayer(layerOpt);

the same settings works in an earth file, i'm a bit puzzled.
Unfortunately , i don't have time anymore to improve this prototype but i hope i'll come back at it soon.