Calinou
commented
2 years ago See also https://github.com/godotengine/godot-proposals/issues/3348.
There are a lot of potential questions with this:
- Multiple particles can die within the same simulated particle frame. The position parameter should probably be an array to account for this.
- The velocity normal is probably needed as well. We may need to add a dedicated return type to return as an array (e.g.
Array[CPUParticles3DExpiration]) instead of just returning aPackedVector3Array. - Handling this signal in a script can easily end up being expensive, especially when you're spawning other expensive nodes such as Decal.
- For small decals, using a transparent PlaneMesh is a better idea.
But, most importantly…
- Communicating from the GPU back to the CPU is either very expensive or impossible. Therefore, this is likely only feasible for CPUParticles3D, not GPUParticles3D. For GPUParticles3D simulation to be efficient, everything needs to happen on the GPU – no exceptions.
jcostello
Describe the project you are working on
Testing 4.0
Describe the problem or limitation you are having in your project
Working on a meteor shower example where a meteor is a particle, there is no way to spawn nodes like a decal where a particle died.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
The particle node would emit a signal for each particle that died with the particle position.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Read above
If this enhancement will not be used often, can it be worked around with a few lines of script?
No
Is there a reason why this should be core and not an add-on in the asset library?
GPU Particles are core