New particle system request for ideas!

[reduz]

Describe the project you are working on:

I will be rewriting the particle system for Godot 4.0.

Describe the problem or limitation you are having in your project:

Users often complain that the particle system in 3.x is limited, so I would like to know what kind of new features they expect from a new one. The one in Godot 4.0 will use compute shaders, so this will probably allow a good amount of extra features.

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

This issue is here to collect feedback and ideas for implementing a new one. I know there are many issues and proposals open for this topic, but I would like to have everything in one place, so please submit (or link them) here.

NOTE: IDEAS AND SUGGESTIONS UNRELATED TO THIS TOPIC WILL BE DELETED

[Zireael07]

I remember a recent proposal for making trails easier to make (something about spawning based on distance instead of time IIRC)? That one has a ton of applications (smoke/dust/snow trails, light trails, backfire...)

EDIT: Also, particles reacting to physics (so that they don't clip through ground/building/car/what have you)

[BernhardWerner]

Compute shaders will be very welcome! Apart from that...

1. Particle attractors and
2. particles that can interact with the physics (especially collision)
   are the things I want the most.

[Metalmastery]

A couple things come to mind:

1. Multipass for 2D

2. Some way of treating the whole particle system as a single texture. This will help with metaballs-like things and post-effects without viewports

2.1. Or accessing vertices as a mesh?

3. Passing an array of data to particle system. Maybe I’m dumb but I made it via writing coordinates of spawn points into a texture and then using it to access dynamic amount of spawn points. It’s not a very common case but I wanted to have a single interaction system (attractors, etc) for particles that are spawned in different locations. Here is my small experiment with several dynamic spawn points in one particle system)

4. Shaders compilation time should be there, right? (in 3D even simple particles freeze the game on first run)

5. Maybe some sort of path for particles in 2D? Probably attractors will do the work.

6. Can we use particles as a glow light (like HDR glow) without blowing the color up to the point where the particle itself is completely opaque?

[NHodgesVFX]

#516

Noise/turbulence for particle systems

Better particle trails

Particles that can spawn other particles on some sort of event.

Collisions with scene, including animated geometry.

Friendly naming for forces

More forces

Global, so its possible to have multiple emitters and forces interact togather.

Spawning lights for a percentage of the particles.

Node based would be cool and future proof.

If node based the ability to write you own nodes easily.

Even if not node based the ability to write your own forces.

[admiralzeech]

Thinking about the GDC talk that described how they implemented rollback netcode into Mortal Kombat:

I think one of the things they said was vital for them was the ability to arbitrarily adjust the time of the particle effect in a repeatable way.

ie. If I let a particle effect run for 10s, I can set the current time of the effect to t=5s, and the state will become identical to how it was 5s ago.

If I record the internal time elapsed of a particle effect, delete it, and then create a new object with the same parameters and set the recorded time elapsed as the initial time, it will look identical to the deleted object.

etc.

[reduz]

@Qws This is not the place to post about it, feel free to open another proposal in this repository for that.

[reduz]

@admiralzeech that sounds like you would probably need a custom particle system shader written for this that is entirely deterministic, and that you would use only for some things (blood splatter and that kind of stuff most likely, for background decorations it makes no sense). I'm unsure this is a good idea to have to regular particle systems as it would limit them too much.

[WolfgangSenff]

1. Generally speaking, I think if it were easier/more intuitive for how to use animated particles, people would use them a lot more. With the current system, adding a CanvasItemMaterial to your Material and then clicking Particles Animation on then giving you H and V frames/looping options is extremely hidden, and having those values apply to the texture that's in Drawing...well, it's a bit rough around the edges.

If possible/sensible, I'd like to see those values moved into the Animation node in the editor. One other possibility is to just have a different node: AnimatedParticles2D/3D, but I find that a little cumbersome as well, given there are already two slightly-confusing particles nodes per perspective (CPU and non-CPU).

2. For Emission Shapes -> Points/Directed Points, it would be nice to be able to draw polygons/lines/whatevers directly in the editor when setting the values for those, though I'm not sure how easy that would be to pull off.

3. As others have mentioned, particle attractors are very useful.

4. A simple one: Explosiveness feels incorrectly named. I'd use something like Burst or even Pause Rate or something. Maybe I don't have a good idea for the name actually, hm.

[nonunknown]

Animated Sprite/Model Points of emission

Particles 2d and 3d have a option called points wich can emit based on the shape of the 2d or 3d node, this feature is awesome, but what if we want to emit on these points based on a animated 3d model/sprite , I think that implementing this shouldnt be hard, just hold a reference to the points and them move them accordingly to the model/sprite animation.

Example in 2d scenario:
the sprite emits 360 degrees luminous points based on it shape (kinda of a explosion)

Example in 3d scenario:
A character bleeding emits blood particles from random positions in the body's surface (animated model of course)

Particle Collisions

Nothing much to say, this is a long requested feature :D

[imjp94]

Particle alignment, for example, aligning particle to the normal of mesh.
It is pretty basic yet impossible with the current system

[reduz]

@WolfgangSenff I am not sure there is much that can be done about animated particles. Moving animation to the particle system itself would be extremely limiting in possibilities, as you would no longer be able to have a custom shader draw them, or allow us to reuse the same particle processing code for both 2D and 3D.

What we can probably do about it (if we are not already) is just warn you that your animation will not be visible until you add a material that can process it.

[Talops]

Rather than using arbitrary randomness (and spread) values for most particle properties, would it be possible to use random ranges instead? This allows for more precise control over particle behaviour and would also reduce property bloat in the inspector.
For instance, the most important one, direction, has 3 properties: Direction, spread and flatness. Using ranges in the Direction property would remove the need for the two others.

[PKGaspi]

It's been in the docs for a while that Particle2D could use SpriteFrames for animated particles in a future.

[redhoot-dev]

As others have mentioned, a node based workflow with more low level building blocks. Have a look at what Blenders node based particle system currently in development is discussing.
If not, then SideFXs Houdini is the (vfx) industry standard for node based effects work.

Node based

• Allow for event driven systems
• Spawning of other events (based on attribute like age, collision, distance etc or any arbitrary attribute )
• Allow for a more plug and play approach to systems creation and granular control.
• Can allow for multiple solvers at some point. (nodes are future proof)
• Node grouping to create new high level nodes that can be easily shared.

Specific features

• More control over distribution (esp for height maps)
• More noise types (curl esp)

[neikeq]

Particle attractors. Something similar to Unity's external forces module would be great:

https://youtu.be/EzNXZIpXJD4?t=527
https://docs.unity3d.com/Manual/PartSysExtForceModule.html
https://docs.unity3d.com/Manual/class-ParticleSystemForceField.html

[reduz]

@Kryper Please read the OP, off-topic proposals will be deleted. Open a separate one.

[reduz]

@redhoot-dev I would really like to see a node based proposal that is more in line with how Godot works.

[Jummit]

Is this proposal discussing both 3D and 2D particles?

[reduz]

@Jummit yes

[eon-s]

Getting the old attractors back would be cool.

Solid particles, like https://www.babylonjs-playground.com/#6UZDJ9#0
A simple dedicated editor, for example http://www.particle2dx.com/

If things like a dedicated editor, or node based editor can be made with addons, then a good API for it could be done instead and have all emitter and particles settings on Resources (emission rate, etc.) leaving emitter nodes just for scene dependant details (also allow full central editor panel addons).

[alfredbaudisch]

• Particle collisions
• Attractors
• Node based editing
• Force fields (both math and physically based ones)
• And on the other spectrum, contrary to node editing, Particle Designer has a nice way of combining particle presets and designing them at the same time. Maybe getting some of those ideas and UX?
• Particle Candy has a massive amount of features, maybe grab some ideas from them as well? Video showing the features and presets.

[golddotasksquestions]

The currently not existing feature I miss the most from the current particle system is build in collision detection. It would be great if it would use the existing collision layers system. Attractors would be really great as well.

My biggest gripe with the currently existing Particle system is that I can't emit new particles from the same node whenever I want, without killing all existing particles, or spawning a new particle node.
In 99% of all my usecases for particles I want to emit them at a particular event. However these events never care about the lifetime of the particle. If I click twice I would want the particle to emit twice. That's currently not possible.
The only workaround is to use either $Particle2D.restart(), but that removes the existing particle that has not finished it's lifetime, or save the Particle node as scene that queue_free() after the lifetime ended, and spawn a new instance of that scene every time. But that pretty much defeats the purpose of unloading the task of spawning the particles to the GPU.

I guess what I am asking for is a emit() method, in addition to the emitting property.

I would also really appreciate if the all the animation setting could be moved from the CanvasItemMaterial to the Particle node or the ParticleMaterial . At least 90% of my particles use animations. It took me forever to figure out how to use it. It one of the most counter intuitive UX Godot has.

[alexfreyre]

I would love that the new particle system allows:

1. Emitter is any mesh (for example, a human figure).
2. Emitter can emit from vertices, edges, faces and volume.
3. Particle collision.
   • with objects from the scene
   • between the particles of the same system
   • between different systems
4. Events triggered at the time and position of the collision.
5. Multilayer node containing different particle systems.
6. Force fields, attractors and detractors.
7. Provide different types of emitters:
   • particles (emit -> objects)
   • hair (position / grow -> objects / splines)
   • water (maybe metaballs)
8. Possibility of painting influence maps for any parameter (one could interactively evaluate the behavior, emission zone, quantity, life, etc.)

thanks for listening!

[huttyblue]

Some of this has already been said but here are my issues with the 3.2 particle system.

• Random Lifetimes is technically supported but values driven by curves will cut off when a randomly selected short lifetime runs out. Ideally the curve should match the lifetime of each particle. This can be seen by setting a curve to scale so particles scale-out. When random lifetime is selected many particles will pop out of existence without finishing their scale-out.

• Spawning particles between frames When you make an emitter on a moving object it only emits particles at the node's current position given the current frame. This can lead to gaps in the trail of particles even when you set the particle emission count to something absurd like 1024. This could be fixed by spawning particles based on how long it has been since the previous frame and how much the particle system has moved, aiming to evenly fill in the gaps.

• More curves on more values Things like Velocity Randomness are currently just an float, it would be nice to be able to select what values are randomly selected (with a curve or such). Unity's particle system allows you to define overlapping curves for most values, the particle system will then pick a value between the overlapping curves at random. Something along that level of control would be ideal.

• Child particle effects Allow particles to emit another particle effect from their location. Ideally so you can more easily sync up multiple effects (like adding a trail to emitted particles), and having secondary effects kick off when a particle dies.

• Add a make-unique-recursive function When duplicating a particle effect that uses a gradient I have to make the process-material unique, then the gradient-texture, then the gradient. Its not a big deal but its annoying, especially when you forget and mess up the effect you copied from. Being able to make all parts of the particle system unique at once would be nice.

• General UI improvements The current particle system UI is kinda annoying. If its got to stay in the inspector add collapsing to the property categories and give them little icons.
  [edit] Its come to my attention that collapsing properties is a thing and I had disabled it in the editor settings. My issue with the current implementation it defaults to everything collapsed, If it could default to everything expanded that would be nice.

• Better defaults Especially for 3D, 90% of the time I want billboard quads with a fuzzy circle that inherits color from the particle effect and uses additive blending. Having to setup a pass for that with a material every time is a bit tedious. Having a selection of defaults for common effect patterns would be a time saver for me, and probably helpful for new users.

• Bugs May not be relevant due to the re-write, but particles 2D has a bug where sometimes all the particles on the screen will reset their lifetime. If they were scaling down they all snap to big again I'm not sure of the cause, it happens in one of my projects that has a-lot of one-shot 2d effects going off.

That about sums up my current gripes.

[orestiskon]

Disclaimer: I've only tried the particles a little bit so I might be unaware of things they can already do. But part of the reason I haven't used them more is because I couldn't find what I'd consider to be necessary particle tools. There is a preset shader for simple emissions, and for anything more then the user basically has to write their own particle system in a particle shader.

I couldn't find high level tools to add external forces, to do collisions etc.

I don't really mind if the underlying system is a particle shader, but I would love to have more intuitive control as a user.

Like many have already mentioned, a modular, Node-based system would allow this. It allows flexibility, experimentation, scene interaction and an overview of available tools.
Being able to add force fields, create custom forces and create collisions is functionality should be available right away.

Searching for how to do collisions I found this great presentation from Paweł Mogiła:
https://www.youtube.com/watch?v=8Q77OlffvfQ
Even though the presentation and the example are excellent material, it really seems the user has to do the equivalent of a bachelor thesis to achieve a basic collision. It should really become as simple as connecting a couple of nodes.

Hope my naive knowledge on the previous system still somewhat useful as a feedback, at least in the sense that it would be good to have a more intuitive, modular system to begin with.

[jesperkondrup]

Random Lifetime as @huttyblue mentioned is something I really miss in the current particle system.

Random within a color list In Unitys particle system you can make a list of specific colors where it randomizes between them. So if you set 4 colors in the list (could be Red, Green, Blue, Pink) then it only spits out one of these 4 colors. I often miss this feature. In order to get around it in Godot I can make 4 different particle systems but it would of course be better to only have one.

[oeleo1]

Did anyone mention that the current particle system is quite awesome? If not, I will. But if there is going to be a rewrite, my wish list is a mix of improvements on the current system with some new features and I'll keep it short:

1. Single CPU/GPU particles API. The current differences are a bit annoying. CPU particles define properties that can be configured with get/set_ while with GPU the same are accessed with the generic get/set_param(). This would also allow for seamless back and forth CPU/GPU conversion which is currently one way.

2. Run-time computed emission shapes. Currently if one uses emission shapes they have to be pre-computed in the editor. It would be nice to expose that array computation so that the points array can be fed to the system at runtime.

3. Fix the preprocess "freeze" if possible. The current preprocess implementation loops internally the whole particle system until it reaches the desired start time which visibly freezes the emission (and the game) for the time of the computation when both preprocess and lifetime are high. That's true for CPU particles (unsure about GPU).

4. Sub-emitters. Allow for each particle to be a new particle emitter on it's own.

I will invariably enjoy any new advanced features like particle collisions or gravity fields but those would be a bonus to an already efficient system which does the job.

Thanks.

[AssjackGames]

One thing I wanted to do but haven't found a way to in the current particle system is reverse time. One can create a time dilation effect by manipulating the speed parameter but it would be cool to have a reverse-time effect, or a negative speed value

[Vaasref]

Instead of being limited to either global or local coords, it would be handy to be able to set the referential to an any other Spatial or Node2D.

[Norrox]

#516

Noise/turbulence for particle systems

Better particle trails

Particles that can spawn other particles on some sort of event.

Collisions with scene, including animated geometry.

Friendly naming for forces

More forces

Global, so it's possible to have multiple emitters and forces interact together.

Spawning lights for a percentage of the particles.

Node based would be cool and future proof.

If node based the ability to write your own nodes easily.

Even if not node based the ability to write your own forces.

example of noise and trail :)

Edit:
Have one or more idea's i put down below when i know what they are 😊

1. You have a something like an emitting sphere or cube, and there are particles in it, when you move that shape the particles outside get destroyed and at the opposing side new particles are being randomly created at the edge of the shape just as they enter.
   Don't know if this is easily done today but really useful for things moving around the player like starfields, dust, snow, rain, etc.

Edit3:
Nice if individual particles can emitt light!

Edit2:
Unitys new vfx node system looks really good, whould be nice if we can borrow some ideas from them?
I know designing a whole new node system might not be ideal since we have an already powerful one (visual shader one).

Here are a link to unitys.
https://docs.unity3d.com/Packages/com.unity.visualeffectgraph@7.4/manual/GraphLogicAndPhilosophy.html

And some screenshots.

[nezvers]

I didn't see mentioning the option for nested particles. Imagine explosion and debris splitting into a few smaller particles.
Basically particle can be also emitter and give it it's own particle to spawn. It would introduce a list of options - emit on death, emit with interval, give delay. Adobe After Effects has such a system.

Actually it would be super awesome if particles could be bakeable and/ or support volumetric data like OpenVDB from software like Embergen or Godot's own baked particles.

[chucklepie]

I'm new to particles, just setting up my system and finding things I'd like to make life easier:

1. It seems you can only have either 1 colour or a gradient for your particles (not textures used as particles). What if you wanted simply a choice of colours, e.g. green, blue, magenta, with no gradient.

2. It would be nice to set a shape/polygon to constrain the particles, i.e. they disappear if they leave. A bit like the 'visibility rectangle' but as a polygon and is not just for the IDE. I imagine this can be done with another node, but part of particles would be nice.

3. It seems the curve editor is now inline rather than in the bottom pane, however the height is fixed so if you use the bezier and move it outside the box, it's sometimes impossible to get it back. Either allow the height to be changed to add margin/padding or allow them to be undocked

4. I'll raise this as a new suggestion, but the number of particle2D boxes and properties is massive, and scrolls forever if you have lots expanded. What would be nice is some sort of inspector anchor, e.g. a new section locked to the top and for any property you can double-click/right-click/click new icon and a copy is made to this box. For example if you want to click 'emit'/'one shot' or are testing two separate properties you have to scroll all over the place

5. It's difficult to know where you are with resources expanded. Why no allow each section heading to be coloured, or for resource elements to have the title bar a different colour so you know you're in a resource and not a standard property

6. Some kind of event to know when all particles have left the building or the last particle has started his journey

[cloewen8]

I don't use particles very much but have been more recently in Blender. I love using the hair particle emitter with a mesh or collection. Especially with weight maps for different properties, namely density and length (size). I'd imagine in Godot I'd need some kind of wind and turbulence property or shader (vertex shader?) to make this practical for a game.

That and basic emitting particles is really all I need. I don't see many high end games using very complex particles.

[boukew99]

How I could see the particle system work in scene tree with nodes is with composition:

Example:

Particle (config warning: need emission shape)

• ParticleTextures(texture, normal map, color, color ramp, angle, scale .......
• ParticleAnimation
• Gravity
• Damping
• Trail
  .....

That way you can immediatly see what (custom) compenents of the Particle system are used and it guides the user with config warnings.
Also, this is in line with how godot already works (ParticleTexture could perhaps be shaped, so it becomes familiar to sprite node users).

[Giwayume]

A simple request, have a way for the particle's rotation to match the direction the particle is currently moving based on its velocity.

This may be possible based on what's already been discussed in this thread.

[mauriciomarinho2]

Would it be possible to expose the random seed for a ParticlesMaterial? That could help me a lot, I'm using multiple viewports just so I can use the same system (still didn't find any other way)

[ghost]

It would be useful to be able to set other AAB-shapes or even collision shapes as bounds for particles besides AABB. For example capsules, cylinders etc.

[eon-s]

Since the new particles system was added recently this may need to be closed and the feature can start receiving improvement proposals...

[Calinou]

Closing per @eon-s' comment.

The following features have been implemented in the new 3D GPU-based particles:

• Subemitters (e.g. for fireworks)
• Manual emission (this makes it possible to implement emission by distance)
• Attractors (box, sphere, 3D vector field)
• Colliders (real-time box/sphere, baked SDF, open world heightmap for weather effects)

See this article for a detailed list of changes. You should be able to test the new GPU particles by using one of my nightly builds. Please report any bugs you encounter on the main Godot repository after searching for duplicates.

2D particles and CPU particles haven't been reimplemented yet, but both of them are planned. No need to open proposals for those.

[golddotasksquestions]

2D particles and CPU particles haven't been reimplemented yet, but both of them are planned. No need to open proposals for those.

I would have an urging request for Particles2D though (that may also apply to Particles3D, but I never used those before). I spend a number of hours yesterday, ultimately failing, trying to adjust the intensity of a character running dust trail (a single Particles2D) via code. The dust should increase/decrease in strength and scale according to a Vector2.length(). Easy enough?

$Particles2D.lifetime = clamp(Vector2.length(),0,0.43)
$Particles2D.speed_scale = Vector2.length()
$Particles2D.modulate.a = Vector2.length() all works, but is not quite enough to create the illusion of of less intense dust.

You might think you could also just write
$Particles2D.amount = int(Vector2.length()) or
$Particles2D.material_override.set("scale", Vector2(Vector2.length()), Vector2.length())))
but no. Doing that in physics_process or process will break the Particle2D.

If you want to have the particles fade out over it's lifetime adjusted dynamically via code (this is done with the ParticlesMaterial Color property using a Gradient and setting the last color in the gradient alpha 0 in the editor), you have to dive much deeper than scale to get to that last Color property. Not sure if that even works as I found it way too much effort for what it is supposed to do.

The other alternative is very time consuming finicky and creates a lot of overhead: Adjust the Particle properties and the ParticleMaterial properties manually until they visually look right, save that as a separate scene, and then swap out scenes according to Vector2.length() thresholds. But this won't give you smooth transitions unless you make a lot of these particle scenes.

Ideally it would be great if we had a visual representation of the particle lifetime direction and amount in the editor. Something like a curve with starting and end point I can drag around. The curve would be able open up like a hand fan into an arced segment when pulled at arrow icons from the side or to a full circle increasing/decreasing in size when other arrow icons pulled from the starting position.

Even if we never get such a handy visual aid, I desperately would need to be able to change particle scale, amount and alpha falloff dynamically via code.

[CodeSmith32]

+1 to @chucklepie's # 6 suggestion:

6. Some kind of event to know when all particles have left the building or the last particle has started his journey

In my case, restore the 'emission_stopped' signal -- i.e. one that emits when the last particle has died. I am using the 'One Shot' option for a particle system of a bullet after it hits, and would love to have the option of destroying the particle system as soon as it's no longer necessary.

I suppose I'll just use a timer. But maybe there's already a better way to do this I'm not aware of?

[Calinou]

Even if we never get such a handy visual aid, I desperately would need to be able to change particle scale, amount and alpha falloff dynamically via code.

godotengine/godot#79527 adds an Amount Ratio property, which allows you to change the amount of particles dynamically without causing the particle system to restart every time you change the amount.

In my case, restore the 'emission_stopped' signal -- i.e. one that emits when the last particle has died. I am using the 'One Shot' option for a particle system of a bullet after it hits, and would love to have the option of destroying the particle system as soon as it's no longer necessary.

emission_finished was added to GPUParticles and CPUParticles in 4.2: godotengine/godot#76859, godotengine/godot#76853