Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulkan: Camera jitter when TAA is enabled on float=64 build #69528

Closed
Tracked by #69494
Qubrick opened this issue Dec 3, 2022 · 5 comments · Fixed by #80257
Closed
Tracked by #69494

Vulkan: Camera jitter when TAA is enabled on float=64 build #69528

Qubrick opened this issue Dec 3, 2022 · 5 comments · Fixed by #80257

Comments

@Qubrick
Copy link

Qubrick commented Dec 3, 2022

Godot version

v4.0.beta.custom_build [0ff8742] equivalent to beta 7

System information

Windows 11, RTX2060 Super Desktop, Vulkan

Issue description

Camera jitter when TAA is enabled on float=64 build.

I tested on normal build (custom build without float=64) and official pre-build of Godot 4 beta 7 as well.
There is no jittering on those builds. This only happens on float=64 build.

This also happens on previous version. For now, I only tested with beta 4 [e675154] and beta 7 [0ff8742].

In the video, you can see viewport before TAA is enabled, viewport after TAA is enabled and game window in respective order.

taa-camera-jitter-float64.mp4

Steps to reproduce

Enable TAA in float = 64 build.

I added mesh, directional light, and camera so you can see that jittering happens on game window too.
But you can remove it all and look at jittering wireframe in editor viewport.

Minimal reproduction project

Just open the project with float=64 build.
camera_jitter_taa_float64.zip

@Calinou
Copy link
Member

Calinou commented Dec 4, 2022

For reference, TAA jitter is expected (as it's required to improve quality in still scenes), but it shouldn't be this strong.

@clayjohn
Copy link
Member

clayjohn commented Dec 5, 2022

This looks like the TAA pass isn't happening at all and instead the raw internal buffer is being used.

@clayjohn clayjohn added this to the 4.0 milestone Dec 5, 2022
@DavidBradbury
Copy link

I have the same thing, but for now, it only seems to be affecting gizmos, not my imported meshes. For now I just turn it off while working, but it would be nice to turn off rendering settings while in the editor, but turn them back on when running. Maybe similar to Environment / Camera Attributes? (Which is a great change by the way)

@Calinou
Copy link
Member

Calinou commented Dec 8, 2022

but it would be nice to turn off rendering settings while in the editor, but turn them back on when running.

This can be achieved with by enabling TAA in a script's _ready() function while leaving the project setting disabled:

extends Node

func _ready():
	get_viewport().use_taa = true

Feature tags can't be used to achieve this, unless you exploit one of them that is pretty much always true due to #64100.

@Qubrick
Copy link
Author

Qubrick commented Apr 23, 2023

Seems like it's not just TAA.
Enable "Depth of Field Use Jitter" option in Project Settings alone cause this too on [16a6bdd]

Maybe it's about Double Precision cause strong jittering on everything that use jitter?

DarioSamo added a commit to DarioSamo/godot that referenced this issue Aug 4, 2023
…sulting in the TAA pass being completely broken.

See Issue godotengine#69528. When building with precision=double, the TAA pass would break due to the motion vectors being corrupted. It was apparent the origin of the camera itself was corrupted in the UBO for the previous frame because the camera origin was only being split correctly for the current block but not for the previous block (to effectively support the double precision float on the shader).
@akien-mga akien-mga modified the milestones: 4.x, 4.2 Aug 5, 2023
IntangibleMatter pushed a commit to IntangibleMatter/godot that referenced this issue Aug 13, 2023
…sulting in the TAA pass being completely broken.

See Issue godotengine#69528. When building with precision=double, the TAA pass would break due to the motion vectors being corrupted. It was apparent the origin of the camera itself was corrupted in the UBO for the previous frame because the camera origin was only being split correctly for the current block but not for the previous block (to effectively support the double precision float on the shader).
YuriSizov pushed a commit to YuriSizov/godot that referenced this issue Sep 21, 2023
…sulting in the TAA pass being completely broken.

See Issue godotengine#69528. When building with precision=double, the TAA pass would break due to the motion vectors being corrupted. It was apparent the origin of the camera itself was corrupted in the UBO for the previous frame because the camera origin was only being split correctly for the current block but not for the previous block (to effectively support the double precision float on the shader).

(cherry picked from commit 77776f5)
mandryskowski pushed a commit to mandryskowski/godot that referenced this issue Oct 11, 2023
…sulting in the TAA pass being completely broken.

See Issue godotengine#69528. When building with precision=double, the TAA pass would break due to the motion vectors being corrupted. It was apparent the origin of the camera itself was corrupted in the UBO for the previous frame because the camera origin was only being split correctly for the current block but not for the previous block (to effectively support the double precision float on the shader).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants