Ocean only renders in global +X/+Z quadrant direction, centered on camera, when using RADV Vulkan drivers on Linux about godot4-oceanfft HOT 4 CLOSED

As far as I can tell, the camera should always be in the center of the visible ocean.

Sort of. The ocean is a very large square centered on origin, so it should appear to be centered on the camera when the camera is near origin. It does not follow the camera though, so you can fly off the edge if you go far enough (several thousand engine units) in any direction.

I was able to figure out that this is a Vulkan driver related issue. This was not occurring on my Arch Linux computer which was using the AMDVLK drivers. I noticed in your screenshot in appears to be a Steamdeck, which uses RADV drivers. When I switch my system to RADV, I see the exact behavior you describe.

You can confirm whether your instance is running with RADV by looking the the Godot output when you run the example (note the very last part):

Godot Engine v4.1.1.stable.arch_linux - https://godotengine.org
Vulkan API 1.3.246 - Forward+ - Using Vulkan Device #0: AMD - AMD Radeon Graphics (RADV NAVI22)

The short term fix would be to switch to AMDVLK drivers when using this project for now, until I can figure out whether this is a project related issue I can solve, or if it is an engine or driver issue.

from godot4-oceanfft.

I have further narrowed this down within the ocean code as being related to the planetary curve code that takes place as the last step of the vertex stage in SurfaceVisual.gdshader. Commenting lines 167-168 also resolves the issue, and is less annoying than switching drivers.

from godot4-oceanfft.

I am indeed running on Steam Deck. I can confirm that commenting out those lines in the shader resolves the issue on my system as well. I haven't had time to try switching drivers, yet.

from godot4-oceanfft.

I have identified the root cause of this issue, and it is squarely on me, not the engine or drivers.

The built in shader functions, per the Godot docs, confirm to the GLSL ES 3.0 standard, and per that standard, the pow() function has undefined behavior when the base argument is less than or equal to 0. (https://registry.khronos.org/OpenGL-Refpages/es3.0/html/pow.xhtml)

The implementations of pow() in AMDVLK and the Windows AMD drivers (the only drivers I have tested myself) appear to handle this undefined behavior by taking the absolute value of the argument before using it.

RADV however does not appear to do this, and it handles the undefined behavior by breaking.

As it is undefined behavior though, it is my mistake for not reading the documentation more carefully to avoid this. The fix in this case is easy, and just requires wrapping the first argument of pow() calls in an abs() call per the commit I just pushed. There may be other issues I need to hunt now with the other usages of pow(), but this particular issue should be fix now.

from godot4-oceanfft.