Implement particle seek request and seed options.

[QbieShay]

2024-05-18.18-45-36.mp4

Works ONLY with GPUParticles3D for now.

Test project:
particles-skim-test.zip

This PR exposes the required API to then construct better particle timing tools on top of existing particles.
I implemented the seed control in this PR because otherwise any restart() would change the seed, which makes seeking impossible.

TODO

• Implement request_process_time for CPUParticles
• Implement rnadom seed for GPUParticles2D
• Implement random seed for CPUParticles2D/3D

Closes godotengine/godot-proposals#6226
Simpler approach than godotengine/godot-proposals#7085 for editor purposes

[Calinou]

Tested locally, it works as expected.

One strange thing I noticed though is that when you set particle seed mode to Random then restart particle emission, the seed is changed to a random value which you can see after changing it back to Custom. This makes sense, but this seed is always capped to 1 million due to the inspector hint:

See the second suggestion below which aims to address this.

PS: Are there any plans to expose a high-level GPUParticles3D property that allows for easy seeking, without needing a custom script? I assume this would need to force speed scale to be 0 though (like AnimationPlayer's Manual process mode).

[Calinou]

I'd document this 30 FPS fallback for particles with fixed FPS set to 0 in the class reference in the fixed_fps description, as well as RenderingServer.particles_set_request_process_time().

Particle trails use the same 30 FPS fallback when Fixed FPS is set to 0.

[QbieShay]

@Calinou yeah definitely I would like to get to something that has a slider to seek. I don't know yet what should be the design because I have a couple of ideas I want to explore. Those being:

• maybe a vfx node, that encapsulates things for all particles.
• maybe a particles track that does special things (seek) in editor
• maybe a mix of the two?

There's also the issue that CPUParticles are not managed by the rendering server so i question whether the rendering server API is the correct way to go, or if i should keep that internal and only expose it via the node with the same interface for cpu and gpuparticles.

For now I'm stuck there but I haven't really dedicated more time to this yet.

[QbieShay]

Oh and thank you for testing even in the incomplete state!!

[QbieShay]

One strange thing I noticed though is that when you set particle seed mode to Random then restart particle emission, the seed is changed to a random value which you can see after changing it back to Custom. This makes sense, but this seed is always capped to 1 million due to the inspector hint:

I noticed that as well, and I am not sure why it resets even if the seed is set manually. For what i thought i wrote in the code, it should be possible to override the seed, but it doesn't seem to be working.

[QbieShay]

add pre process on clear

[Calinou]

I tested the latest revision of this PR. I've gotten GPUParticles3D seeking to work successfully (it's quite simple to script, only 2 lines of code):

$GPUParticles3D.restart()
$GPUParticles3D.request_particles_process(value)

Testing project: test_pr_92089.zip

particle_seeking.mp4

Some remarks:

• What's the difference between request_particles_process() and request_process_time()? For GPUParticles3D seeking, it seems I can call either of them (or both) and get the same result visually.

• I noticed that when CPUParticles3D have their Speed Scale set to 0.0, seeking will not make any particles emit (unlike GPUParticles3D where particles are visible as expected).

• I get some errors when opening the editor or running a project:

ERROR: Class GPUParticles3D already has a method set_seed_mode.
   at: bind_methodfi (./core/object/class_db.cpp:1793)
ERROR: Class GPUParticles3D already has a method set_seed.
   at: bind_methodfi (./core/object/class_db.cpp:1793)

• This PR makes CPUParticles3D simulate much faster than intended (compared to master or GPUParticles3D in this PR). The speed depends on the rendered FPS (not particle fixed FPS) – at 10 FPS, speed is mostly equivalent to GPUParticles3D, but still a bit faster.

[QbieShay]

Thank you @Calinou !

What's the difference between request_particles_process() and request_process_time()? For GPUParticles3D seeking, it seems I can call either of them (or both) and get the same result visually.

Most likely copy-paste error >< i renamed things but I didn't change the little notepad i use to port codeblocks

I noticed that when CPUParticles3D have their Speed Scale set to 0.0, seeking will not make any particles emit (unlike GPUParticles3D where particles are visible as expected).

I had to change something to make it work for gpuparticles, but i didnt for cpuparticles. I need to fix that too, thanks!

I get some errors when opening the editor or running a project:

Not sure what that is, will investigate.

This PR makes CPUParticles3D simulate much faster than intended (compared to master or GPUParticles3D in this PR). The speed depends on the rendered FPS (not particle fixed FPS) – at 10 FPS, speed is mostly equivalent to GPUParticles3D, but still a bit faster.

Likewise, will investigate.

[QbieShay]

Update:

Removed get rid in case we want to manage separate bursts as under-the-hod separate renderingserver particles.

Exposed process request on all nodes

Documented relevant nodes.

Many thanks to @Calinou @AThousandShips and Tuppy

[AThousandShips]

LGTM

[paddy-exe]

Code looks good to me. Have only tested with Calinou's test project and works fine for me as well. Amazing work on this Qbie!

[akien-mga]

Thanks!