3.1 very slow with elevation data

classic Classic list List threaded Threaded
7 messages Options
benedikt.schwarz benedikt.schwarz
Reply | Threaded
Open this post in threaded view
|

3.1 very slow with elevation data

Dear all,

While trying the new version 3.1, I found that it is about 10x slower compared to 2.10 with mp engine. As soon as I switch of the elevation layer, both are blazing fast. I use progressive, no morphing and adapted min_tile_range_factor to get a more comparable behavior between mp and rex.

Both imag and elevation data loads from a local ssd. I use a 5m elevation layer in a tiled geotiff. The elevation data is in the same profile epsg:31254 as the map.

Here is a list comparing the loading/rendering speed until fully loaded after zooming to a viewpoint.

osgearth 2.10 mp 11s
osgearth 2.10 rex 28s (19s with no progressive)
osgearth 3.1  rex 120s (70s with no progressive)

without elevation
osgearth 2.10 mp 5s
osgearth 2.10 rex 5s
osgearth 3.1  rex 7s

when map is in spherical-mercator
osgearth 2.10 mp similar
osgearth 2.10 rex similar
osgearth 3.1  rex 45s


I attach 2 examplary videos for osgearth 2.10 mp and osgearth 3.1 rex as they seem to be the fastest and slowest versions, respectively.
osgearth2p10_mp.mp4
osgearth3p1_factor9.mp4


earth file:
<map name="basemap" type="projected">
    <options> 
                <terrain driver="rex"
                                        progressive = "true"
                                        morph_terrain="false"
                                        morph_imagery="false"
                                        min_tile_range_factor = "9"
                />
                       
                <profile srs="+init=epsg:31254"
                 xmin   = "-50000"
         ymin   = "100000"
         xmax   = "250000"
         ymax   = "400000"></profile>
    </options>
   
        <image name="basemap" driver="xyz">
        <url>PATH_TO_WMTS/{z}/{y}/{x}.png</url>
        <profile>spherical-mercator</profile>
    </image>
       
        <elevation name = "gelaende"
                                driver = "gdal"
                                interp_imagery = "true"
                                interpolation = "bilinear"
        >
      <url>elevation.tif</url>
    </elevation>

        <viewpoints>
                <viewpoint name="Testpoint" heading="0" height="600" lat="47.280474" long="11.471341" pitch="-90" range="10000"/>
    </viewpoints>
</map>

Benedikt
benedikt.schwarz benedikt.schwarz
Reply | Threaded
Open this post in threaded view
|

Re: 3.1 very slow with elevation data

Dear all,

I tried several more test meanwhile. With a profiler I did not find something particularly interesting.

However, I discovered that createHeightField is callen much more often in case of REX and even more often with 3.1 and REX. This perfectly scales with the total loading time.

So while the image layer has the same resolution, it seems that 3.1 REX loads the elevatino much more detailed. In my case definitively too detailed. For the example shown in the video mp loads 29 tiles for the elevation, while rex loads 459.
The latter leads to a resolution of ~7m for a view of 10km.


I was looking for options to modify it, but did not find it. Is there an option set the ratio between image and elevation resolution or LOD?

Best, Benedikt
Benedikt
benedikt.schwarz benedikt.schwarz
Reply | Threaded
Open this post in threaded view
|

Re: 3.1 very slow with elevation data

This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Benedikt
benedikt.schwarz benedikt.schwarz
Reply | Threaded
Open this post in threaded view
|

Re: 3.1 very slow with elevation data

I am now one step further.
It seems in osgearth3.1 the elevation tile size is now also configured directly in the elevation layer.

The tile size in the terrain is responsible for the displayed resolution of the elevation, while the tile size in the elevation layer is responsible for loading the data.

I believe the default behavior here is not ideal, as it loads elevation with 257 points per tile and displays it only with 17 point.

I guess the best option is if they match. So maybe the elevation layers should by default be set to the definition from the terrain options, eventually making it possible to overwrite it, if the option is provided.

With the following configuration I now get excellent results:


image  tile_size="512"
In order to make the text better readable after reprojection

elevation and terrain option tile size = 65 or 129.


I additionally use
range_mode = "PIXEL_SIZE_ON_SCREEN"
tile_pixel_size ="512"

So my issues are solved and I hope my suggestions could be useful.

All the best,
Benedikt
Benedikt
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: 3.1 very slow with elevation data

Hi Benedikt,

Elevation data loads at a higher resolution because it can be used at higher LODs. For example if you have an LOD 2 tile at 257x257, that elevation data can be (and is) used when sampling vertices at LOD 5 if necessary. It's not just one-to-one. This means far fewer tiles of data on the server or in the local repository. Also the higher-resolution elevation texture is used for normal mapping, so you can have a 17x17 tile but still see 257x257 detail when lighting is enabled.

But like you said, if you want one-to-one data from a local GeoTIFF, you are free to configure it any way you like. The slowdown may have been coming from the use of an unoptimized GeoTIFF.
Glenn Waldron / Pelican Mapping
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: 3.1 very slow with elevation data

In reply to this post by benedikt.schwarz
This is good information to know.

Thanks for sharing your results.

Best

Shayne
liugaijin liugaijin
Reply | Threaded
Open this post in threaded view
|

Re: 3.1 very slow with elevation data

This post was updated on .
In reply to this post by benedikt.schwarz
I use the same geotiff data. mp engine is faster than rex engine.

But like you said, rex is more powerful than mp.

speed up!