Add a menu option to convert CPUParticles back to GPUParticles

[Calinou]

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

Currently, there is a menu option to convert GPUParticles to CPUParticles, but not the other way around (CPUParticles to GPUParticles).

There are some use cases for converting CPUParticles to GPUParticles:

• Benefiting from performance improvements when using large amounts of particles, yet you've designed your particle system around CPUParticles at first because you thought a small amount of particles would be fine initially.
• Using particle shaders for custom simulation, which are only supported in GPUParticles. However, you may not want to set up everything from scratch again.
• Going back to GPUParticles after converting some GPUParticles to CPUParticles, especially if you've closed the project since doing so. Non-destructive workflows are better 🙂

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

Similar to what GPUParticles already provides, when a CPUParticles node is selected, add a menu option to convert the node to GPUParticles.

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

The menu option could be disabled and have a tooltip when using a rendering backend that doesn't support GPUParticles (such as GLES2). However, since the resulting GPUParticles node will emit a node configuration warning as soon as it's created, we may not have to do this.

I can work on this feature if it's desired.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It can likely be implemented in an add-on, but I believe being able to convert particles nodes in a two-way manner will improve editor usability out of the box.

Is there a reason why this should be core and not an add-on in the asset library?

See above.

[Xrayez]

I realize that there are certain design decisions that lead to separation of the particle class into CPU/GPU, but I wonder if such design is really justified when we talk about Godot 4.x. Couldn't we merge both classes into one, so that there's no need to implement convertors for those classes in the first place?

Regardless of the above, this proposal makes sense to me, especially when it complements existing GPU → CPU conversion tool.

[Calinou]

I realize that there are certain design decisions that lead to separation of the particle class into CPU/GPU, but I wonder if such design is really justified when we talk about Godot 4.x. Couldn't we merge both classes into one, so that there's no need to implement convertors for those classes in the first place?

By design, CPUParticles has less features than GPUParticles and does not support many features like custom shaders. I don't really see a way to merge both in a way that doesn't limit GPUParticles functionality. People need to be able to know whether the features they use will work correctly if they switch to a low-end renderer later on.

[Xrayez]

I wonder whether Godot plans to remain CPUParticles in the future with Vulkan/GLES3, unless there are reasons for keeping CPUParticles other than supporting low-end hardware. According to the recent news article "About Godot 4, Vulkan, GLES3 and GLES2", GLES2 will not be implemented officially. But I guess it depends on exact differences between Vulkan/GLES3, which may be equivalent to GLES3/GLES2.

In any case, something tells me that both backends will use GPU acceleration for particles, not CPU. Maybe CPUParticles/GPUParticles will be renamed to LowEndParticles and HighEndParticles... 😃

If you ask me, I don't really like this kind of low/high-end separation, it should be just an implementation detail that you can switch via project settings or other means. Note that I'm speaking as a user here, not necessarily developer.

[Calinou]

I wonder whether Godot plans to remain CPUParticles in the future with Vulkan/GLES3, unless there are reasons for keeping CPUParticles other than supporting low-end hardware.

CPUParticles will be able to provide accurate physics collisions in the future (based on your project's existing physics bodies and PhysicsServer). In contrast, GPUParticles uses approximate physics collisions with dedicated nodes for performance reasons, especially since it may need to manage a much greater amount of particles.

Therefore, there are still reasons to use CPUParticles in specific cases even with the Vulkan renderer 🙂

According to the recent news article "About Godot 4, Vulkan, GLES3 and GLES2", GLES2 will not be implemented officially. But I guess it depends on exact differences between Vulkan/GLES3, which may be equivalent to GLES3/GLES2.

The plan is to have GLES3 as a low-end renderer, which means GPUParticles are unlikely to be supported in GLES3 in the future. CPUParticles will still work though.

In any case, something tells me that both backends will use GPU acceleration for particles, not CPU.

This cannot be done for the physics reason I mentioned above.

[Xrayez]

Ok, this clears it up. Taking this all into account, this proposal must be implemented, no doubt.

The reason why I bring those questions up is because there's no simple way to develop a project which takes into account both low-end and high-end hardware, since we have two separate classes that make it difficult to manage at run-time (not impossible, but still PITA). Having editor conversion tools only make it possible to replace one implementation for the other.

Similar problem is present with shader programming described in #944, which might be the main reason (or even the root cause) why we have both CPUParticles and GPUParticles in the first place, excluding the future-reserved implementation for particles physics collision system. Of course, this is a separate topic to discuss.

[Calinou]

The reason why I bring those questions up is because there's no simple way to develop a project which takes into account both low-end and high-end hardware, since we have two separate classes that make it difficult to manage at run-time. Having editor conversion tools only make it possible to replace one implementation for the other.

Most particle effect simulations aren't demanding enough to warrant using the GPU over the CPU with a significant performance difference. It's more about having additional control thanks to particle shaders. Still, if you really want to, you can maintain both a GPUParticles node and CPUParticles node, and hide the CPUParticles node depending on whether the high-end renderer is used – GPUParticles won't be visible when using the low-end renderer.

[snoopdouglas]

I've just converted my GLES2 game to GLES3, so this proposal is timely for me - it would've been very useful!

The only thing I can see being a (vague) problem is the calculation of the visibility box/rectangle, which CPUParticles doesn't have. Should the user be prompted to run a visibility calculation after the conversion?

[Calinou]

Should the user be prompted to run a visibility calculation after the conversion?

Good point – the visibility rect/AABB generation could be done automatically after converting the node. You'll want to generate a visibility rect/AABB most of the time, so we might as well do it automatically.

[Calinou]

Regarding issues like godotengine/godot#54052, it may be a better idea to move the particle type conversion to a function that can be called at run-time. This will allow adding a project setting to automatically perform particle conversion when running the project, but only on macOS by default (to sidestep the issue outlined in godotengine/godot#54052).

This should be done before adding CPUParticles → GPUParticles conversion, as both should be done in the same way (run-time function or editor-only tool).