Add particles_updated and particles_expired signals to CPUParticles

[Calinou]

This can be used for various effects and even gameplay purposes:

• Add lights that follow individual particles.
• Add sound effects that follow individual particles.
• Add particle nodes that follow individual particles (either CPUParticles3D or GPUParticles3D). This can be used to emulate subemitters for CPUParticles3D.
• Detect collisions with areas or physics bodies, and make the areas or physics bodies react accordingly.
  • Individual particle reporting is read-only, so the particles themselves cannot react to collisions this way. GPUParticles3D supports collision, but they don't support individual reporting on the CPU (since communicating from the GPU back to the CPU is too slow).
    • Need both individual particle reporting and collision? It may happen one day…
• Spawn lights, sound effects or other particles at the location of a particle that just expired.
  • This is a separate signal as it'll be emitted less often than particles_updated, which can therefore perform better when you don't need to know particle transforms on every particle tick. If we follow along this design, I expect particles_collided to also be a separate signal from particles_updated if CPUParticles collision is implemented.

This closes godotengine/godot-proposals#3349.

Testing project: test_cpuparticles3d_signal_dictionary.zip

Testing project for old commit: test_cpuparticles3d_signal_class.zip

Preview

Local/Global coordinates support

cpuparticles3d_signal_1.mp4

Explosiveness

cpuparticles3d_signal_2.mp4

Lights reflected in VoxelGI

cpuparticles3d_signal_3.mp4

Spawning boxes on expiration locations

https://www.youtube.com/watch?v=rOLA_-IZ4jM

TODO

• Add Max Particles Reported property which limits the number of particles reported in total during the particle's lifetime. This would affect both particles_updated and particles_expired. Spread out the particles reported over the lifetime smoothly. If set to 0 (default), the signal is never emitted to avoid incurring any performance cost.
• Port to CPUParticles2D.

[lawnjelly]

If this is using dynamic allocation for each particle within a particle system per frame, then it is a really really bad idea. Particles should usually be super lightweight data orientated. If they absolutely have to be objects they should be pooled. But really they should just be data imo.

[Calinou]

There's already a Particle struct, but I can't emit it to scripting using a signal.

[lawnjelly]

Can the signal not come from the particle system, rather than the particle?

[Calinou]

Can the signal not come from the particle system, rather than the particle?

This is already what happens, but the issue is passing the data to the signal in a way that is compatible with the scripting API. GDScript does not have a struct type, so type-safe data must be passed via custom objects.

We could emit an array of dictionaries in the signal, but it's not strongly typed. This means there's no autocompletion and errors will only occur at run-time in scripts (instead of compile-time). Parts of the Godot API use dictionaries for that reason, but I feel this is something that should be avoided in the long run.

[lawnjelly]

Making the particle system super inefficient to work around bugs / deficiencies in the scripting seems a case of the tail wagging the dog. Imo it is important the particle system works efficiently, then problems in gdscript can be addressed in further PRs.

[Calinou]

I've pushed a second commit that switches to a Dictionary[] return type.

[Calinou]

Rebased and tested again, it works as expected. See OP for updated MRPs, both for the initial commit and the second commit that switches to a Dictionary[] return type.