osgEarth 2.10: odd texture artifact

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

osgEarth 2.10: odd texture artifact

Hi,

Not sure what may be causing the following effect in the image below.

The tiles display correctly when a lot closer to the earth. As I zoom out I get an odd swimming effect.

I am using Nvidia 440.100 driver on Ubuntu 20.04. I suspect something maybe playing up with the OpenGL driver as I did not see this effect on 18.04.

Any ideas as to what may be happening and how to reduce the effect?

Thanks
Damian



osg 3.6.3
osgEarth 2.10
Using GDAL 2.4.4
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10: odd texture artifact

Looks like z-fighting to me. Are you trying to use an ocean layer? Show your earth file.
Glenn Waldron / Pelican Mapping
DamianDixon DamianDixon
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10: odd texture artifact

I'm not using an ocean layer. Should be a very simple application.

Earth file is:

<map name="OpenSeaMap" type="geocentric" version="2">
    <options>
        <cache type="filesystem">
            <path>/home/damian/cache</path>
        </cache>
        <terrain>
            <lighting>false</lighting>
            <tile_size>17</tile_size>
            <morph_imagery>false</morph_imagery>
        </terrain>
    </options>
    <image name="osm_mapnik" driver="xyz">
        <url>http://[abc].tile.openstreetmap.org/{z}/{x}/{y}.png</url>
        <profile>spherical-mercator</profile>
    </image>
    <image name="contour" driver="wms">
            <url>http://osm.franken.de:8080/geoserver/gwc/service/wms</url>
        <format>png</format>
        <layers>gebco_2014</layers>
            <tile_size>256</tile_size>
        <srs>EPSG:4326</srs>
        <transparent>true</transparent>
        <opacity>0.5</opacity>
    </image>
    <image name="osm_mapnik" driver="xyz">
        <url>http://t1.openseamap.org/seamark/{z}/{x}/{y}.png</url>
        <profile>spherical-mercator</profile>
       
    </image>
</map>

You are correct in that its z-fighting. Been awhile since I've been doing any heavy OpenGL work.

The issue is the contour layer as can be seen in the Nsight frame debugger:



The layer has an opacity of 0.5. Is there away of combining the rasters of the bottom two layers into a single raster so that I can avoid the z-fighting?

The top layer does not exhibit the problem, probably because the majority of the image is transparent.

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

Re: osgEarth 2.10: odd texture artifact

osgEarth composites layers by rendering them one on top of the other with an LEQUAL depth function, which prevents z-fighting. So that's not the issue. It could be related to your driver upgrade. Is this osgearth_toc, or your own app? Are you doing anything custom with the near/far planes?
Glenn Waldron / Pelican Mapping
DamianDixon DamianDixon
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10: odd texture artifact

I'm using my own app. Been awhile since I wrote the base application so I may be playing with near and far clipping planes.

I will try with osgearth_toc tomorrow to eliminate anything I may be doing.

Thanks
Damian
DamianDixon DamianDixon
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10: odd texture artifact

In reply to this post by gwaldron
osgearth_toc is not demonstrating the problem I am seeing.

I'm not doing anything custom with the near/far clipping planes.

At least I know the problem is somewhere in my app or the integration with Qt.

Thanks for the suggestions.

Regards
Damian
DamianDixon DamianDixon
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10: odd texture artifact

I thought I would follow up on this .

I had applied remoe's git pull request 'GEOS 3.8 compile fix #1497' so that I could use the stock geos (3.8) on Ubuntu 20.04.

However I ran into problems with using a osgEarth::Util::Controls::Frame(). In that my application was crashing.

I dug deeper and found that objects created in geos were losing thier contents so that a subseqent call later would crash attempting to access the coordinates. I've spent most of today and half of yesterday trying to find out when the contents disappear but I'm not having much luck.

I've a hard timescale so I've abandoned the debugging for now... so I built geos 3.7.3, rebuilt gdal 2.x, osg, osgEarth 2.10.
 
Runing with the new builds the problem with the z-buffer has gone away and the Frame object draws.

Nothing else has changed in my build other than the version of geos. Neither has any of the graphics drivers or other dependencies.