Particle System Proposal

[NHodgesVFX]

Describe the project you are working on: 3D Games with a variety of styles. This proposal would be relevant in any project using the particle system

Describe the problem or limitation you are having in your project: Particle editor is hard to use and lacks features.

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

1. The particle system is hard to use

• Naming of forces is unintuitive

• Forces are cluttered into the particle window. it would make more sense to separate them into a "force node." The force node would have options for affection distance, falloff of that distance, whether or not the force is Global (Affects the whole scene), individual force options, and a drop down menu to select the type of force. This would also allow stacking of forces. It would also be cool to have a custom force type which takes a shader or script so you can make your own.

2. lack of features

• No collisions, in modern game engines particles can collide with geometry both on the cpu and gpu(Depth based and SDF based). Also can be used to remove particles on collision.

• No noise, one of the ways to get great looking particles is to introduce a noise or turbulence into the particles that makes them look natural. A PR to do this is here https://github.com/godotengine/godot/pull/22254

• No way for particles to cast light and shadows, it would be nice for the particle system to be able to create lights that move with the motion of the particles and mimic the color of the particles. As far as the light in can just be a normal Omnilight with all of its settings intact that is spawned for every n particles. This is probably less of a concern with the new GIProbe in vulkan but GIProbe lacks hard shadows and not every game that uses particles will use a GIProbe.

• Lack of particles that can spawn other particles on death or other events. This makes creating fireworks and other types of effects that relies on previous particles hard.

• Lack of proper Trails

• Lack of emitting from a skinned mesh

• Particles currently function as an enclosed box, multiple emitters interacting with each other is not supported. It would be nice to have a Global Particle object which holds emitter and force nodes. This way you can add multiple emitters and force nodes and they can all interact together.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

Naming: instead of Tangential Force use Vortex Force

Collisions: CPU can be done in multiple ways, one would be to treat the particles previous and current position as a line and check if it intersects a triangle. On GPU the easiest method is depth based aka screen space particles although this is simple to implement it only works in screen space. This can be acceptable for some effects, its also the fastest performance wise. SDF Particles are high quality and scene wide but harder to implement and slower.

Force Node: Things like attract, noise, damping, directional force, Vortex force would go here

If this enhancement will not be used often, can it be worked around with a few lines of script?: No this requires a change in core.

Is there a reason why this should be core and not an add-on in the asset library?: you could have a particle system as addon but it makes sense to just improve the one in core

Additional Notes: This is for Vulcan Rendering engine as some things here would be hard to implement in GLES2. Although, GLES2 could still take ideas from here.

Suggest your own ideas and changes in the comments :)

[Calinou]

No way for particles to cast light and shadows,

I think particles can already cast shadows if their material is configured for it. You may have to enable Alpha Scissor for transparent textures; I don't know if it'll be possible to cast shadows with alpha-blended textures in Vulkan.

As for lighting, this is usually better achieved via fake corona sprites and/or a single OmniLight. Spawning an OmniLight for every particle would be way too slow. I suppose the particle system could be made to spawn an OmniLight at the particles' averaged position, but configuring this OmniLight in the ParticlesMaterial sounds tedious as we'd have to duplicate all the OmniLight properties there.

Naming: instead of Tangential Force use Vortex Force

Out of curiosity, what's the rationale behind this? Is this naming established in another engine out there?

[NHodgesVFX]

No way for particles to cast light and shadows,

I think particles can already cast shadows if their material is configured for it. You may have to enable Alpha Scissor for transparent textures; I don't know if it'll be possible to cast shadows with alpha-blended textures in Vulkan.

As for lighting, this is usually better achieved via fake corona sprites and/or a single OmniLight. Spawning an OmniLight for every particle would be way too slow. I suppose the particle system could be made to spawn an OmniLight at the particles' averaged position, but configuring this OmniLight in the ParticlesMaterial sounds tedious as we'd have to duplicate all the OmniLight properties there.

Naming: instead of Tangential Force use Vortex Force

Out of curiosity, what's the rationale behind this? Is this naming established in another engine out there?

Whoops might not have explained my self well enough, particles can currently cast shadows. I was referring to the spawned lights also being able to cast shadows.

As far as spawning lights goes you would only spawn it for a percentage of the particles. For example one light for every 50 particles.

As for light settings, yeah copying or maybe we could make a light material that could be used.

For lights here's a link to ue4 and unity.

https://docs.unrealengine.com/en-US/Engine/Niagara/HowTo/ParticleLights/index.html https://docs.unrealengine.com/en-US/Engine/Rendering/ParticleSystems/ParticleLights/index.html

https://docs.unity3d.com/Manual/PartSysLightsModule.html

For force naming "vortex force" Is more intuitive as both a beginner and advanced user would know what motion it applies.

https://docs.cryengine.com/plugins/servlet/mobile?contentId=36869033#content/view/36869033

https://docs.blender.org/manual/en/latest/physics/forces/force_fields/index.html

[girng]

Very concise and well-written proposal.

[2plus2makes5]

If i can, instead of opening a similar issue i add my proposal here, if necessary i'll open the issue though.

Simple and complex particles.

(i edited again lol)

Actually there are the particle node and the particle material and both are really confusing and limited, in my opinion in order to make things simple and clear we should clearly define the roles of each entity.

The particle node should be a simple emitter(even better if renamed particle emitter), think of a gun or cannon, it simply shoots things in a direction without really caring about the bullet, and then there's the particle itself with all the info about its lifetime, movement, look and so on. Instead of making the current particles more complex i would suggest to keep them limited and introducing a new kind of particle, a scene particle, a particle that's literally a scene, it would be heavy obviously, but think about the flexibility and all the mindblowing things it could do, and it would be better to have the choice of a limited but performant particle material or a heavy but flexible scene particle instead of just making the particle material more complex and heavy.

Here some ideas to make the particle node and material better:

1)the particle node/emitter should be simplified, it shoud only have infos about where and when shooting particles, here's the parameters: -emitting true/false -min and max number of particles emitted at the same time -min and max time between an emission and the other, 0 and 0 would mean constant emission -number of emissions, 0 would mean unlimited -minimum and maximum x and y shooting angles, min=(0,0) and max=(0,0) would shoot straight like a gun, min=(-20,-20) and max=(20,20) would act like a shotgun, while min=(0,0) and max=(359,359) would mean shoot all around like an explosion -minimum and maximum emission distance from the emission center

2)the particle material should be simplified too, since the particle node/emitter takes care of the initial direction that info is no more necessary. About its movement, think of a cartesian grid, the particle emitter without rotation shots the particle in the +x direction, we could use curves to determine how it moves along the y and z axis during its lifetime. If you want particles all around the emitter you just make the particle emitter rotate and give the particle a very curved y and z curves. Here's what particle material should have: -min and max lifetime -mesh -color ramp(but maybe it would be better to let the mesh material handle the color?) -min and max acceleration and speed(along the "x axis" trajectory) -min and max initial value, acceleration and speed for rotation and scale(for the look only, they don't affect movement) -y and z curves to determine how the particle moves along the "x axis" trajectory

3)in addition to shader and particle materials give us the ability to use scenes as particles, this way we could have all the collision, light and complex behaviour that we want(we could make particles that create other particles like fireworks, or particles that follow the player, others that have complex movements or why not spawning enemies, bonues etc), at the cost of efficiency, in addition to the limited but more efficient particles we already have.

Sorry for the mess, the many edits, if i should have written this in a new issue and if the idea is stupid.

[lentsius-bark]

I am working on a story driven First person platformer and make massive use of the particle system within my game, I was about to open a similar proposal but instead will add my own two cents here to the improvements which I believe would greatly enhance the quality of the particle system (should be mentioned that I've built and tried Godot4 to see what the current most up to date state of the system looks like and whether my points have been made irrelevant by its latest iteration):

• start/end rotation - being able to set the XYZ rotation of particles, just like you do with objects, including the ability to make it random. This would be really helpful for things such as particles of falling leaves
• • at the moment we only have a 2D angle option which works but remains limiting.
• • having a rotation property would allow for much more varied effects.
• fix randomized lifetime - this is already implemented but if you randomize the lifetime of particles the colour over lifetime remains applied to the original hard set one
• easier setup - I've spent a long time figuring out how to set up the particle so that it:
• • points upwards
• • is scaled by the ProcessMaterial

Sadly I'm not sure what UI/workflow improvement could be done here instead of clearer instructions, these three places are interlinked...:

1. ParticleSystem node
2. Process Material
3. Particle Material

...going back and forth can be puzzling at times. I've been wondering about a way to make this more streamlined but haven't come to a concise solution. Thing is, it works great if you know what you're doing, if you don't... i dare say the current UX problem here is that there's a lot of clicking involved, and if you don't know the specific properties you're stuck with going back and forth, trial and error, between the ProcessMaterial and particle material trying a myriad of combinations.

• easier starting point - somewhat a follow up to the previous point,
• • when creating a new particle system, have it default to having a quad mesh from the get-go, which the user can of course change later on just like now.
• • heck even create a blank ProcessMaterial by default. So that when you add a Particle3D node in the scene it automatically does something.
• noise - apply a noise texture to pseudo randomize the movement of the particles.
• random between two values - this is something I didn't know existed until I recently tried the unity particle system where each value can be set up so that it the system picks from the two specified ones, allowing the user to create a great variety of particle effects without having to write their own shaders.
• emission shape consistency - at the moment if the emission shape is a box the particles are spawned all throughout the shape's volume, however with sphere, it only spawns the particles on the surface points.
• • I'd propose a property in the emission shape options called surface which when ticked only emits the particles from the surface of the emission shape and when not spreads them throughout the volume just like it does with box now.

Please do disregard anything that has already been implemented or fixed or made redundant. The very last master version of Godot crashes when playing particles so I couldn't test it again after my last try about three weeks ago.

in 3D, IMHO, the particle system in its current form is fantastic for basic and great looking effects but when you want to give it an extra layer of polish, you'd probably have to start writing particle shaders.

Thanks!

EDIT: Added a bullet point to easier starting point

[Calinou]

fix randomized lifetime - this is already implemented but if you randomize the lifetime of particles the colour over lifetime remains applied to the original hard set one

See https://github.com/godotengine/godot/issues/43485.

[jcandres]

@NHodgesVFX I believe particle collisions and emission on death are already implemented on Godot 4, in adition to particle trails.

Turbulence or noise would be awesome, I have found very hard to create interesting or nuanced particle behaviour. I have the impression that the current particle physics are best suited for cartoony effects.

There's a few problems I've found while working with particles:

• Particle scale is a float, so you can't control width and height independently. I find this very limiting and arbitrary, specially considering that it's such a basic feature and Godot only applies this restriction to particles. There's just so much you can do simply by scaling each axis. Take for example this demonstration of Disney's principles, pretty much every animation depends on it: https://the12principles.tumblr.com/ I like having a "global scale float/curve" for controlling the overall size, but I can't understand why there is no Vector3 for individual axis manipulation.

• There is no way to set a min-max for movement parameters, so controlling the behaviour involves endlessly going back and forth between different categories and tweaking values until something clicks. A better way would be to group them into different motions, for example:

  • Linear motion
    • Initial Linear velocity
    • Linear acceleration
    • Linear damping
    • Linear velocity range (min, max)
  • Angular motion
    • [...]

• The Flag properties are unintuitive or straight broken. For example, rotate_y suddendly turns the Angle parameter into Angular acceleration (I would expect it to be applied once on emission, as it usually is). Then the align_y works depending on direction AND speed, and disable_z property overrides the rotation behaviour... if you include a bit of extra complexity into the mix (say, billboarded particles) it's very hard to predict what the outcome will be, and harder to achieve the result you want.

• Emission shape consistency. I support @lentsius-bark proposal.

• Minor thing: by default Gravity is on, Direction points to +x, and there's no velocity. I find this this is a bit arbitrary and in most cases you place the particles on a solid ground or object, and they start clipping out of sight right away. I think friendlier defaults would be zero gravity, direction pointing up, and optionally some initial speed to display movement.

[Calinou]

Particle scale is a float, so you can't control width and height independently. I find this very limiting and arbitrary, specially considering that it's such a basic feature and Godot only applies this restriction to particles. There's just so much you can do simply by scaling each axis. Take for example this demonstration of Disney's principles, pretty much every animation depends on it: https://the12principles.tumblr.com

It's probably an oversight, or nobody needed it until now. (I haven't seen anyone request this before you.)

Feel free to open a pull request to expose individual scales, but remember that this will make tweaking particle scale significantly more complex for people who don't need per-axis scale (especially since you need one curve per axis to support the 12 principles). A lot of people are screaming at the number of properties in ParticlesMaterial already :slightly_smiling_face:

---

Edit (May 2022): Particle turbulence/noise is being worked on in https://github.com/godotengine/godot/pull/55387.

[QbieShay]

Turbulence is merged \o/