Deprecate CPUParticles

[QbieShay]

Describe the project you are working on

Godot Engine

Describe the problem or limitation you are having in your project

Particles have been a daunting area to maintain, because even with their small surface, they're actually quite tedious to work with. As i got deeper into VFX (now I do that for living), i realized there's many many things that artists need that Godot didn't provide. So i implemented the bulk of it in this PR
However, while doing this, I realized how complex it actually is to port my changes to CPUparticles and I simply, do not have the bandwidth to do it and maintain it long term. CPUParticles and GPUParticles had subtle differences and bugs already for the whole course of life of Godot3, and they're still not exactly equal as of Godot 3.6.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

• Considering Reduce maintainance cost of particle nodes #7344
• Considering https://twitter.com/reduzio/status/1685666760849002496 : most people seem to use them for compatibility with older devices, but to my understanding which comes from direct conversation with the rendering maintainers, CPUParticles will bring no significant benefit over GPUParticles in the gles3 backend
• considering Add support for particle recording and playback #7085

I propose to deprecate CPUParticles, after supplying a converter from CPUParticles to GPUParticles. (#2997)

Note that CPUParticles are just a wrapper around MultiMesh instance. They can be re-implemented as an addon.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

CPUParticles 2D and 3D are marked as deprecated. Some easy way to migrate the project from CPUParticles to GPUParticles should be provided (I do not know exactly how compatibility tools are provided in Godot4 but i know they exist)

A tentative roadmap could be mark as deprecated in Godot 4.2, then remove them in Godot 4.4 (with a forced converter)
Any script inheriting CPUParticles also will need to be either converted, or at least the user should be prompted some action for them.

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?

/

[AThousandShips]

What is the principle on removing functionality, should we really make such a drastic removal in a minor version? Can mark it as deprecated and not include in builds with the setting, and make it clear that it is deprecated and no longer receives support

[QbieShay]

I don't think this removes functionality, GPUParticles are as capable as cpuparticles (and soon even more capable). If there's an automatic way to push all cpuparticles to gpuparticles, it should be mostly seamless for people. The only issue they'll have is if they script CPUParticles, which i imagine will be a tiny percentage of users, since it's not actually possible to script behaviour in CPUParticles.

[Calinou]

Note that GPUParticles can't support precise collision without baking or manual authoring or signals on particle update and expiration, while CPUParticles could do that.

Therefore, I think CPUParticles still have value as a specialized tool. Basically, this is how I see CPUParticles and GPUParticles relating to each other in each Godot version:

• Godot 2.x: CPUParticles as the only particle solution.
• Godot 3.0: GPUParticles as the only particle solution.
• Godot 3.1+: GPUParticles and CPUParticles available, but CPUParticles is de facto recommended in most cases for GLES2 support and fast GLES3 support on macOS. Use GPUParticles if you need custom shaders.
• Godot 4.0+: GPUParticles and CPUParticles available, but CPUParticles is de facto recommended in most cases for OpenGL-on-macOS support. Use GPUParticles if you need custom shaders.
• Godot once we have ANGLE merged: GPUParticles and CPUParticles available, but GPUParticles is recommended in most cases. Use CPUParticles if you need features not technically feasible in GPUParticles, such as precise collision or signals with per-particle information.

[QbieShay]

I don't think that precise collision and signal on death justify the maintainance cost of 3 separate particle nodes

[QbieShay]

To add more information on this: CPUParticles were added because gles2 couldn't do GPUParticles.

Now that Godot4 has vulkan and gles3, the reason for cpuparticle to be there should be re-evaluated based on what usecase they serve. gles3 can support gpuparticles. they're compatible with web (they don't use any extension on gles3). The only issue arises with mac on gles3, but mac builds can be done with vulkan instead, and the issue will be solved anyway with angle.

I do believe if they didn't exist, and someone came today and asked us to implement them to support the above mentioned cases, we'd say no for the maintainance cost. This is a feature that we dragged from 3.x but doesn't have good enough benefits to be worth the tradeoff.

[Calinou]

I do believe if they didn't exist, and someone came today and asked us to implement them to support the above mentioned cases, we'd say no for the maintainance cost. This is a feature that we dragged from 3.x but doesn't have good enough benefits to be worth the tradeoff.

Before taking a decision, I think we need to wait until ANGLE is merged, a new Godot version with ANGLE is released and people start using GPUParticles in production on all platforms (including macOS, web and mobile). I want to avoid a situation where we deprecate the only solution that works reliably on certain platforms, especially on low-end GPUs such as integrated graphics.

[QbieShay]

Oh. Yeah I agree. The timeline was tentative. I am not proposing to remove them tomorrow. But for sure I'd like to stop maintaining them as the particle refactor is merged.

[KoBeWi]

I think another option is somehow unifying the 4 nodes using a common utility class (like this one for example). Though not sure how technically possible it would be and whether it would affect performance.

[QbieShay]

The big issue with the two is that they're written in different languages (c++ and glsl) and between 2D and 3D they use different types in the process :( I'm out of ideas on that front