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

GPUParticles don't emit finished signal when oneshot is set true in gdscript #93991

Open
JUSTCAMH opened this issue Jul 6, 2024 · 5 comments

Comments

@JUSTCAMH
Copy link

JUSTCAMH commented Jul 6, 2024

Tested versions

  • Reproducible in 4.3.beta2
  • Reproducible in 4.2.1.stable

System information

Godot v4.3.beta2 - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.3619) - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 Threads)

Issue description

When setting oneshot to true on a GPUParticles2D node, the particles visually stop emitting some time later as expected, however the 'finished' signal is not emitted. This does not occur with CPUParticles2D. I have not tested this for 3D particles, but I presume that this also applies to the GPUParticles3D.

Steps to reproduce

  • Open the MRP below
  • There are two particle emitters, the left is GPU and the right is CPU.
  • Both are setup the same, and each have a custom script. In this script, the emitters are set to have oneshot enabled on ready. A function is connected to the finish signal which will print a message and free the particle emitters.
  • Play the game. Both particle emitters visually stop emitting, however only the CPU particles prints a message and frees itself. Checking the remote hierarchy, you can see that the GPUParticles2D is still present despite nothing being emitted; the finished signal should have emitted!
  • If the oneshot setting is enabled on the GPUParticles2D from the beginning (rather than being set through gdscript), then the finished signal correctly emits.

Minimal reproduction project (MRP)

particles-finished-bug.zip

@JekSun97
Copy link
Contributor

JekSun97 commented Jul 6, 2024

I confirm this problem

@4X3L82
Copy link

4X3L82 commented Jul 6, 2024

I reported something similar in #93546.

@patwork
Copy link
Contributor

patwork commented Jul 6, 2024

Perhaps this is related #76859 (comment)

❗ UPDATE: try using restart() instead of emitting = true (godotengine/godot-proposals#7322)

@4X3L82
Copy link

4X3L82 commented Jul 6, 2024

Perhaps this is related #76859 (comment)

❗ UPDATE: try using restart() instead of emitting = true (godotengine/godot-proposals#7322)

But that comment is about how to start a particle emitter, while this issue (and #93546) is about finishing it?
Not to mention on my issue #93546 I do use restart() and I still don't get a finished() signal.

@patwork
Copy link
Contributor

patwork commented Jul 6, 2024

This is script from the MRP in this issue (sorry, I didn't look at yours):

extends GPUParticles2D

func _ready() -> void:
	one_shot = true
	emitting = true
	finished.connect(finish)


func finish() -> void:
	print("GPU Particles Destroyed!")
	queue_free()

After adding restart() in _ready() function signal will be emitted.

IMHO he problem lies in the fact that the one_shot value is changed when the emitter is already added to the scene tree and has an active emitting state.

void GPUParticles2D::set_emitting(bool p_emitting) {
// Do not return even if `p_emitting == emitting` because `emitting` is just an approximation.
if (p_emitting && one_shot) {
if (!active && !emitting) {
// Last cycle ended.
active = true;
time = 0;
signal_canceled = false;
emission_time = lifetime;
active_time = lifetime * (2 - explosiveness_ratio);
} else {
signal_canceled = true;
}
set_process_internal(true);
} else if (!p_emitting) {
if (one_shot) {
set_process_internal(true);
} else {
set_process_internal(false);
}
}
emitting = p_emitting;
RS::get_singleton()->particles_set_emitting(particles, p_emitting);
}

If signal_canceled is set, signal will not be emitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants