Particle velocity/direction enhancements

[QbieShay]

Describe the project you are working on

Various VFX! I am a VFX artist! Professionally! WHEEEE

Describe the problem or limitation you are having in your project

The way velocity is treated in Godot does not allow me to reliably realize my creative vision with VFX.
It lacks fine control both on the magnitude of it and the direction.

This proposal proposes 2 enchancements:

1. Velocity over life curve
2. Velocity direction options

NOTE: Acceleration produces by definition an "ease out" motion. There's no way to have ease-in curve or linear motion when using acceleration. That's why it should be decoupled from direction.

Attractors don't do it either because their usecase is basically interacting with the world. They use a very physical approach. This is good for more realistic particles and for interacting with the game world, but it's not what I'm disucssing in this proposal. Furthermore, attractors are not local to a single particle system, so I can't have two nearby particle systems not be affected by each other's attractors.

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

Velocity over life

Expose a curve for velocity over life. If the curve is exposed, all accelerations will stop working: I don't see a way to make them meaningfully work together.
This exposes an underlying issue in particles: the acceleration right now does not only control acceleration. It controls as well direction of the particles. There's currently no way to have particles orienting in interesting ways without using acceleration (radial, tangent, etc.). An outlier there is turbulence. Together with @RPicster we worked on making turbulence act mostly on the direction of the particle rather than any other property (it slows down particles when they make a sharp turn, which we figured out with testing, looks way better and more natural)

Velocity directions

Introduce a new concept for velocity direction and ways to control it. This can be done in various steps, a good step by step is the following:

1. Velocity from point: all particles consistently orient away from the point
2. Cylinder orbital: all particles orbit around a cylinder
3. Sphere orbital: all particles orbit on the surface of a sphere

Note for Cylinder and Sphere that the surface that they move on should be defined by the particle position when the cylinder/sphere orbital affects it, so there shouldn't be any explicit radius property. The properties for the sphere should be something to control the direction in a meaningful way and the properties for the cylinder should just be the axis and clockwise/counterclockwise motion property.

Also please don't tell me to go use tangent + radial to make orbiting particles. It's super fiddly and still it doesn't achieve the result i want.

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

Velocity over life

Expose a single curve that takes the velocity generated at start() and multiplies it by the curve.

Velocity directions

Add a "Direction constraints" category, with the following options:

1. None
2. From point
3. Turbulence
4. Cylindrical
5. Spherical

When this is enabled, they would all expose a constrain_over_life property, that is a curve from 0 to 1, to define how to align velocity in the same way that turbulence does.

From point

• position(vec3)(default 0,0,0): the position that the particles should face away/to
• away(bool)(default true): face towards or away from the point?
• local_space(bool)(default true): is this position to be interpreted world space or local space
  

Turbulence

• We already have it, no need to change it, just to group it under this category -

Cylindrical

• axis(vec3)(default 0,1,0): the axis of the cylinder
• clockwise(bool)(default true): clockwise/counterclockwise motion. not entirely necessary because it should be enough to flip the axis, but it's nicer to work with.
  

Spherical

I don't think there's any necessary property. I am not sure this is even needed. It's a cylinder but with no axis, so each particle picks an axis and goes.

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

Yes it can. But it means losing the particle process material and using a shader, with all the documented hassles of this process.
It also means losing compatibility with CPUParticles, which is something that people never want in a professional environment.

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

I can script this myself using visual shaders/shaders but i can't script cpuparticles. I would lose compat with CPUParticles. This is a long running issues when customizing particles, and the reason why particle shaders are not taking off, in my opinion. People care about

[Calinou]

Furthermore, attractors are not local to a single particle system, so I can't have two nearby particle systems not be affected by each other's attractors.

This is possible using cull masks on the particle attractor node, though the number of cull masks you can use is limited to 20. Therefore, you can only have 20 different particle systems that can't interact with each other's particles. This is probably enough, given it's unlikely you'll have 20 different particle systems that are close enough to each other for their particles to end up in another particle system's attractor.

That said, cull mask is currently not working for attractors and attractors aren't implemented in 2D yet.

[QbieShay]

There's more than one reason why attractors don't suit me. I have more than 20 total VFX in my project and at that point I'd have to play whack a mole by grouping effects in groups that are unlikely to interact with each other. It's not good UX, it's not foolproof and it does not serve my usecase since attractors are still forces and have that ease issue i mentioned before.

[QbieShay]

Ehh sorry i wrote a super dry message while I was hungry. I appreciate that you're trying to help me find a good solution to my problem but I got a bit frustrated because I thought I already detailed in the post why attractors are not working out for my usecase. What I do like about attractors is that they can be stacked on top of each other, which is something that my proposal for directionality does not cover. I had considered proposing a stack but at that point we're just reimplementing Niagara.

[hsandt]

Exactly, I've been trying to make particles with precise motion at specific speed, like smoke rising into the air in an S-shape, but we can only tune acceleration and gravity precisely, which are both acceleration-based and pure numbers, not vectors. Btw if we implement this, we could also add acceleration / acceleration curve over time as vectors to complement (it's hard to edit a curve of Vector2 but I suppose splitting XYZ components will do). In addition, negative acceleration values in the curve don't seem to be taken into account.

I've been checking the Particles demo, but it uses tricks to change direction every time:

• the infinite symbol uses a Path2D on which the particle is moving, to demonstrate trail. I can do that too for my S but then I'll lose the advantage of integrated particle parameters such as move randomness
• the "water spring" particle actually uses a sub-emitter: once the main particle falls and ends, a second one takes over and goes up. It would be cumbersome with my S to chain 3/4 sub-emitters for every turn

So to complete this, once implemented it may be nice to add examples of precise velocity-controlled particles to the samples.

[QbieShay]

Setting milestone 4.2 as I'm hoping to get some partial implementation of this in the engine by 4.2

[QbieShay]

Closed by godotengine/godot#79527