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]

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.

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

[groundlar]

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

[abraaofilho10]

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.