#2634 ALS water: fast waves due to wind interpolation

Waves going too fast on ALS water as reported in the thread https://forum.flightgear.org/viewtopic.php?f=37&t=29912 seem to be caused by the wind interpolation mechanism, and occurs both on Basic and Advanced weather.

When this occurs, waves go in different directions on different polygons of water, whereas normally the mismatch of texture edge between them is still visible but the waves move properly in the same direction. This could mean that something that sets the speed and initial position of moving texture sets it slightly different from what it was.

Reproduction:

1. $ fgfs --aircraft=ufo --airport=TNCM or other airport with water nearby.
2. Check "Rendering Options / ALS" and turn up "Shader Options / Water" to max or one below max.
3. Adjust wind at sea level in "Weather / Basic Weather / Manuual Configuration".

With /environment/sea/config/wind-filter-time reduced by a factor of 10 the problem becomes less pronounced but never goes away completely.

[Colin Geniet]

I think I have a reasonably good idea of what goes wrong—but no idea how to fix it.

The issue occurs precisely while /environment/sea/surface/wind-from-{east,north}-fps are changing (it's easy to check with the property browser, with reproduction steps indicated by Michael).

When the wind changes, Environment/interpolator.xml smooths the wind parameters /environment/sea/surface/wind-from-{east,north}-fps.
(this is where wind-filter-time has an effect).

These properties are used as uniforms Wind{E,N} in Effects/water.eff.

Shader water-ALS.vert uses them as follows (around line 102, irrelevant code removed):

    vec4 t1 = vec4(0.0, osg_SimulationTime * 0.005217, 0.0, 0.0);
...
    float windFactor = sqrt(WindE * WindE + WindN * WindN) * 0.05;
...
    waterTex1 = gl_MultiTexCoord0 * RotationMatrix - t1 * windFactor;
...

The wind vector is multiplied by time (and some constants), and used as offset for textures.
If the wind vector is constant, it means the textures are moving at a rate proportional to wind,
which seems to be what is intended.

But as soon as the wind vector changes (and in particular if it changes smoothly), this expression doesn't make any sense as far as I can tell, and results in the fast moving water texture.
I think windFactor * <time> should instead be an integrator to have the desired effect.

But then there is the problem of RotationMatrix, which corresponds to the wind direction, and has similar problems (as the wind turns, the entire wave texture turns as a single block).

And there may also be other problems in the fragment shader (which also uses the wind vector), I have not looked into that.

[James Turner]

The sqrt(WindE * WindE + WindN * WindN) computation is trying to compute a direction-less wind velocity : that should be correct even as the window-from-foo-fps properties change, I think? It's slightly wasteful to do this computation per vertex, but I guess we have comparativley few water vertices.

[Colin Geniet]

That was not the issue, the first two lines of that block of code were just for context.

The problem is when the wind velocity is multiplied by time to get texture offset (last line).
I think the intent is to have the texture move, with speed proportional to the wind.
For this, offset = time * wind, works when wind is constant, but does weird stuff as soon as the wind changes (it should be replaced by an integrator).

[James Turner]

Right, but an integrator implies some state, which is what (presumably) we're trying to avoid in the shaders since it's expensive. I guess the question is can we define a stateless approximation which doesn't have the visual aretfacts, or can we spare some uniforms to make a stateful solution?

I think the stateful solution would be a vec2 'waveTextureOffset' which we run a C++ side integration of wind direction + velocity each frame. The resulting vec2 would wander (with wrapping) over the 0.0..1.0 tex coords, and we'd usr that as the offset in the vertex shader.

[ranguli]

With the move to the HDR pipeline on the horizon (which contains a new water shader), perhaps it's best to mark this issue as WontFix, depending on how long ALS will still be supported?

[Agri Kola]

Not fixing this is barely considerable only if the project decides not to have a stable, bugfree release 2024.1. Ignoring known bugs will not achieve that.

[Fernando García Liñán]

See this mailing list thread https://sourceforge.net/p/flightgear/mailman/message/58849029/

The water texture coordinate offset due to wind will be disabled in 2024.1.

[Agri Kola]

I am up to date with 2024.1 but have not seen any improvement. Is it disabled yet?
A question: Is the property /environment/sea/config/wind-filter-time involved in this?

[James Turner]

I think we just forgot the fix, have made a note.

[Manuel Ace]

It would be great if you could fix this bug, as it has a very negative visual impact when flying in coastal areas. I'm sure we've all spent a lot of time trying configurations without success... I'd love to help, but it's beyond my knowledge.
Best regards, and congratulations on 2024.1