Imagery From Files Fail To Render on ATAK

[kenktk]

Versions: ATAK-CIV - 4.3.1.X Android 11 - GrapheneOS RQ2A.210505.002.2021.05.19.06

Howdy all,

For the past few versions of ATAK, my custom imagery has not been able to render properly. I have taken all the steps that includes reinstalling imagery, reinstalling ATAK, downgrading to the earliest version of ATAK that's in 4.3, attempting this on another device, etc. I believe patch 4.3.1.5 was the last version that my imagery worked.

The following image depicts how the imagery is not rendering. Regardless of the zoom setting.

Now when I attempt to load online imagery, it loads just fine.

I am not sure why this is happening. I've used imagery from different sources to no avail. I usually use imagery from TNRIS.ORG, specifically Texas NAIP 2020 imagery. WinTAK loads the imagery just fine. I do not believe that any update from GrapheneOS has caused a rendering bug of any sorts.

I appreciate the read. For any further information on my testing environment, please let know. Thanks!

[takdeveloper]

@kenktk Thanks for reporting the issue. We'll pull some imagery from the referenced site and test with versions starting with 4.3.1.5. Thanks for including the version information!

[kenktk]

So I have been working on this problem. The imagery sometimes loads but it takes a very very long time in order for it to finally render. It used to not do this before some patch. I wonder if this was a change at how imagery was rendered as to not throttle other UI components from high system usage.

[kenktk]

Further observations on this imagery rendering, compared to downloading tiles via the WMS server, is that imagery loaded from the filesystem has larger tile sizes compared to when ATAK downloads the tiles from the WMS server. This makes the rendering of WMS downloaded tiles easier for the system to handle.

[takdeveloper]

@kenktk There should be noticeable improvement with this issue coming with ATAK 4.7. Performance should be more in line with ATAK 4.2 and prior.

There were a confluence of issues that contributed to the slowdown:

• 4.3 reimplemented the globe to pre-render the terrain surface (e.g. imagery) into separate textures, one per terrain tile.
  • Terrain tiles are defined on a uniform grid, and not clipped to the viewport. This results in more imagery tiles to be requested to fully form the scene.
  • ATAK does some prefetching of lower resolution terrain tiles that are offscreen to show data more quickly during pan/zoom. Terrain surface rendering for a given terrain tile evaluates at the resolution of that tile. For non-pyramided imagery this means subsampling. Subsampled imagery reads are more expensive than non-subsampled reads. The image reading worker can get bottlenecked if there are highly subsampled reads queued up.
  • Terrain tile population triggered imagery loading, meaning that imagery tiles would be queued in the order that terrain tiles were populated (arbitrary). This caused a general degradation in prioritization for data loadouts using imagery chips as opposed to tile pyramids.

As you noted, the texture size is also different between tile pyramids (256x256) and non-pyramid data (512x512). I know we explored switching to a 256x256 size -- but I can't recall whether or not it had an impact on throughput.

I will close this issue once the 4.7 release is pushed.