Godot: High frame delay causes rendering issues with auto exposure enabled [GLES3]

[lekoder]

Godot version:
3.1.alpha 5a03d50

OS/device including version:
Windows 10
GPU: NVIDIA GeForce GTX 1070 MQ, driver: 411.63
GPU: Interl UHD Graphics 630

Issue description:
When game starts, just as first scene renders, it appears for a brief second frozen, with distorted colors:

Steps to reproduce:
Unable to reproduce in minimal project. Issue can be observed with demo version of ΔV: Rings of Saturn 0.20.0, available on itch.io - observed with windows builds.

It might be related to loading resources and auto-exposure of WorldEnvironment. Going to work around it by providing blank/black initial scene.

[akien-mga]

I doubt this is an engine issue, this must be related to the way you cache resources in the title scene and maybe add them to the scene tree (thus making them potentially visible) before the GUI is initialized on top of them.

Edit: Scratch that, further debugging proved that it's related to per pixel transparency.

[Xrayez]

It might be related to loading resources and auto-exposure of WorldEnvironment. Going to work around it by providing blank/black initial scene.

I can confirm that, specifically the auto-exposure of WorldEnvironment. I often experience this effect when the debugger catches some error immediately after scene startup, or even worse when the frame rate drops significantly.

[lekoder]

Isolated to this minial project. Took a while since I was stripping down my production code.

It is triggered in my case by:

func _ready():
    OS.window_per_pixel_transparency_enabled = false

[akien-mga]

CC @bruvzg

[lekoder]

Please note that I seen this effect without disabling per pixel transparency. It is a trigger, not a cause.

[akien-mga]

Do you see it if you don't use per pixel transparency at all?

[lekoder]

Yes. One way to trigger it without per-pixel transparency is to use Multi-Threaded or Single-Unsafe rendering model.

I have bug report of these artifacts happening when recording dV with OBS, but I was unable to replicate.

[lekoder]

I gave the issue some thought and I have a hypothesis. There are two separate things happening:

1. The WorldEnvironment Auto Expose starts up with maximum exposition in the first frame and adjusts to actual exposition in subsequent frames. This usually goes unnoticed, however...
2. Some things, like changing per pixel transparency, cause rendering engine to freeze for ~0.5-1 second. If it happens on the first frame, it exposes the problem.

[lekoder]

@Xrayez this issue was fixed for me with install of KB4462933 OS Build 17134.376 via Windows Update. Could you cross-check?

[Xrayez]

@lekoder just installed mentioned update manually, this hasn't fixed the issue for me, maybe it was due to graphics driver update?

Btw, this auto-exposure issue can be easily reproduced with:

Project Settings > Application > Run > Frame Delay Msec > set to 1000 (one second)

Some things, like changing per pixel transparency, cause rendering engine to freeze for ~0.5-1 second. If it happens on the first frame, it exposes the problem.

This simulates high CPU load and introduces enough delay.

[lekoder]

maybe it was due to graphics driver update

Might be, those things are tough to replicate if we don't know what exactly is triggering it - and I don't pay close attention to it, as I worked around it in my game. I assume the underlying problem is freezing for significant fractions of a second.

[akien-mga]

So it seems to be driver-specific in the end?

[Xrayez]

Not sure, doesn't seem so, this is still reproducible in master in my own project.

Upon further testing, I managed to create a minimal project (3.1):
auto-exposure.zip

The sprite will appear white if enough delay is introduced:

By enough I mean that the delay has to be as twice longer than the auto exposure speed! The default auto exposure speed is 0.5 sec, so 1 sec delay is the minimum time to cause the issue.

[Xrayez]

Setting OS.window_per_pixel_transparency_enabled is indeed not the cause, but it triggers the flickering by introducing the delay, and there are numerous other ways to trigger the delay, so maybe rename the issue.

[akien-mga]

Still reproducible in the current master branch with @Xrayez's minimal project.

[akien-mga]

It seems to only happen with the GLES3 driver, not GLES2.
CC @clayjohn.