More display issues on Galaxy S6

[stleusc]

Note sure anymore if it's the high res since I'm also getting other render artifacts. Attached pics from the provided demo app using the latest vtm from today.

It happens with VTM provided map data and also Mapsforge map. Any help?

[stleusc]

As seen in this picture, the vertical/horizontal lines (I called them gaps before) also show up in demo app using VTM data. Also, there seem to be an offset/shift in the road data.

However, the building's seem to draw fine! Wonder if there is some odd clipping going on somewhere?

[stleusc]

GPU info from device...

vendor = {java.lang.String@21391} "ARM" renderer = {java.lang.String@21392} "Mali-T760" version = {java.lang.String@21393} "OpenGL ES 3.1"

[stleusc]

Maybe related to #119

[hjanetzek]

yes, this is most likely the same issues with somehow messed up projection and texture coordinates. I didn't have device to reproduce this yet. When I have the time I'll try to reduce any use of opengl that goes slightly beyond the minimal functionality needed to draw a textured triangle..

[stleusc]

What can I do? I have zero opengl knowledge but if you have ideas to narrow it down I'd love to do that. I really need a fix for that.

Tnx On Apr 21, 2015 5:22 AM, "Hannes Janetzek" notifications@github.com wrote:

yes, this is most likely the same issues with somehow messed up projection and texture coordinates. I didn't have device to reproduce this yet. When I have the time I'll try to reduce any use of opengl that goes slightly beyond the minimal functionality needed to draw a textured triangle..

— Reply to this email directly or view it on GitHub https://github.com/opensciencemap/vtm/issues/148#issuecomment-94718119.

[stleusc]

In some of the glsl files I see lines like:

precision mediump float;

Could low precision be an issue here? Ok, I'm really just throwing out stuff to get this resolved...

[stleusc]

In the last image the bottom left tile seems to be higher (z-axis). The width of the road going north is wider than in the tile above. Anything that could cause that?

[hjanetzek]

Did you try precision highp float; for the line shaders? Since the texture coordinates (packed as the 2 least significant bits with the extrusion vector) are definitely wrong I would first see if this is the only problem. Use a fixed color by setting:

gl_FragColor = u_color;

[stleusc]

where could I try that? I mean, which file?

[hjanetzek]

line_aa.glsl and line_aa_proj.glsl

[stleusc]

so you say only try and change the FragColor lines? and the highp? in both files? sorry, zero knowledge of OpenGL :-(

[hjanetzek]

yes :)

[stleusc]

OMG! you are really good! Results: a) no change on issue #147, same gaps still present b) the ends of roads are now not rounded anymore like before, BUT the artifacts are basically gone! Edges appear a bit rougher but generally 99% better!

Any ideas how to smooth that out?

If you want, I can create screenshot of same map from S4 and S6 device using old code on S4 and new code on S6 to compare. Let me know if needed.

[stleusc]

roughly same are, same device, new code compare this to very first image! besides the 'straight' ends of line segments it's working again!

Do all GPU support highp? Or is the true fix the 2 bit color thing?

[stleusc]

OK, above results are based on changing ONLY line_aa file. Missed the change in the other file ;-) When is which file used?

[hjanetzek]

hmm, could you try what happens by only changing to the precision to highp and restoring gl_fragColor? just checked that mediump on gles must only provide provide +-2^10 integer range which does not suffice..

[stleusc]

Ok, now I applied the change to the other file as well (as I should have the first time). Now the ends are rounded again!!! So what does the fragColor really do? I don't see a real difference to other device running old code anymore?!

Only thing left is issue #147 that is also visible in mapsforge maps.

[stleusc]

Have to take that back... Buildings appear to have issue now :-(

[stleusc]

current change is ONLY highp! buildings 'disappear' when zooming/dragging but ONLY when extrusion is active. Zooming out to 'flat' buildings shows them correctly.

[hjanetzek]

thanks for the hint to look into precision again :)

the building not being drawn is more likely a problem with the mapsforge datasource where the winding of polygons may have the wrong direction for tessellation, and an issue for another day..

about the annoying flickering lines: you say their color is taken from the gridlayer. what about removing the grid layer? :) or maybe using thicker lines so that they dont get lost in subpixel space

[stleusc]

I need some gridlayer in the back since loading live tiles might be slow and you need something in the background. right now gray grid. Even plain gray will shine through. If I make it dark then it will show more on street maps. I think it is also precision issue. How are the bitmaps rendered?

[hjanetzek]

yea, maybe - try highp in for texture_alpha.glsl

[stleusc]

nope that did not help....

[hjanetzek]

then, if it is about precision, base_shader.glsl also needs highp as it is used to write the clipping region

[stleusc]

change is base_shader fix that one! So, I want to minimize changes and maximize compatibility with devices... I read somewhere that not all fragment shaders support highp. So what half of th glsl is the fragment shader? I want to try to make minimum changes while still achieving the goal.

[stleusc]

Ok, I played with it. It seems I only need highp in the top half of the file. line_aa line_aa_proj texture_alpha base_shader are the only 4 files I changed. Combined it fixes both issues #147 and #148.

I'm not an expert on it, so I don't really wanna push that change but if you could create an official change for it one day it would be great. I just don't want to break iOS, or other platforms.

Great job! Even though both have solutions I think we should keep them open until they are resolved .

[hjanetzek]

In (my custom) glsl file format the part before ^$$ is the the vertex shader, the second part is the fragment shader. highp is actually the default for the vertex shader when not specified as I recently learned. for a opengl crash course related to map rendering I can recommend https://www.youtube.com/watch?v=WN71rEcs5g8

the changes to explicitly use highp in vertex shaders are already pushed

[stleusc]

poly_texture contains § instead of $$, is that a bug?

[stleusc]

Closing this issue, fixed.