Add ability to set GPUParticles2D's emitter velocity

[follyfoxe]

Cue dramatic lighting.

Let's say you are working with particles in godot. You use inherit_property_ratio in the process_material. Using a feature as intended so we should be all good, right? Pretty much.
Until...
You decide to teleport this particle node.

Oh no! The horror.
Particles flying all over the place. This does not look polished or professional at all! This must be fixed post-haste.

You know this would probably be fixed by just spawning a new scene instance every time you need it. But you don't want to spawn a scene every time you want to use this effect. That wouldn't be very efficient.

So you do your research. You look at documentation and even godot's source code. (Thank god the source code is readily available for when things like this happen)

Turns out, there's a little function called RenderingServer.particles_set_emitter_velocity
This is just what you need, and it takes in a RID (Luckily, you know what this is thanks to the ever so reliable godot documentation)

However... It isn't as simple as that. Looking at gpu_particles_2d.h you realize... It does not expose it's RID. So this is all essentially useless.

You look at gpu_particles_2d.cpp, it calls that function.
So you come up with this workaround:

func reset_particle_emitter_velocity(particles: GPUParticles2D) -> void:
	particles.notification(NOTIFICATION_INTERNAL_PHYSICS_PROCESS)
	particles.notification(NOTIFICATION_INTERNAL_PHYSICS_PROCESS)

It isn't pretty... but it gets the job done.
It works due to this piece of code in gpu_particles_2d.cpp

case NOTIFICATION_INTERNAL_PHYSICS_PROCESS: {
	// Update velocity in physics process, so that velocity calculations remain correct
	// if the physics tick rate is lower than the rendered framerate (especially without physics interpolation).
	const Vector3 velocity = Vector3((get_global_position() - previous_position).x, (get_global_position() - previous_position).y, 0.0) /
			get_physics_process_delta_time();

	if (velocity != previous_velocity) {
		RS::get_singleton()->particles_set_emitter_velocity(particles, velocity);
		previous_velocity = velocity;
	}
	previous_position = get_global_position();
} break;

...

So what i'm trying to say is.
It would be nice if GPUParticles2D exposed it's RID or even better; Have a property that allows reading and writing to this hidden property.

[Calinou]

cc @QbieShay

[QbieShay]

Thank you for the ping @Calinou ! I don't plan to expose get RID because I have plans to have particle nodes spawn other particles for multiple bursts (not yet decided, but i actually had exposed RID in a PR and ultimately took it back).

However we can talk about ways to teleport a particle system with inherit velocity. Do you mind explaining better your usecase @follyfoxe ? what do you need this for?

[follyfoxe]

There's a mechanic in my game that allows the player to grab objects with the mouse. When the player does so, a particle system is set to emit at the object's position. This particle system has inherit velocity ratio set to a non-zero value becuase that way, particles inherit a bit of momentum of the held object (and it looks nice). After the player drops the object, the particles' emitting property is set to false and stop moving with the object.

The problem arises when the player goes and grabs another object quickly after dropping one. The particle system which was at the old object's position gets teleported to the new one, causing the particles to go flying due to the sudden change in position (and therefore calculating a huge emitter velocity)
Note that I do call Node2D.reset_physics_interpolation() and GPUParticles2D.restart(), so it is not an issue of either.

While this could be fixed by spawning a new particle system every single time the player decides to grab an object, it is less than ideal, since it is a really common and important action that gets triggered very often.

Currently we're using the workaround I mentioned above.

[QbieShay]

If reset physics doesn't cause inherited velocity to stop momentarily, I think it could be added. Would that work?

[follyfoxe]

I believe that would do the job. It would make sense for reset_physics_interpolation() to reset the internal velocity as it would work the same as it's regular use, you first move the transform, then reset the interpolation. (However this also means that reset_physics_interpolation would have a valid use for projects which do not use physics interpolation, which would be a bit weird)

Either that or GPUParticles2D.restart(), because if you want to keep the state (keeping the velocity, and previous particles) you would probably set the emitting property to true. It would make sense for the restart method (which kills all existing particles) to also reset the emitter's velocity.