Instancing GPUParticles3D Causes Flashes Onscreen

[The-Randalorian]

Godot version

v4.0.beta14.official [28a2463]
v4.0.1.stable.official [cacf499]

System information

Windows 11 22H2, Forward+, NVIDIA MX350 (528.02) and NVIDIA RTX2070 (517.00)
Ubuntu 22.04, Forward+, NVIDIA MX350 (525.85.05)

Issue description

Instancing a GPUParticles3D can cause colored flashes on screen. In some cases (such as the minimal reproduction project), the flashes are small, however in my other project I have seen them fill the screen. I am still unsure what causes the different sizes

These are some example correct frames from the minimal reproduction project (the effect is supposed to be a fireball.)

These are some example incorrect frames.

Steps to reproduce

Create two scenes, one with a GPUParticles3D, and one that instances those particles repeatedly, using a script. Flashes will occur on screen.

Minimal reproduction project

Particle Flash MRP.zip

Edit 1: Corrected driver version for my friend's computer.
Edit 2: Added note about the issue also appearing on Linux, and that the issue is still present in 4.0.1

Bugsquad edit (keywords for easier searching): flicker, flickering

[Calinou]

Related to #70546.

[clayjohn]

Might be fixed already by #71925

Could you test with #71925 and see if it fixes the issue for you?

[The-Randalorian]

I don't currently have the setup to build the engine myself.

[clayjohn]

No problem, #71925 was just merged, so you can test again when Beta 15 releases in the next couple of days!

[The-Randalorian]

Just tested it in v4.0.beta.custom_build [379d83dd5], which had #71925. The issue persisted.

I am attempting another build with some of the newer commits (up to 70377), to verify that I didn't mess up something with git, but I'm pretty sure I did everything correctly.

Edit: Yes, the issue persists in v4.0.beta.custom_build [1dfd236], up to #70377.

[The-Randalorian]

I should note the flashes that appear seem to be the particle mesh; the round shape is due to the radial gradient used for the flame effect. Using a noise map yields a result like this (only the first picture is correct.)

[IvanIG3]

I'm also having this issue in 4.0.stable. It happens almost always, when I create a new instance of a GPUParticles3D. In the video below, 3 of the 4 instances generates a big colored flash.

Base.Profile.2023.03.15.-.16.08.39.01.mp4

[The-Randalorian]

The issue is not limited to just windows, also appearing on my laptop after I swapped it to Linux. I have added a note to the original issue.

[hunterloftis]

I'm experiencing the same thing with Godot_v4.0.1-stable_linux.x86_64 on Fedora 37. It's intermittent, but always happens a few times:

godot-particle-flash-bug.mp4

[Calinou]

I can confirm this on 4.0.1.stable (Linux, GeForce RTX 4090 with NVIDIA 525.89.02).

Epilepsy warning: The videos below contain flashing.

Default MRP settings

simplescreenrecorder-2023-03-29_19.07.11.mp4

Interpolation disabled, Fixed FPS = 0 (use render FPS)

simplescreenrecorder-2023-03-29_19.08.15.mp4

Interpolation disabled, Fixed FPS = 1

simplescreenrecorder-2023-03-29_19.08.28.mp4

Preprocess = 0.25s (same as Lifetime)

simplescreenrecorder-2023-03-29_19.08.46.mp4

[KylerBessert]

I got a link to this bug after posting about this issue. I can confirm it is a bug in v4.0.2 . I will watch this bug report going forward, thanks Calinou for the link to this post!

[The-Randalorian]

v4.1 dev 1 still has the issue, despite some of the other particle fixes.

From the blog post:

• Particles: Properly calculate lifetime_split for particles (GH-73313).
• Particles: Translate inactive GPUParticles3D particles to -INF (GH-75162).
• Particles: Fix “error X3708: continue cannot be used in a switch” in HTML export (GH-75795).

[KylerBessert]

I hope this can be looked into further before v4.1 release, while it can be totally worked around and is only visually impacted, this bug really hurts the particle system as a whole in Godot Vulkan.

[IvanIG3]

I hope this can be looked into further before v4.1 release, while it can be totally worked around and is only visually impacted, this bug really hurts the particle system as a whole in Godot Vulkan.

What do you do to workaround this issue?

[KylerBessert]

What do you do to workaround this issue?

Oh sorry, I meant it like I just deal with the issue and you can work around it being there, its not engine breaking or anything. It may not usable if you are prone to epileptic seizures though.

[The-Randalorian]

I hope this can be looked into further before v4.1 release, while it can be totally worked around and is only visually impacted, this bug really hurts the particle system as a whole in Godot Vulkan.

What do you do to workaround this issue?

I've had limited success through moving the rest of the game world away from the origin, but it's not a consistent or reliable fix. Sometimes the particles appear HUGE, and will therefore still cause flashes even if the level is a decent distance from the origin. Trying to move the level further can yield physics and rendering bugs as the floats get less precise.

[RichardR01]

Godot 4.02, and 4.03 rc2:
I am having similar issues. I have an animation, where 12 missiles are being instanced. The missile has 2 GPUParticles3D to create the effect of flame and smoke. They start turned off. When the player presses the "fire" button, it enables the physics and turns on the particles after a brief timer timeout. The player can fire consecutively, firing all 12 missiles. The player can also reload, adding even more. The problem doesn't surface the first time, but after the 2nd or 3rd reload, I am seeing flashes of white on the right hand side of the screen, and particles being drawn in places they don't belong.

I forgot to mention I have this code, thinking it would help (it doesn't):

func _on_tree_exiting() -> void:
	if is_queued_for_deletion():
		fire_fx.emitting = false
		smoke_fx.emitting = false

I also forgot to mention, each missile uses 400 particles.

[RichardR01]

I found something that helps. Keep the emitting on, set the visible property to false. Set the preprocess to 0.1. I also set the visibility to false in the exit function. That way when the particles are instantiated, they are running but not visible, with the 0.1 preprocess buffer.

Edit: I need to test more, but any of the things I mentioned could have helped, or all together. It doesn't make sense to have to set the visibility to false right before it's freed, so who knows.

[clayjohn]

This looks to be an issue specifically when draw_order is set to "view depth". Looking at the particles buffers. It seems the positions get out of sync in that case. I'm still investigating where the issue comes from, but this should be fixable in a safe way for 4.2 and 4.1.1

[IvanIG3]

This looks to be an issue specifically when draw_order is set to "view depth". Looking at the particles buffers. It seems the positions get out of sync in that case. I'm still investigating where the issue comes from, but this should be fixable in a safe way for 4.2 and 4.1.1

I can reproduce this bug with any draw_order setting. Maybe I'm wrong but I don't think this is exclusive for "view depth".

[clayjohn]

@IvanIG3 You can reproduce the issue with all draw_order settings with the MRP from this issue, or in your own project?

Edit: It looks like Z - billboard also causes the issue. So it isn't limited to only view depth

[clayjohn]

I've made a PR that fixes the MRP from this issue. #78852

@IvanIG3 I would appreciate if you could test #78852 and confirm whether it fixes your project as well

[IvanIG3]

I've made a PR that fixes the MRP from this issue. #78852

@IvanIG3 I would appreciate if you could test #78852 and confirm whether it fixes your project as well

@clayjohn I don't know how to do that. I made a MRP, extracted directly from my project. Could you test it? You only need to run the project and click the "play" button. The bug triggers 50% of the time. If it doesn't with a few clicks, then I think it's safe to say that the bug is fixed. Thanks!

GPUParticlesBug.zip

[clayjohn]

@IvanIG3 #78852 fixes your MRP as well :)

You can expect the fix in 4.2 and in 4.1.1 (it is a little bit too late for 4.1, but 4.1.1 should only be a few weeks behind)