Vulkan: SDFGI incorrectly reads certain high-contrast textures for cascade generation

fLindahl commented 9 months ago

Godot version

v4.1.3

System information

Godot v4.1.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 6900 XT (Advanced Micro Devices, Inc.; 31.0.22023.1014) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

Issue description

Trying to use SDFGI, but I'm getting strange artefacts and incorrect bounce colors. Checked the cascades and the pictures show (I think) the problem.

godot_cascades godot_normal

Any ideas on why this happens?

I've tried loading different scenes with different textures, and it seems to work fine with most assets, but with these specific textures (no matter if they're jpg, bmp or png), it just doesn't work as expected. The textures are quite basic and without a lot of color, and I'm thinking that it might be a compression issue specifically for SDFGI. I've attached the GLB as well, so that others can test.

Steps to reproduce

Setup SDFGI in scene with directional light.
Add entrance.glb into scene
Enable visualization of SDFGI cascades

Minimal reproduction project

entrance.zip

Calinou commented 9 months ago

SDFGI doesn't use VRAM compression (it's generated in real-time), so this looks like a more generic type of corruption.

fLindahl commented 9 months ago

I did some further testing and took some more screens:

cascades normal

Those are the same view, same material, in sdfgi cascade view and normal view. I set the SDFGI cascades to be a single cascade and changed the cellsize to be 0.02 (very small voxels). You can make out that the "general shape" of the colors are there, but the actual colors are crunched into oblivion. Is there some bias towards more vibrant colors that goes bonkers with such low fidelity textures? I know I've seen biasing towards vibrant colors in other GI implementations to get more pronounced color bleeding effect.

Calinou commented 9 months ago

Please upload a minimal reproduction project[^1] to make this easier to troubleshoot. (The ZIP only contains a .glb file, not an entire Godot project.)

[^1]: A small Godot project which reproduces the issue, with no unnecessary files included. Be sure to not include the .godot folder in the archive (but keep project.godot).

Drag and drop a ZIP archive to upload it. Do not select another field until the project is done uploading.

Note for C# users: If your issue is not Mono-specific, please upload a minimal reproduction project written in GDScript or VisualScript. This will make it easier for contributors to reproduce the issue locally as not everyone has a Mono setup available.

fLindahl commented 9 months ago

SDFGCornell.zip

Minimal repro

Calinou commented 9 months ago

I don't see anything out of the ordinary in https://github.com/godotengine/godot/issues/85058#issuecomment-1819059184 (4.2.beta da0b1eb12, Linux, GeForce RTX 4090 with NVIDIA 535.129.03):

SDFGI disabled	SDFGI enabled

Remember to disable VRAM compression on the textures in the Import dock by using Lossless compression instead. The textures used are low-resolution, so they don't use much VRAM. That said, this doesn't affect SDFGI appearance in any noticeable manner either way. I've done this on the above screenshots, which fixes the grid pattern appearing on the gray checkerboard texture on the floor.

The SDFGI debug view does have this "crunchy" appearance that you mention, but in this particular example, it doesn't really affect how visuals will look in practice. Also, remember that the normal view uses specular lighting, while the SDFGI debug view doesn't. If I set the specular mode to Disabled on the materials used by the brick textures, it looks closer to the SDFGI debug view as the bricks' mortar can actually become black in the normal view:

Normal view	SDFGI Cascades view

Either way, SDFGI is planned to get a rework in a future 4.x version, so this may be incindentally resolved.

With entrance.glb, I can reproduce the issue mentioned in OP:

Disabling VRAM compression on textures doesn't resolve the issue. I've also tried increasing texture resolution by 4× on each axis using parallel mogrify -resize 200% ::: *.png to no avail.

Reducing texture contrast using parallel magick {} +sigmoidal-contrast 10,50% {} ::: *.png largely alleviates the situation:

That said, even with this reduced contrast (and increased brightness), lighting from SDFGI has a lot of trouble bouncing (it's barely visible in most cases).

Testing project: SDFGCornell_2.zip

godotengine / godot