Artifacts, wrong display on Android and iOS

[vhornik]

First, thanks for your great work!
It works perfect on desktop but when I tried the demo in Chrome Android (also Safari on iOS, or Firefox on Android) the visualization is broken, with strange artifacts, particles are certainly moving differently and unrealistically then with the same wind image data on desktop. See screenshot from Android:

iOS shows similiar wrong image...

On desktop browsers the wind flow looks as expected:

Screenshots come directly from https://mapbox.github.io/webgl-wind/demo/ (default setting) but I also tried the version from https://github.com/mapbox/webgl-wind/tree/mercator and it seems to have the same problems

[mourner]

Interesting! I tested on my iPhone and it worked well. Can you say more about what mobile devices you uses and which versions of OS / browsers?

[vhornik]

I am trying on Samsung Galaxy S7 with Android 8.0, and iPad with iOS 11.4.1
adding screenshot from the iPad

[vhornik]

Just in case you are interested in investigating the bug for mobile devices, I made this jsfiddle where it can be easier to see better where the problem could be: https://jsfiddle.net/3mxhsjn2/5/

result only:
https://jsfiddle.net/3mxhsjn2/5/embedded/result/

I used your demo from https://mapbox.github.io/webgl-wind/demo/ and replaced the real wind data images with a red only image, altered the json accordingly, now we have he same "west wind" everywhere... removed the map and also removed the "distortion" parameter so that the particles move same speed independent on "latitude". The result should be red particles moving left to right everywhere.

It works on all desktop PCs I could try, but on mobiles the only device where I could view it correctly is a new Samsung Galaxy Tab S4, other mobile devices that I tried (iphone SE, iphone 7, ipad (even with latest ios 12...), Samsung Galaxy Tab A10.1, Galaxy S7 etc.. all show the strange blocky animation as on screenshot. Maybe it's rather hardware related?

[Farkal]

The error is linked with the conversion from color to pos and from pos to color in the file update.frag.glsl

    vec4 color = texture2D(u_particles, v_tex_pos);
    vec2 pos = vec2(
        color.r / 255.0 + color.b,
        color.g / 255.0 + color.a); // decode particle position from pixel RGBA

    ...

    // encode the new particle position back into RGBA
    gl_FragColor = vec4(
        fract(pos * 255.0),
        floor(pos * 255.0) / 255.0);

If you remove all the code between this two operations you will see the particles converge to center on mobile/tablet and on desktop i will be immobile.
If you pass the initial color to gl_FragColor the particules stop converge to the center on mobile/tablet gl_FragColor = color
So we loose data from the conversion on mobile/tablet because they don't have the same float precision.
Do you think we could improve this conversion for mobile/tablet ?

[vhornik]

Yes, this seems to suffer the similiar problems. webgl is a complete mystery to me yet ;) but link I found that might help to someone more experienced: ?

https://stackoverflow.com/questions/18453302/how-do-you-pack-one-32bit-int-into-4-8bit-ints-in-glsl-webgl

[munrocket]

Yep packing is wrong.

[neuwcodebox]

Hi.
Thank you for sharing a great work.
I also encountered the same problem in mobile environment when using this source code.
I avoided this problem by storing the position of the particle in the RAM, updating the texture by processing the movement calculation in the CPU and preserving the existing texture-based logic.

Yes, This is not a solution use GPU. But I hope it helps people like me who have no other way than this source code.

Here are the commits that contain my solution.
Link

[msfstef]

Using the packing method from vhornik's link, and also Sly v's comment on the solution for iOS devices, I got it to work on an iPad as well.

I changed the packing method (x on rg and y on ba), and used the rounding to fix the issue.

const vec2 bitEnc = vec2(1.,255.);
const vec2 bitDec = 1./bitEnc;

// decode particle position from pixel RGBA
vec2 fromRGBA(const vec4 color) {
  vec4 rounded_color = floor(color * 255.0 + 0.5) / 255.0;
  float x = dot(rounded_color.rg, bitDec);
  float y = dot(rounded_color.ba, bitDec);
  return vec2(x, y);
}

// encode particle position to pixel RGBA
vec4 toRGBA (const vec2 pos) {
  vec2 rg = bitEnc * pos.x;
  rg = fract(rg);
  rg -= rg.yy * vec2(1. / 255., 0.);

  vec2 ba = bitEnc * pos.y;
  ba = fract(ba);
  ba -= ba.yy * vec2(1. / 255., 0.);

  return vec4(rg, ba);
}

[vhornik]

Great, this seems to work for me too (at least when I am testing Samsung Galaxy S10)

original encode/decode with artifacts:
https://jsfiddle.net/nfym81qe/1/

msfstef's encoding/decoding:
https://jsfiddle.net/nfym81qe/2/

in the meantime, what worked for me was to actually use full RGBA to store each float coordinate

const vec4 bitEnc = vec4(1.,255.,65025.,16581375.);
const vec4 bitDec = 1./bitEnc;

vec4 EncodeFloatRGBA (const float v) {
    vec4 enc = fract(bitEnc * v);
    enc -= enc.yzww * vec2(1./255., 0.).xxxy;
    return enc;
}

float DecodeFloatRGBA (const vec4 v) {
    return dot(floor(v * 255.0 + 0.5) / 255.0, bitDec);
}

then I used 2 different textures to store particle positions, and used 2 update.frag shaders - one that writes the x the other y)

[munrocket]

@msfstef nice solution, thanks! It works on iPhone 6. I am used 2 drawcalls before this too.

[guigrpa]

@msfstef Your solution was almost perfect, thanks a lot!

I noticed though that resolution was good towards the top of the image, but coarser at the bottom. This can be fixed by updating both draw.vert.glsl and screen.frag.glsl to use precision highp float instead of mediump.