ParticleSystem: Ring buffer support

@richardkettlewell
I use the ParticleSystem not just for traditional particle effects, but also as a "generic fast renderer". For example, I use the ParticleSystem to emit footprints and bullet impacts. Using a particle system to render hundreds of these objects is a lot faster than using a MeshRenderer for each single "decal".

I use the "Max Particles" property to limit the particle system to e.g. 100. Now I walk around with the player and emit lots of footprint particles in the world.

If the particle system contains 100 particles, no further particles will be emitted, unless old ones die.

I would like to have an option that a new particle is emitted always, BUT it replaces the oldest particle, like a ring-buffer concept. This has a big advantage for rendering these kind of things.

So far, I need to specify a particle lifetime to make sure there is always room for a new particle. However, if the player does not move and is just looking around, it's very noticeable that older footprints vanish due to the lifetime. (no matter whether they fade out or just hide immediately)

If the particle system supports to replace the oldest particle with a new one, particles can have an infinite lifetime, while maintaining the "Max Particles" budget. In my case, the problem with obvious vanishing of footprints would be minimized as well, because old particles get replaced while the player is moving only, which is hiding this issue. The same applies to bullet impacts.

Several games seem to use that "ring buffer" concept for these things. For example, I noticed this recently in Call of Duty Modern Warfare Remastered.

I believe this mode is generic and could be used for a lot of things, not only for what I use it in my game. That's why I suggest it here for the ParticleSystem, rather than coming up with a custom solution.

I could probably use DrawMeshInstancedIndirect for that as well, but it feels a bit overkill for just a quad to use GPU instancing for that. The ParticleSystem also comes with a lot of useful other options, that would require a tremendous effort to reimplement in an own system.

What do you think?

 

Just adding own experiences:

I used a technique of setting Particle from a local array for mobile when it turned out to be far too slow with other options, and that point sprites weren't guaranteed to function well. This was awesome and I was able to handle several thousand on a mobile where otherwise I'd have had to construct some form of elaborate shader system. I did not actually use any of the features of the particle system except as a dumb renderer.

I also had to hack in some form of time code for changing the image of the particle as the wasn't any API support properly for it back then (this was Unity 4).

But these days I'd probably just go with DrawMeshInstancedIndirect, unless quads are much faster under a GPU particle system in the future.

 

Good point, I didn't think of that. This is where it gets more complicated. I first thought was they all just pause at the end. But this feels like a harsh limitation. It would certainly work for my case, but this wouldn't make it as generic as I though it would be.

Another idea that comes to mind is to use loop-markers. I know this from audio systems, where you specify attack (fade-in), sustain (loop) and release (fade-out) markers (see ADSR). This makes it enormously easy to play looping sounds with proper fade-in and fade-out, audio designers love it.

Theoretically, the same concept could work with particles. If you can specify a "loop range" in a particle system, a particle could fade-in, loop until something signals "please die" and then fade-out. The loop-range would be specified using a time range. I imagine the "lifetime" of a particle would "freeze" while it's in the loop-range. A loop range is also easy to understand when authoring a particle effect.

If a particle has a "fade-out" in this example, it can't be replaced immediately with the new particle as I suggested in my initial post. The PS would probably need some kind of "buffer" in the particle array to allow these particles to fade-out, but not exceeding the Max Particles property.

Thanks for the info, perhaps I should just give it a try. But I like the particle system so much, that makes it hard to replace

PS: Thanks for your support even on a Saturday! I certainly didn't except a response to rapidly.

PS2: Having loop-markers would actually solve quite a few issues. I had to mimic this in various projects actually, where our VFX artist had to create separate fade-in, loop and fade-out particle effects and I had to implement code to glue them together. I remember a flamethrower was one of it. With loop-markers, the VFX artist could create one effect that contains everything and he/she could actually test it properly.

 

Any thoughts on the loop-marker idea?

 

I did imagine it would be quite a large change, but wanted mention it anyway, because I thought it might solve the Lifetime-based properties handling issue you mentioned. Perhaps it's something to keep in mind for a future particle system iteration.

If you believe it's a good idea and won't cause issues in the long-run, due to its limitations, then I'm all in for that new mode. It certainly would help with what I'm trying to solve here.

 

I second the need for a wrapping / ring buffer. All the particle systems I've made for my own engines have always just looped over an array overwriting the oldest (really just wrapping the index) when new particles are spawned, it is a very common and useful tactic. Especially with more hectic situations where there are lots of effects going on, it will always look worse when no particles are emitted when expected, than when old effects vanish to make room for new particles, IMHO.