Godot-proposals: 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?

1. 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)

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

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

4. 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]

https://github.com/godotengine/godot-proposals/issues/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.

[rapsaGnauJ]

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 emittingproperty.

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.

[fmenozzi]

Something that I've actually run into the past few weeks is the issue of pixelated particles. I'm making a pixel art game that, for various reasons, has to use the "2D" stretch mode instead of "viewport". It would be great if particles had a "pixelate" or "discretize" checkbox that would snap them to the nearest in-game pixel. Here's a comparison gif comparing normal particles (right) with the pixelated version (left).

I achieved that effect by placing a viewport over the particles, but this causes the "non-local coords" option not to work anymore, since I assume they're now using that viewport as the root transform instead of the root viewport's. Here's an gif showcasing that issue. Note that both particle systems have non-local coords enabled.

I suppose it might be possible to convert all my particle materials to shaders and add some shader code to each one that performs the pixelation, but that seems like a hassle to have to do to each particle system. If it's possible (and if there's interest), I think having built-in support for pixelated particles even in "2D" mode could be really cool.

[metalfrog2018]

Maybe some particles bake system? like the physics bake in Houdini? https://www.youtube.com/watch?v=6MgUEbfrjXA&feature=youtu.be&t=2540

[navett52]

I would love the ability to have particles bounce off of objects. Maybe an option in process material for bounce. It can be checked on or off and if on could give you more configurable options like how bouncy the particles are, what angles they bounce at, etc.

[HoneyPony]

There are two things I have wanted to do with particles that I haven't been able to do:

• Spawn a bunch of particles and have them live forever (like fur, for example). I think this is technically possible by spawning them and then setting speed scale to 0, but that's not a very good solution.
• Once I was trying to change the amount of particles dynamically, but changing the amount restarts the simulation. It would be nice to be able to change the amount of particles without the simulation restarting (so that a particle effect can become gradually more complex).

[skycook]

+1 for particle physics (clipping and/or collision), esp culling when they hit the origin for eg particle attractors.

+1 for velocity/acceleration based effects: deformation/color based on velocity.

Billboard mode for 3D particles.

Things like this are easy in unity but really hard in Godot:
https://www.youtube.com/watch?v=50rlfU-rOk8

Basically things I complained about there:
https://www.facebook.com/groups/godotengine/permalink/1778059585663961/

[HeartoLazor]

A powerful Particle Physics system which can be used not only for particle animations, but for game features too, think about make bullets from a shmup particles or units in a strategy game particles.

[jason-luxsonic]

The unity particle trails module is really great. It allows very easy creation of impressive effects.
https://docs.unity3d.com/Manual/PartSysTrailsModule.html

The way godot's particle system handles random ranges is not very intuitive. I believe it has weird behavior for values < 1.0, as well. It should just be simple min & max.

Particle Lights or Emmissive material support would enable some really great effects as well.

[KoBeWi]

I have a bunch of rather minor problems with current particles.

First, randomness. Right now for parameters like velocity, angle, etc. you have one slider for max value and another for randomness, which means that the value can be anything between 0 and max. It's meh. Maybe this could be min and max, with max being less than min by default, which basically would mean "don't randomize".

Second thing would be customization. It happened a couple of times that I wanted to achieve something not obviously possible with the default material. I don't remember the exact effect, but I thought about trying to edit the shader to achieve it. And while the ability to convert the particles material to shader material is nice, the resulting shader is prohibitively complex. Also with shader material you lose the nice inspector for the material and instead you have a wall of uniforms. It would be nice if we had some ability to extract a "minimal shader" or tweak some shader code in a modular way.

A problem I had recently was need for dynamic visibility rect. I have a projectile that emits particles in global coordinates. The problem is that the visibility of all particles is bound to the node, so if the node moves out of the screen, any stray particles that are still on screen would become invisible. This can be only worked around by having a very very big visibility rect that could cover the whole trail with all possible directions considered (so basically a huge square). I wonder if it would be possible to dynamically fit the rectangle based on the trail.

I think I had one more thing, but I don't remember it now. Anyways, hope this feedback is somehow useful >_>

EDIT:
Ok, I just remembered. Generating visibility rectangle is cumbersome. If particles have long lifetime, it takes long (which is a problem on scenes with many particle nodes where you generate the rectangle for each of them). Would be nice if it was instantaneous (like, instantly simulating whole lifetime, so you don't have to wait).

EDIT2:
Also not sure if anyone already mentioned it, but ability to animate amount of particles would be useful too. According to a related issue, right now when you change amount, the particle buffer is recreated and the simulation is reset. There should be some way to define a "max amount" of particles, so that changing amount within this value wouldn't reset the simulation.

[PapaCheese]

the trail can be more controlled

[DaividFrank]

Callback on death
I have long wanted a callback function when particles "die" (i.e. for spawning something in that location for blood splatters and such), and am willing to implement it myself if necessary, yet I fear for the performance implications this will have...

[benbishopnz]

Not sure about a good way to do this, but particle rotation based upon direction of travel. I would use this for starburst type effects.
Also seperate X/Y scale?

[UgisBrekis]

I think we could definitely use Unity's particle system as a good example. It might seem scary and bloated, but I've created plenty of particle FX for slots games which require very rich looking visuals and I can't really name many issues I had with it. If there was something missing I was able to add my own forces and logic to the particle system without much hassle. Here are a couple specific things I really like about it:

• Almost all parameters can be either single value, min/max range, curve and random between 2 curves. The way Godot addresses this is just max value and randomness which instantly imposes many limitations.

• Chained particle systems; one particle system can trigger other particle systems. Most simple example- fireworks. I would set-up one particle system which launches 1-2 particles every second in random direction; during each particle's lifetime it would be emitting trail and some sparkles and at the death it would trigger another particle system which emits 10 particles in the location of that particle which in turn produce trails and some other other secondary FX.

• Noise; can be either static or moving. Huge lifesaver for creating convincing ember particles.

• More freedom on defining emitter shape. Quite often in Unity I use circle with thickness; segment of a circle, edge, rect, etc. One of the coolest aspects is that the user can define in normalised value how filled is gonna be the emitter shape- just the edge, the whole shape or anything in between.

In general it would be great to be able to access particles themselves from the script, so that we could write custom logic and force fields.

[chalcosoma]

Hello, Juan and other contributors! Firstly, thank you, Juan, and thank you all for your amazing work on the Godot Engine. I'm very grateful for using such an incredible piece of work for free.

I saw your comment on the Godot Facebook group saying this after a comment to look at Unreal and Unity particle systems:
"But they may also have stuff nobody uses which I don't know whether it's useful or not.. so I prefer ask users instead."

I think the entry barrier for the beginner VFX artist in the current system is pretty high. I never did particle systems before and my approach to learning was looking for Unity VFX tutorials. The problem was when I saw the first tutorial, I tried to it step by step looking for how they did in Unity and translate to Godot but the missing properties in the Godot particle system in relation to Unity was so many that I didn't know how to make the same effect in Godot.

I always found fantastic the Godot unique way to do things without worrying to be equal other engines but I think particle system is an exception. I think it would be awesome if you make the particle system as close as possible to Unity's system. It would be easier for beginners to use it.

[fossegutten]

More emission shapes and preferably custom shapes. Maybe a possibility is to add a mesh as emission shape. In addition to this it would be great with a boolean to toggle emitting only at the rim of the shape, or in the whole volume. Also 2d shapes for use in 3D particle system.

[securas]

As suggestions:

• Particle collisions. It's been promised since 3.0 but set aside for other priorities.

• Programatic CPU particles. It would be very nice to be able to attach a script to each particle to control its behavior instead or relying on the editor settings. Might be a performance issue though.

[justinbarrett]

mesh emission, out of the box.... by volume, normal or even a UV2 texture etc
EDIT: I apologize for not reading the initial post:

I have been working on an open world action rpg.
The reason I would like to set particles to emit from meshes is probably self explanitory...there is a multitude of use cases..I would use it for grass... particles are better suited for this than multimesh, since you have a range in which the particles could be emitted instead of drawing all the grass for an entire open world...

it would be nice also to be able to set lifetime to negative values or just zero to indicate that they have infinite life...and the clipping volumes that are associated with the particle systems should also despawn all particles outside of the aabb, or mesh volume(defined by a mesh instance)...this could also be handy for clouds and other atmospherics.

lastly: I would also prefer to cull them with range as opposed to the cull bounds we can adjust now...since they will be culled by the frustum (camera) anyway.
I hope this makes sense and I do not sound too much like an idiot :)

[nikhilCad]

Please do something about godotengine/godot#17903

[Byteron]

There's only one thing that had me bugged in the past, for things like dust trails for running characters.
Reducing the size of particles at runtime (when the character walks slower) resizes all particles of that node. I'd like to see an option that only applies runtime changes to newly emmited particles and the ones that are already visible retain their properties like size etc.

[Jummit]

There is a very comprehensive list in this issue: godotengine/godot#10239

[benjaminsuhr]

Stretched particle billboards in the direction of movement (and additionally scaling on each axis). Even when motion blur is beeing added in the future, this helps to give particles more sense of speed. Some effects will become possible, that were not possible in Godot 3.0.

[Calinou]

@Zireael07 Allowing particles to be emitted on a distance basis (instead of time) is being tracked in #780. I think it's an useful feature, even if a proper trails system would make it less important to have.

[Zireael07]

Thanks for referencing the correct issue - I remembered there was one but I couldn't remember the number :)

[Lamoot]

Guiding emitted particles along a path / curve. This would be essential to display a flow along a specified path, like blood cells inside the veins or fluid along the pipes.

It might appear this could work by simply moving a particle emitter along a desired path, but that wouldn't produce the same flow effect.

[ZX-WT]

I am not a experienced user so I cannot give precise suggestion but I guess there could more control of the particle for non-technical artists, some more built-in slider or buttons for adjusting.
The current particle system can be customized by particle shader which is too technical? Maybe some more sophisticated nodes for creating shader which can help non-technical artist? A node based system which is not identical to coding, more high level?

Here are some suggestions which is more vague.
Maybe have a look at unreal's cascade?
A particle system that is flexible and easier to achieve things that is shown in https://realtimevfx.com/.

[lentsius-bark]

I'd like to second @UgisBrekis, the unity's particle system and its editor have been a great experience for getting things to look right, lots of things to tweak. Random values between two numbers of colours is really cool too.

[mhilbrunner]

What I've used and liked in the past:

• Mesh particles
• Trails
• Emitting from a certain face and/or point of a mesh
• Being able to pre-warm a particle system by letting it start at some time instead of 0
• Collisions

Relevant proposals:

• Particles system emission by distance
• Make Particles emit a signal when it's finished emitting particles
• Particle improvements and Scenes as Particles
• Particle System Proposal

Relevant issues:

• Ribbon Particle Trails
• Ability to pause particle simulation in the editor
• Particles bouncing off of collision objects?
• Improve Particles Damping/Drag Behavior
• Tweening the amount of particles slows down engine considerably
• Interpolated particles between frames
• Particles2D with non-local coordinates on ParallaxLayer have wrong transformation
• [TRACKER] Particle system improvements
• Particle effects (3D) in a viewport blend to black
• Particles 3D, Shape mode "points": points can be defined only in distance from 0 to 1 from the origin
• [TRACKER] Particles issues
• Enhanced 2D and 3D particle system & tooling

Inspiration from what others are doing:

• Unity has their Visual Effect Graph
• UE4 has Niagara
  Both tend more towards being node-/visual graph-based authoring tools for visual effects than just particle systems. But the systems of forces and particles are fairly nice.

[Athsmar]

Signal to know when particle emission is over, basically like the animation finished signal .

[2plus2makes5]

mhilbrunner already linked my proposal( https://github.com/godotengine/godot-proposals/issues/626 ) so i'll just do a quick summary:

1)separate the particle emitter(think of it as a gun, shotgun, bomb ecc whose only function is to shoot particle in a certain way) and the particle itself, the emitter decides where and when and at what direction(and eventually with what force) the particles are shot, all the other infos like lifetime, movement, look etc are part of the particle. this way it would be more clear, easier to understand and more reusable, an emitter can be used with more than one particle and a particle can be used with more than an emitter.

2)make the particlematerial more flexible and easier to use.

3)in addition to particlematerial and shadermaterial let us use nodes and scenes as particles, this way we could have complex physics and behaviours, like particles that shoot other particles(like fireworks), particles that follow a target or we could even use the particle system to spawn enemies, bonues etc.

[frankiezafe]

Hello,

Just to mention that i did some work to add physics in particles, the code might be of interest: https://gitlab.com/polymorphcool/futari-addon
It's basic physics computation in vertex pass of each particles, using "modifiers" placed in the scene.

Modifier types:

• wind: directional force on all particles
• attractor: sphere pushing or pulling particles in range
• vortex: spiral motion on particles in range
• floor: attempt to make a planar collider

All modifiers have gizmos + control textures; particles and modifiers are taking layers into account. The registration of the modifiers in particles is still tricky...

Asteroid field demo: https://www.youtube.com/watch?v=pwp7T1Tft9w

Let me know if you are interested, i'd be happy to participate to the integration of advance particles system in the engine!
All the best, godot is great.
fz

[elvencode]

I add here a video about the system created by Sucker Punch for their PS4 game.
https://www.youtube.com/watch?v=o2yFxPY2b1o
The initial part is more of a showcase related to the game (still interesting examples) and around 25:50 it shows actually the tools. It's a mix of using keyframes and scripting within the properties of the particle system to define how the elements behave. It's quite minimalistic UI wise but still powerful. Probably all those expressions would translate in a graph but here you have all in a contained space to tweak it quickly.

Interesting the idea of deeply connecting the particles (even to a single one level) to other elements in the scene, like attaching lights, reading vertex data (from an animated mesh or static one) and spawn particle elements from there (follow them, giving them the same colors, etc). Maybe too advanced but a simpler case would be sharing some input between different particle systems (ex. wind direction and power) and data between them (ex. emit particles from one system when end of life of particles in another).

Being able to code the logic of input data, spawning, update of various parameters over time of each particle, detect events like collisions, end of life, etc with some language (piece of code to go inside the compute shaders?) certainly would give more flexibility to the developers/artists.
Still classic options like the ones used in the old system would need some easy preset selection to choose without going to scripting deeply. Instead of the huge set of options in the current system you'd choose just what makes sense and see just that (with the properties to set with the uniforms logic of the other shaders)
Some cool stuff could be made default into Godot if the community create it (i like for example the UV magnification idea in the video to simulate volume for smoke billboards). Basically new functions (keywords) with parameters to pass.
I don't know how it would work on GLES2 without compute shaders. Maybe make a loop with a timeline tool, bake the data changing over time into textures and replay that in less capable hardware via interpolation? Could work but if something is dynamic it wouldn't be possible to convert that way. Baking could help also simulating collisions on set pieces (like looping sparks in some place or potentially fluid simulation for smoke, maybe even externally), you get the data on a powerful machine than replay it on lesser ones.
Or the compute shader logic could be translated to CPU with obvious limitations.

Another interesting thing comes from Unreal with volume based systems, like dust particles going around in vector fields (a box shape with multiple directions defined in that volume). A system could be affected by a volume applying a single force (like wind) or a volume with different, smaller, forces depending where you are to simulate some randomness. Maybe forces would be better handled with particular nodes on the scene defining volumes instead of setting values on the system? Maybe it'd be good for classic uses but limit the user to do some other custom stuff?
I don't know if those fields can also be used to limit the particles within the volume itself, trimming anything that could go outside it. Like being sure something doesn't clip inside a wall with any parameters you set.

[claychinasky]

I'm not sure technical details about my proposal but this,
True, many improvements can be added to the particle system as they are required but they are like version 1.x of all and AI driven particle systems would be 2.x
AI driven simulation is interesting concept. Particles like soft body, hair, rope, fluid etc.
And non of the real time engines have these but yet it seems possible.
Imagine an particle engine in Godot that accepts model data and algorithms as an input, where they the trained data comes from outer source as like tensorflow, pytorch or something else.

as this Channel interested in this topic and to have an idea of what is being papered
https://www.youtube.com/watch?v=54YvCE8_7lM

[nezvers]

• Support rotating emitter I encountered this problem in 2D by making a top-down car that leaves tire marks (couldn't make it work with particles).
  > - The emitter is not rotating with the parent.
  > - All particles deployed are rotating with a changed angle.
• Animated particle respect the last frame Using animated particle there's no way to make end life with the last frame. I had to implement my own system to satisfy these simple and in my opinion, must have particle system features:
  > - with random lifetime make animation speed to divide frames evenly to end with the last frame.
  > - have an option for a random start frame but still divide all frames evenly to end with the last frame.
• Snap to pixel Option to lock particles on pixels.
• Particle modifiers As an example in Defold engine (which is now source available). Like specific nodes that can interact with particle systems.
• Acceleration - Acceleration in a general direction.
• Drag - Reduces the acceleration of particles proportional to the particle velocity.
• Radial - Either attracts or repels particles towards/from a position.
• Vortex - Affects particles in a circular or spiraling direction around its position.

For 3D there's massive opensource particle system Effekseer, that has WebGL support. It can be referenced or supported in Godot.
It has already has runtime support for Unity, Unreal, Cockos2D, DXlib, RPGmaker.
Creator mentioned that he is thinking to create Godot support from their side.

[FaultyFunctions]

I don't know if this is currently possible, but having the ability to apply a fragment shader to the Particle pixel output would be fantastic. This sorta goes into what @fmenozzi mentioned. This would allow you to use a pixelate shader or other shader effects on the particles. Either that or have a "pixel perfect" option without having to change the whole project to the "viewport" vs "2D" setting.

Also having signals for when all the particles have died would be great, and adding an "autostart" function for particles that are instantiated from their own dedicated scenes. Currently, the "oneshot" button clashes with the "emitting" button for no reason and an autostart isn't achievable.

[ntswamp]

hi very newhand to Godot there, really love the engine for intuitive design.
but somehow i found that 2d games built with Godot are just not such graphically clear, gleaming, vivid, or just say "juicy" when compared to games made in GMS or Monogame like Miami hotline, Celeste, Undertale or just take a look at this one https://youtu.be/0OGfO-2M2y0
actually i can even recognize the engine behind games by merely watch it. the Godot side looks a bit sort of grey and dull.
i got no idea is this just a question in art sense of game maker, or some technical reason though.

[Calinou]

@milkvolleyball Please keep the discussion on-topic about the new particle system.

[swarnimarun]

I don't have any feature requests just a couple quality of life ideas/requests, these may not even be rendering features but just UI changes, but I think it would be nice to work on the system keeping them in mind.

Solo Mode/Selective Rendering of Particles: Ability to just render one particle or one type of particle in the entire scene disable other particles to be able to test the impact of the particle effect on performance and visuals, and to be able to tune particle effects selectively even after finishing a scene.

And,
Quick Presets, or Simple and Advanced Editor UIs, to quickly setup the particle effects without having to change all the knobs and dials from scratch.
Like, say, the editor is in easy mode and can change a lot of settings under the hood at once, and then we can jump to advanced to mode to tune it more as per our need. Or just quick presets which can be saved and reused, like I don't have to setup the fire particle effect from scratch every time...
Maybe even both?

Both Unreal and Unity support some version of these features too, can make iterating over the particles much easier.

[Beefster09]

Probably some repetition here, but this is stuff I could see being useful.

• Ability to query and manipulate individual particles, e.g. position, color, rotation, lifetime
• Ability to emit and destroy particles individually from a script
• Collision detection: not just bouncing off walls, but also the ability to implement flamethrowers, water jets, etc... with particle systems. So Kinematic particles, I guess.
• Emit an "all_done" signal when all particles have died (if the particles are no longer emitting), and/or a simpler way to "delete" a particle system without deleting remaining live particles
• Emit a signal for each emitted particle, which could be used to sync particles with sound effects.

And make sure there is as much feature parity as possible between 2D and 3D systems. It would be sad indeed if I could only use physics particles in 3D.

[vagrantG]

How about being able to use the particle system for interactive cloth? You create a grid of particles constrained to each other. Every element is a tiny sphere that collides with other elements in the scene (using voxels or SDF simplification of meshes using for GI to recreate a mass of particles/spheres to have the same volume of the objects for collision detection on the GPU). Then the cloth mesh is deformed based on that particle representation.

The other way around is using this to debug a cloth simulation in the editor, by displaying a particle for each node of the grid of the cloth, instead of a single entity for each one in the scene. If the particle sphere collision would be detected with a mouse click it would be a very useful tool to create control points in the editor to manipulate single point entities.

In the future that kind of interaction can be used for fluid simulations. Here's an WebGL example
http://david.li/fluid/
Could be useful to animate realistically the dust in the air when moving around a room :)

[jitspoe]

Here are 2 things I hacked in that would be useful in a general case:

1) An option to take the camera velocity into account when orienting particles based on velocity. I noticed when creating a spark particle with a trail that the particles looked off somehow. Subtracting the camera velocity made them look much better (because sparks create a trail based on exposure, so the trail is going to be from the velocity relative to the camera location). You can see it in effect here: https://twitter.com/jitspoe/status/1269216334467956738?s=20
2) An option to adjust the amount on the fly without restarting particles, or an option for a number of particles to emit per unit of distance. That way you can have particle trails on things that move at variable speeds without them looking too sparse when fast and too dense when slow.

[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/[email protected]/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)

[Thyrux]

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.