osmandapp / OsmAnd

OsmAnd
https://osmand.net
Other
4.65k stars 1.02k forks source link

Tiles fail to render if too close to the camera #18460

Closed mikehgentry closed 11 months ago

mikehgentry commented 12 months ago

Description

I use the relief layer from

https://maps-for-free.com/

I can't remember exactly where I got the parameters from, but if you search around you'll find discussion of using their layer in various applications. So I ended up with

https://maps-for-free.com/layer/relief/z{0}/row{2}/{0}_{1}-{2}.jpg

Rendering has always been a little erratic, but it basically works at lower zoom levels. At high zoom it only seems to be able to render tiles a certain distance away from the camera. This is evident even without map tilt - if you're using a profile with display position set to bottom, you can end up with it happily rendering tiles at the very top of the screen, but failing to render them in the middle. It gives up at about zoom 14 on legacy rendering, and about 18 on OpenGL.

https://github.com/osmandapp/OsmAnd/assets/1724168/03b05a93-7728-4f90-945f-ad65d6bad441

If you tilt the map significantly, this becomes even more apparent - there's a line right in the middle of the screen where it stops rendering

https://github.com/osmandapp/OsmAnd/assets/1724168/4d504c7c-2923-4831-a793-41d2fe7f3c4d

Interestingly, this effect is also present with the generated 'Slope' terrain layer - it renders the whole way across the screen, but there's a clear difference between the top and the bottom (and it looks like it's rendering properly at the top).

https://github.com/osmandapp/OsmAnd/assets/1724168/ebe5a8c8-3dc7-4cf5-8a2e-f15e45b5d4c5

(it was a bit harder to capture this last one because the rendering slows down a fair bit with the screen recorder on using vector maps - if you have trouble recreating it I can probably make a better video)

Steps to reproduce

Either use

https://maps-for-free.com/layer/relief/z{0}/row{2}/{0}_{1}-{2}.jpg

Or add the 'Slope' style of terrain. On my device on OpenGL problems start at zoom 17 - 18 ish.

Actual result

Inconsistent rendering

Expected result

Consistent rendering

Your Environment (required)

WARNING Crash-Logs MAY contain information you deem sensitive. Review this CAREFULLY before posting your issue!

OsmAnd Version: + 4.6.4
Android/iOS version: 11
Device model: XCover 4s
Crash-Logs: ?
DmitryAlexei commented 12 months ago

OsmAnd~ 4.6.0#934m, released: 2023-10-29 Android 13, Samsung galaxy note 20

Steps to reproduce:

Actual result

mikehgentry commented 12 months ago

It isn't necessary to tilt the map - here's a better video of the last example. Note: this only happens with display position set to bottom.

https://github.com/osmandapp/OsmAnd/assets/1724168/8e7692bb-510b-437e-8ab6-8a8889d302ac

(I'm finding it more obvious with the Slope shading than the Hillshade for some reason)

edit - also, might be worthy of note that in the first two videos above I was using that map as the primary layer, not an overlay

edit 2 - sorry, I was wrong, it's happening with display position set to centre too. It's more obvious with it set to bottom, and I think it only recently started doing it with it set to centre.

vshcherb commented 11 months ago

Probably it will be hard to fix cause the camera is "inside the hill"

mikehgentry commented 11 months ago

Might be worth renaming the issue to make it easier for others to find - I don't think the present name fits very well (it happens with primary layers, and without tilt).

vshcherb commented 9 months ago

To do : avoid too close zoom rendering with 3D relief on. So in most of the use cases the zoom fractional part shouldn't exceed > 1.5-2. Watch real use case where it was 17 + 2, 17+3... which caused significant visual artefacts.

mikehgentry commented 9 months ago

I'd still choose that given the choice (I'm using this profile outside on a bike, and don't need much detail / resolution).

Maybe to avoid the impression of jankyness an option to override the limit could be hidden in the developer plugin or somewhere. Or maybe there's a way to avoid those issues by rendering at lower precision then upscaling it (presumably at a performance cost and with some pixellation).