[Official] Particle System [Shuriken] Improvements

Hi all,
We would like to discuss the direction of our particle system with you. Rather than pre-seed this discussion with what's on the roadmap, I want to be sure we don't miss anything, so I want to start this discussion with a relatively blank roadmap.

To really help us though, like we have done in other threads, it REALLY helps for us to understand who you are and what your use-cases are to put you comments in context.

Who are you?
What kind of game are you trying to build or would like to build?
How does particles fit into that? What use-cases do you have?
What are the GOOD things about the particle system now you like?
What are the BAD things about the particle system now you dislike?
How can we make it BETTER?

Again, it's super important we understand you and your use-case more than "add feature X now, do it!" without context.

Thanks!
Brett

 

Single dev, doing this part time. I'm a C++ engineer (medical devices) by profession.

A 3d submarine game (see sig).

Almost everything around water effects and explosions, splash stuff.

Ok, what I really MISS is just the ability to scale a whole ParticleSystem. That's it. Beside that I like the current system very much.

 

Jack of all trade hobby developer who is running a free game graphics resource page since several years.

This is not bound to a specific genre. In the past i made from puzzle games up to rpg nearly everything. Former project was a 3d jump n run with puzzle elements. Next may be a Bejeweled clone in 2D. Or a strategy game. Most likely a little tool first.

Like my previous poster, almost everything around water effects and explosions, splash stuff. Additionally stuff like fog, wind effects like a whirlwind, or status effects for the player, like pain stars jumping out of him.

I double the need to scale the whole particle system as one. It's a pain to adjust a particle system when you have it in a specific size already, and need it in another size. Makes it hard to transfer.

I also request a direct way to destroy the particle system by code. The current workarounds across is alive or to put it into a hierarchy and destroy the whole hierarchy is not as good as a direct destroy command.

 

A hobbyist game dev and game jams participant.

I'm making a 2D side-view neon-style football (soccer) game.

I use particles mostly for "juicing my game up" when collisions occur. It gives a really cool visual feedback of what is happening during a fast paced game.

It's pretty straight forward to get the desired effect. But please note that I'm not really an advanced user of particles, so my use cases may be really simple

Some properties are not exposed. For example it's not possible to assign the Collision planes after instantiating a particle system, which is a pain :/

Expose every attribute of the particle system! Something as simple as changing both "Start Color"'s when set as "Random Between two colors" or setting the collision plane as I mentioned before are not possible right now.

 

Hobby dev, third person open world game.
Water, smoke, rain, indicators (directions, mission starts)
Explosions are looking good enough for me (with detonator prefabs )

I like the flexibility of the system, but:
- its too slow (a circle with a "few" particles (maybe 1000?) drags my game from around 110fps to 60fps if in view), should maybe be gpu-accelerated
- billboards don't work with lighting
- wrong culling, the whole system disappears if the particle start is behind the camera
- should have better presets. The system looks good if you know what you do, but the examples look like coming from 3d game studio 2002...

I'd really love to have the smoke of the new "the division" gameplay videos. Your transporter demo shows that you really really improved shaders, lighting and antialiasing, but the smoke still looks like a quad texture with perlin noise moving through the room, and smoke would probably be the single most used effect in my game. Guns smoke, bullets do, cigarettes, manhole cover, cars, tires, waterfall haze...

It is possible now to make really diverse and unique magic effects for a RPG for example, or those sparkles with physics interaction, but smoke or water is missing a bit.

 

As an artist I really don't have much problems with Shuriken. I'd give another vote for scaleability and maybe a profiler for how expensive a single Particle system is on the system. But other than that... I don't really have any problems with it, yet. I fact - I like it

 

who i am ? hobbist, in future asset publisher, 3d game

use cases - enviroment effect - dust, falling leafs, snow, rain etc..., effects for spell/power/level up

adv of shuriken - visual editor with some randomization based on curve, contain some event system which is useful for collision and so on situation

disadv - slow, no gpu-accelerated, lack of API (e.g. cannot set runtime 2x curves if i use random value between curves) and some visual feature (path particle based on curve/spline in 2d/3d space rather than hard type vector which is counter-intuitive and require more reiteration - vector for force (over lifetime) is good when we require very precision, calculated by math path but not for "organic" effect)

How can we make it BETTER?

more API, more visual features like path/force based on curve/vector (defined visual rather than hard typing), improve performance, more complex event system ? (e.g. define event which throw after some sec or after reaching above/under defined value in selected property?)

 

Me:
In my spare time, I sell asset packages, mostly particles, and I'm prototyping 2d games. I worked in the games industry for ten years full-time on games such as Baldur's Gate II, Neverwinter Nights, Need for Speed Underground/Underground 2/Most Wanted/Carbon and a bunch of other stuff. My job titles have been technical artist, effects artist, lead lighter, and environment artist. I have worked with a half dozen engines, Max, Maya, Softimage, After Effects, etc. I have created particle effects for most of the games I've worked on: 2D, 3D, and cutscenes.

Use cases:
I create asset packages with effects that have a theme. For example, I know that a lot of people make games with a pseudo-retro vector graphics look, so I will create a group of effects that I think they would enjoy. Other packages might contain smoke, fire or other things that enhance environments. I try to keep the effects as simple as possible. I want the noobiest noob to be able to use my stuff without asking for help.

For my prototypes so far, I get more technical because I am comfortable with scripting and shaders.

I'll fill in the good/bad later, gotta go to work!

OK, I'm back...

Good things about Shuriken:
- Shuriken has just the right amount of complexity for 99% of the particles I currently make. For most of the games I've worked on, Shuriken would have been a huge improvement.
- Shuriken never crashes on me. I think Unity has only crashed once for me in two years.
- The layout is organized well. I can find everything easily.

Bad things about Shuriken:
- For me, nothing really bad stands out.

Making it better:
- Althought I haven't done much scripting with Shuriken, I have done some with UDK/Unreal 3.
- I'd like to have the ability to easily pass variables/values between shaders and Shuriken a la Cascade
- example: if a value crosses a certain threshold, I increase the intesity of the lighting in the shader
-

I'll add more here when I've had time to think about it.

 

I'd like to see the addition of a new module to Shuriken that enables the sending of dynamic parameters per particle to the shader.

Specially the dynamic parameter would use a single shader semantic ( i.e a single float4 as TEXCOORD2) to enable up to 4 dynamically controlled floats per particle to be transferred to the shader. Its pretty much exactly what happens with particle colour now as that uses vertex colors.

This would enable particles to provide the shader information such as its current lifetime (normalised to lifespan) or other dynamic values that are controlled by a particles lifespan. Doing so would allow for more complex effects to be created with particles as demonstrated in this Fire tutorial created with UDK. Check out 31.50 minutes into the video for seeing how they link together dynamic parameters from their particle system to a shader.

Without this functionality its pretty much impossible to recreate the specific fire effect demonstrated as there is no easy way to get the current lifetime of a particle to the shader. You could re-purpose the existing vertex color data, but then you lose the ability to tint the particle over lifespan, so that's not really a solution or even a decent workaround.

I would suggest having a look at how UDK does this, but generally you'd want a set up where for each dynamic parameter float you can;

1. Select an input source

• Normalised lifetime of particle ( i.e. current time of the particle normalised to its lifespan)
• Speed
• Size
• SystemTime
• Collision - would be nice to get this in somehow, perhaps a value of 1 on a collision which then smoothly fades down to 0 over a specific time.

2. The source value should then be mapped using either

• Between two constants - i.e min and max value that the source is mapped (not clamped) to.
• To a Curve - i.e. source is horizontal, output is vertical from curve.

The key points are

• These values are per particle, not per system.
• Various source values can be selected
• Various mapping processes can be applied to source value
• The dynamic Paramaters are passed to the shader using a specific and documented semantic, e.g. TEXCOORD2

 

I am the developer of the Cloud System which is available in the asset store.

I am getting lots of emails regarding Shuriken. Many want to use it, because of its batching capabilities, but then they run into a culling issue. This bug makes Shuriken useless when the particles are modified by any script.
http://issuetracker.unity3d.com/issues/shuriken-is-culling-particles-when-were-using-setparticles

Within the Cloud System, it was necessary to integrate several hacks in order to setup the tiling and other basic functionality like that due to the lack of an API for almost all the modules. The hacks only work in the editor which takes a lot of flexibility away. It would be awesome to get access to all the modules (also at runtime) through an API.

 

Looking at what we know about Unity 5, one of the only fancy"next generation" features that is missing is GPU particle support. Is there any word on if this functionality will be implemented within Shuriken?

 

Who are you?

Keith Boshoff, Technical Dude. RetroEpic Software CC

What kind of game are you trying to build or would like to build?

We've made e-comics, infinite runners, point-and-click adventure, puzzle and many more games. A few more in the pipeline that I'm not at liberty to discuss.

How does particles fit into that? What use-cases do you have?

Mostly visual effects, in some cases those effects are vital to gameplay.

What are the GOOD things about the particle system now you like?

The curve driven nature and 'particle trees' that can be created with shuriken has been a massive boon.

What are the BAD things about the particle system now you dislike?

No scaling. A particle system can only be emitted from a single source (ie. I can't have 1 fire particle system that emits from 20 sources without coding my own particle spawners).

There aren't nearly enough script bindings to access everything in shuriken.

How can we make it BETTER?

Expose every single setting that's available in the Inspector to script.

 

Who am I? - Hobbyist and student, although I've done some game dev for educational and outreach purposes.

What game are you building/would you like to? - A first-person puzzle game, and would like to work on an exploration based 3rd person shooter, but I'm building design tools for that first.

What are you using particles for? - In my puzzle game, the art style is monochromatic, with only certain important features having colour. These are often highlighted with particle effects. So I use them for emphasis, drawing a player's attention through a level, and also for atmosphere, and helping the player understand their position in the world (eg. gravity often changes in the game, so there is a subtle dust effect to show which way is "up"). In the 3rd person shooter, the character is a magician, and all the "guns" are spells. This will require a lot of particle work, so I'll probably be pushing the system to its limits.

What is GOOD? - The modular design of shuriken means that it is pretty easy to use, and the modules are pretty self explanatory. It's easy to tweak in the editor. Being able to designate your own emission mesh allows you to create more interesting systems, but then you need to manually edit the normals etc...

What is needs improving? - There are both a few bugs that need fixing, and several features that could improve shuriken that I will list (in some sort of least-most important/easy order):

- Frustrum culling bug: if the particle system origin is outside the view frustrum, it disappears. This is an absolute show stopper for any system with long lived particles over a large area (like smoke)
- Easy particle system scaling: as mentioned
- Independent time scale: If you want to make a "stop time" effect, or just want particles in your pause menu, this is currently impossible. Adding such an option would be incredibly useful. Also it should allow particle effect to play backwards, which would be cool and useful.
- Negative forces/emission speeds: It's very easy to make an explosion effect in shuriken. Now try making an implosion effect. Much more tricky.
- More emission shapes: Ring shaped emission is quite a common need, for example. Maybe also defining local emission points. Also, being able to define "emission density" so that you can change the shape of emission and not have to change the particle emission count
- Radial coordinate mode: Ever try to make a particle system that has rotating elements to it? Sure, you can make the entire system spin with a script, but what if you only want part of it to spin? An ability to define motion in radial coordinates would really help with this.
- Better particle shaders: People have mentioned lighting, but there are several other kinds of shaders which I think would be useful: Alpha erosion (for smoke effects), refraction (for water/liquid), shaders that effect the colour of what's behind (eg making colour negative)
- Texture/UV based emission: Think an "emission map" like a specular map, that defines where on a mesh, particles are emitted from. (eg. just the bits that are on fire/burnt etc)
- Emission from skinned meshes: self explanatory, and really useful for character effects etc. Perhaps combined with the emission maps I've just mentioned (eg. making a characters arms become wreathed in flame)
- Attractors/repellors/turbulence/more interactivity: Whilst not vital, modules to do this would be incredibly cool. Imagine walking through a fog and the fog swirling more as you moved through it. Nifty.
- Path following for particles: Being able to make particles follow a spline path would be super cool. Maybe too much of a specialised requirement for the main shuriken package though.

and finally...

- Improved scripting access: So many parts of shuriken are not open to scripting. They really all need to be. Some of the desired features I could add myself, but without scripting access, that becomes impossible.

Thanks again for asking for this community feedback, it is a welcome relief after quite a long period of relative silence. It's good to know you're listening!

 

Can you make 2 separate sections on the asset store?

Particles - Legacy
Particles - Shruiken
Particles - Both.

 

Owner of a six person indie studio.

We are working on a space action exploration game, that is currently on Steam.
Kinetic Void.

Explosions, muzzle effects, nebula / dust, procedurally generated sector star, stars in our procedurally generated skybox (spacebox?)
.

For a basic particle system, it works, and does what it is supposed to do.

Its pretty limited, and the interface for making a particle system could be laid out better.

• Particle scaling. a particle can be used in many ways and many scales, the ability to scale the parent object and have the particle scale with it would
  be very good.
• In large scenes we have to use an origin reset to bypass float precision issues. When a particle emitter is reset like it it is cut, and then restarts. This is an awful effect and we can no l longer use particles for our engine trails. The ability to make the particles aware of the parent object and move accordingly would be most valuable, in many projects.
• Bring the UI into a single view instead of the inspector like one we have, with the ability to focus on individual particles, right now everything as to be assembled in a scene to get an overall view of whats going on.
• More - options, manipulators, settings, effects etc.
• Mesh related particle uses, emit from shell for example.
• More example content/assets, right now we don't even have the basics needed to prototype a new effect.
• open up everything related to particles in the API, there is no reason I can think of for this to not be available.
• I should not have to get assets to round out the particle systems in Unity, as it is now we use FX Maker and Particle Playground, Look to them to see examples of what Unity particles are missing.

I am sure there is more, but this is what comes to the top of my mind.

 

This would have to be a Windows only feature since Unity's OpenGL implementation doesn't support the features needed for this and they said they don't plan on changing that any time soon.

 

Why not? AFAIK all the stuff platforms Unity supports should have Compute shaders (Unless they are not in OpenGL ES 2.0) and even on all platforms except for IOS(It seems IOS does support it but Apple won't accept apps using it) there's support for Open CL which could be used, having a fall back to CPU would be ok, or even an option to pick.

Hmm, actually maybe not. Much conflict on this subject, I guess I'm not up to scratch on the lingo.

 

I would like to be able to emit particle in a non randomized way.
To create such effect :

 

OSX didn't support OpenGL past OpenGL 3.2.

 

Who are you?
The graphics monkey.

What kind of game are you trying to build or would like to build?
XY plane 2d exploration shooty game thats is trying to have some visual appeal (pc platform for now)

How does particles fit into that? What use-cases do you have?
smoke, dust, fire, splosions etc etc the full gamut.

What are the GOOD things about the particle system now you like?
Its extreme simplicity has some stability speed advantages.
The physics update was good.
Its quicker to setup than a 'legacy' system with all those components.

What are the BAD things about the particle system now you dislike?
Oh boy..no holding back? ok then...

My specific ongoing really really annoying issue:
Controlling the rotation rotation axis of particles is infuriating. Im having to use the UNDOCUMENTED ParticleSystem.Particle.axisOfRotation to get custom particles aligned to the camera in the XY plane. It maybe a small use case issue for you guys but I've been burning voodoo effigies of unity devs over this. You even changed the custom particle default rotation axis a year or two ago without telling anyone - was that just to piss me off? because it did!

General other stuff:
What everybody else says: Support lighting, scaling, expose its shame to one all.

Bigger picture:
Creatively constrained in the editor. I can only seem to get so far with it without having to start scripting each particle, no path support out of the box. Feels like a system for mobile games, barely competes with previous generation, no 'wow' factor.

How can we make it BETTER?
Give me control over default axis of rotaton! end the madness now!

Let me rotate particles in all axis simultaneously too - how does having to use a sprite sheet animation to do the cherry blossom thing make sense in a 3d engine?

While your fixing shuriken start planning its successor or a do-over - Is shuriken a true game engine particle system or a just a billboard/mesh emitter? Should it have a pooling system so I can shoot prefabs? I normally enjoy using any particle system in any application but with shuriken its always felt underwhelming, stable, but a bit meh.

 

Can you not just move all particles with .GetParticles(), move them, .SetParticles()?

 

Thank you for starting this thread, Brett!

Who are you?
I'm an independent designer/programmer. I've shipped a handful of 2D games using Unity over the past 4 years-ish.

What kind of game are you trying to build or would like to build?
Exclusively 2D games for a wide range of platforms.

How does particles fit into that? What use-cases do you have?
I use particles just about everywhere -- environment effects (snow, leaves, fog, smoke...), footsteps, collision effects, etc. It's a cheap way to bring a game to life.

What are the GOOD things about the particle system now you like?
It's very simple to use, and the inspector is artist friendly.

What are the BAD things about the particle system now you dislike?
It's slooowwww. Almost all performance issues I've dealt with traced back to Shuriken. It feels like it's impossible to compete with the particle effects seen in games like Resogun, or even Geometry Wars.

How can we make it BETTER?
1. GPU Acceleration. Let me go to town with particle effects!
2. Attractors and repellants. Or anything to increase the interactivity.
3. Expose the sorting layer property in the inspector. It's annoying to have to set this in script every single time.
4. Independent timescale. If I pause the game by setting the timescale to 0, I sometimes want the particles to continue animating. I can manually pump the particle systems through script, but it would be handy if there was some inspector setting I could set instead.
5. As almost everyone has mentioned, please allow us to scale the entire particle system

Cheers!

 

I've already introduced myself on another thread, so I'll keep this short and sweet.

I've spent only a small time with Shuriken doing fire and waterfall particles, so someone might be able to tell me all this is possible. You should aim to match UE4's particle system, it's generally quite simple to use and I know Unity could probably improve it in areas of workflow. But it just looks amazing.

 

Just to correct you, Mavericks (10.9) finally supports all extensions through OpenGL 4.1 on supported hardware. Hopefully, 10.10 bumps OS X up to 4.4.

http://support.apple.com/kb/HT5942?viewlocale=en_US&locale=en_US

 

Hi, I got one request for the Shuriken scripting API:

Allow us to change the type of emitter a ParticleSystem has. I know it has box, cone etc. and all that. Allow us to change that from script.

More than that, I want to be able to change the position, rotation, and scale of the box emitter from script, for example. Because I want the particle emitter positioned properly before I let it emit the particles. For example, an explosion whose radius I want to change first before I let it play.

In fact, it could be good for a single function call (or some way to do it from the inspector) to "scale" the particle effect (including any children particle effects). This would affect the size of the emitter and optionally also the size of the particles being emitted. Sometimes I may have bought a particle effect pack from the Asset Store only to find out it's too big/small for my needs.





Who are you?

I'm CTO and co-founder of our game dev studio, Dreamlords Digital.


What kind of game are you trying to build or would like to build?

We're primarily making a 3d tactical turn-based game called Graywalkers: Purgatory




How does particles fit into that? What use-cases do you have?

All the special effects for combat.


What are the GOOD things about the particle system now you like?

More settings to fiddle around with in the Inspector. Plus, it's more neatly organized.


What are the BAD things about the particle system now you dislike?

Lacking scripting API access, compared to the legacy particle system.

 

There's a very specific reason I used past tense there :v

 

Solo game developer and part-time university lecturer.

Currently working on a puzzle game.

Using the legacy particle system for timers, input feedback and rewards.

I like the legacy system because it has a standard Unity interface, I can alter values in code, it has features such as Systematic.

Things I like about Shuriken include it batches, particle animation, sub emitters.

Shuriken has a non-standard interface that I have to relearn every time I use it (same goes again for Mechanim), missing features from legacy, cannot change enough in code.

Standardise, add missing legacy features, more documentation about how Shuriken works.

 

Single game-developer, small asset developer

FPS

Particles are key for just about everything from Impact Effects to burning to atmospherics like fog.

- Interface (though it could still be better, looking at UE4)
- Batching / Performance (though others here say that's actually not true, but for me it is a big reason I use it)

- Need more advanced shapes (Donut, Chain, etc.)
- Regarding Chain Emission, it would be cool to define a path (with bezier curves) and manipulate it. I could imagine using it to create a nice looking gun barrel smoke that twists and distorts itself along a path together with some randomness. A little like in Metro 2033.
- Need more scripting exposure, I cannot manipulate Shuriken from script the way I want or could with legacy.
- Attractors/Repellers/Flow Volumes - I want all that.
- GPU Accelerated Collisions. I'm on AMD and therefore aware of the issues, but it's something I wanted for a long time and now with DX11 perhaps we might?
- Smoke effects don't look all that great, with the Alpha shader you get something passable but it kinda looks outdated. Fog over a large area is unfortunately buggy but essential for atmospherics. I use both of these things frequently.
- More high-quality examples by Unity such as Explosions, multiple sub-emitters and how to use the Spritesheets properly.
- In terms of Spritesheet, I have a hard time figuring out how to make it work properly and reliably. It's even difficult for me to figure out the proper Grid for it, I'd appreciate a template and a lesson at the very least.
- I can't seem to do nice Implosion Effects
- Organizing child particle systems is a bit of a pain, and gets worse in scripting.

 

Well, I see three recurring requests here that are my main wants, not in any particular order.

1. Access to everything via scripting-We should be able to to access every single setting at any given time in scripts.

2. Performance-GPU particles would be great for "faster" systems, at the least PC systems. With mobile devices it would be great, but there are more limitations there anyway so it isn't as much of a priority there, even though the speed is actually needed more there than on PC.

3. Interactivity- What the above posts have suggested...forces, attractors(which in negative work to repel particles), turbulence, better collider system, as in being able to collide with all colliders(or at least by layers) instead of simple planes. I know these things require a performance hit, but it should only require it if indeed they are in use. We are willing to take a hit if it is required to get the effect we want, and I understand very well that particle collision on a mesh collider would be a massive penalty likely only used with few polys and particles.

EDIT** The collision with colliders part is already implemented and I didn't know that, but the rest still stands.

 

Regarding 3:
Particles *do* collide with other colliders. I believe since 4.2 or 4.3

 

Indeed, I see that in the docs. It has been a while since I checked. I retract that part of my request

 

as already mentioned, I would like to see in Shuriken:
- proper scaling
- exposed sorting layer in inspector (for 2D usage)
- ability to manipulate everything (even during runtime) through scripts

 

Now the time has come to try to remember my recent issues with the system.. hmm..

Who are you?
Single indie developer from germany.

What kind of game are you trying to build or would like to build?
I'm working on an onrail space shooter (imgur screenshot)
I'm so waiting to move this to U5, since it's still very early in development, but well, it's the usual waiting game and not the point of the topic.

How does particles fit into that? What use-cases do you have?
Right now i'm using it in the scene from the screenshot for:

• explosions (i have to admit it's the old free explosion framework from the asset store that still works with the legacy particle system)
• space dust (barely noticable on the jpg compressed screen)
• spaceship afterburner
• some unfinished shielding effect

Tried using it for laser shot effects but it just didn't align right to the camera. Line-/Trailrenderers looked better but were too expensive so i went on to use very simple meshes.

I'd love to use it for various other scenery effects later, too. Like a snow storm for example.

What are the GOOD things about the particle system now you like?
I like that you can open it up in an extra window and edit the values graphs.
Prewarm is a great function, too.
Also that you can emit particles via script. Used that for bullets in an earlier game so i could have a lot of them on screen.

What are the BAD things about the particle system now you dislike?
Inherit velocity doesn't really seem right, noticed it when emitting bursts per script. It seems to take the velocity from the last emit, not the current.
Culling is a big problem since it's based on the origin and not on a bounding box. I tried using a Mesh for the emission shape to have a shape for a player surrounding arena that has some sort of magical effect coming from the ground. That did not work out because of the culling.
I'm certain i already hit other limitations, but i just can't remember right now.

How can we make it BETTER?
Turbulence would be nice.
Not sure if i just failed, but making particles move away in all directions from a sphere emitter and reverse their direction mid lifetime moving back to the origin didn't really work out. A little bit like a ball on a line you throw and pull back. Forces only seemed to work in a whole particle-system/world-space space, not single particle.
You're probably aware of TC Particles on the asset store. I don't wanna ruin their business, but unity really should have something like this build in instead of making their users buy something like this.


If i remember something else i'll mention it.
Also thanks for asking us !!

 

I have bought and like particle collections created by JMO Assets and On-Q to give you an ideal of my interests. I'd like to see those improved as faster and the collision planes as already mentioned.

For the wider world at large, and possible my own interests later if I buy a better computer I'd like particle systems to be associated with specific types of real events, in the same way I'd like PBR to allow me to say this is 'onion skin paper' texture and this is 'chrome' texture rather than something like roughness and specularity and such jargon such that you know what roughness and specularity is and those numbers are effecting it and look, lots of nice examples, but I want to type 'onion skin paper', 'rice paper', 'steel', 'chrome' and the correct shader come up to apply.

So now, back on topic, associating the particles with specific physical phenomena such be that distribution of particles, movement, and physical forces with those types of particles is typical of a tornado, a hurricane, fog, clouds, wind, rain, explosions, even something like solar systems and cosmology. A bit much for most computers and I read about Wolfram intentions and they do sound interesting but mathematics and physics is public domain. I don't like the ideal of having to ping Wolfram clouds all the time to compute these things although that there is a cost to using Wolfram's collecting of public domain mathematics into a convenient library is understandable.

Maybe the Unity engine can query the capabilities and of system running the engine and, as the capabilities of the system are better, then so is more of the physics and AI system available? But, and this is important, it should be intelligently scaled back when those capabilities cause the engine to sink in performance metrics say, for example, an FPS lower than say 24 FPS or maybe on a continuum capabilities that are scaled up down in accuracy: the more computing cycles and precision available the better one apply traditional numerical analysis techniques to varying degrees of accuracy based on that availability.

A lot of wind here but all I'm trying to say that the physics system would be nice if it was designed to detect the computing availability on start up and adjust it's precision based on the computing power available.

A similar concept could be done I suppose for shaders, lighting, shadows, textures, and meshes such that when you published to a known platform optimizing meshes and the other optimizations and substitutes needed to make something written from the latest dual card gaming PC rig to be simplified down to run on an iPod touch 4th gen for example. I know this wouldn't be easy as those are all somewhat arbitrary data structures but as standards are refined and converged it's worthwhile I think. The write once, publish on any platform rings a little hollow without such capabilities although any experienced reasonable person wouldn't necessarily expect Unity to be able to do that, but oh! if Unity could do that!

 

I definitely echo a lot of what has been said already. Some of the improvements/asks below might even be possible today (especially with scripting, but these shouldn't require that) so the requests would be for better, more intuitive controls and documentation/examples where that's true.

Who are you?

Head of game development at a large company, also long-time indie developer/designer

What kind of game are you trying to build or would like to build?

2D social/casual

How does particles fit into that? What use-cases do you have?

Environmental effects (background augmentation), UX effects (transitions UI enhancements)

What are the GOOD things about the particle system now you like?

Fairly rich basic controls and decent real-time visual feedback; a few great advanced functions but they're cumbersome to use and not well documented/implemented

What are the BAD things about the particle system now you dislike?

• Most of the issues listed already (inconsistent script access, culling issues, performance)
• Inconsistent behaviors in some of the features (e.g. velocity over lifetime, velocity limit over lifetime force over lifetime don't behave as expected)
• Lots of "hidden" capability that is poorly documented (or not at all) or has a UI that is poorly implemented (e.g. adding and adjusting colliders)

How can we make it BETTER?

• Better particle-specific profiling info (min/max/current particle counts, overdraw values, etc.)
• Easily scalable effects by platform (e.g. mobile vs. desktop effects; different shaders, different emission limits, etc.)
• Independent X/Y size control (both initial and over lifetime) for squash/stretch type effects
• Better initial direction control (e.g. on box or mesh shapes, ability to specify emission angle(s) direction)
• Some kind of per-particle pivot support, mostly for offset rotation effects (e.g. orbits)
• Much broader color control (e.g. each particle to be random from a set of multiple specific colors, not just random monochrome range between two colors)
• More controls like ____ by speed (e.g. ____ by distance from emitter, location in range, etc.)
• Ability to specify initial angular velocity
• Scaling the entire effect
• Velocity over lifetime, limit velocity over lifetime force over lifetime don’t play well together, don’t behave as expected
  
  E.g: Emitter from mesh (plane, set to vertex); adding force on X (world space) effects particles as expected; adding velocity limits (world space) velocity over lifetime (world space) each have totally unexpected results; X on each of these don’t effect the expected direction​
• Velocity over lifetime just doesn’t make sense; shouldn’t this be absolute? If my curve sets all three axes to 0.0, shouldn’t the particles stop?
• Ability to enable just a single axis of velocity/limit velocity over lifetime
• Clicking a curve to toggle it between gray and color doesn’t seem to do anything other than hide it on the curve window
• New 2D Sprite integration as particles (for animations, etc) instead of texture sheet animation

 

Robert Cummings of Simian Squared Ltd

Currently, it's a 2.5D game for PS4 and Vita.

We need 2D particles, in some rare cases, but a shader override trivialises this issue.

I like that it's generally fast.

It's too far left field. IMHO it's actually a failed concept. Sometimes concepts do fail, and this IMHO is one of them. It's simple to use but far too limiting in practise without scripting support. Particles are about as far from scripting as you really want to get.

1. I can't set particles[] cell image. I want to - for example debris or blood, or items. Using it as a general purpose rough and ready fast (think thousand) object system gives it other uses.

2. I frankly think some of the terms used are confusing.

3. I found it impossible to make eddying fire embers the way I wanted them, it seems limiting in comparison to legacy.

1. Give it pure GPU support with optional depth collisions for speed (if necessary). I'd like that to work on mac and all consoles not just DX11.

2. proper collider support vs layers in 2D and 3D. Or optionally depth particles if going via GPU.

3. Need more scripting power.

4. Need proper native tools like attractors and gravity fields. Need a behaviour list or similar.

5. It just seems to be the odd man out design wise overall. An overhaul of this might help.

 

For me the main thing is having the same access in script at runtime that a designer has in the modules in the Editor. Not having this breaks designer-coder workflows, and leads to potentially having to reinvent wheels just to achieve stuff that's already 99% there in the back end.

Also, I'll be honest on my feelings about this one: the culling bug is silly and should have been fixed long ago, I can't fathom why it's still there. We've got live projects where we've had to hack around it, making transforms follow the camera frustum so that large particle effects don't go missing.

Also, let us write custom effectors/modules. I know we can do this by getting/setting the whole particle array, but I'd assume that whatever you do internally is more efficient than that and this stuff is all about speed... Having said that, I realise that these are probably written in native land, so it might not be that easy. (Though I'd not at all be opposed to having to write them as native plugins if that's what's required.)

 

Who are you?
Visual effects artist for Eight Pixels Square

What kind of game are you trying to build or would like to build?
3rd person action shooters
https://www.google.co.uk/search?q=l...pm4KQCA&ved=0CEQQsAQ&biw=1900&bih=965&dpr=0.9

How does particles fit into that? What use-cases do you have?
gun fire, explosions destruction and UI

What are the GOOD things about the particle system now you like?
Once the basic understanding of the particle system was in place it becomes quick to get results you know can be achieved, the module system works well, and keeps things optimised automatically. the editor works well, with the ability to edit multiple system at once. Using curves to control particle values works well, and with lerp between 2 curves a lot of versatility is available

What are the BAD things about the particle system now you dislike?
- to able to scale systems seems like a very popular option, this would be very useful, especially if particles are to be used to mobile UI's.

- To be able to control rotation in 3 axis, this is especially important when emitting non-sprite particles, such as meshes. I used a particle system to animate background cars on lawless. it worked, but took a bit of clever thinking in order to get the result i wanted.

- Non uniform scale of sprites,there is too much wasted overdrawn on sprites that only need a small section drawn as i can't stretch the sprite instead.

- Allow any gameobject to be emitted as a particle.

- i currently often write shaders that use the particle color to control vertex colour values, it would be useful as mention in a previous message, to have a additional particle value stream to input into the shader. this would mean the particle color stream could be retained as color, and the new stream to control shader values.

- Fix the rotation based on velocity. when making debris particle systems with a collision plane, i tried to use rotation based on speed so that the debris spins when in flight and stops when the debris is stationary on the floor, instead the debris continues to spin even when static.

-inherit percentage of parents movement - this isn't the same as inherit velocity. the velocity is unaffected, rather at 100% inherit, the particles would move the same as local space, at 0% they would move like world space. and 50% would be between the 2. this more useful than inherited velocity for things such as effects based on characters feet. this would be useful to define what object to receive the movement from.

- Allow for more controls for all modules - example would be to drive the animation frame of the sprite by the speed of the particle. this is useful to fake motion blur of particles, such as sparks. more of these type of controls allow for more inventive results.

- frame blend of animation textures, this would result in less frames required.

- to be able to specify and update at runtime which collision plane to use, i want to be able to use simply planes for mobile performance for things such as gun fire hit effects. the environments change as so i need to be able to change the collision plane used on global gun effects.

-MOST OF ALL expose all of the system to allow for custom modules/ scripting on the particles. with this i sure most of my previous requests could be catered for in house, or via the asset store.

 

Who are you?
Freelance game asset developer (programmer)

What kind of game are you trying to build or would like to build?
A multiplayer survival combat game

How does particles fit into that? What use-cases do you have?
Mainly impacts, some explosions
Use cases include blood impacts, bullet impacts on various surfaces, muzzle flashes

What are the GOOD things about the particle system now you like?
It's easy to get something up and running, and there typically isn't much you have to go into code to do (at least in my use cases).

What are the BAD things about the particle system now you dislike?
The complete inability to dynamically scale a pre-created particle system (like those on the asset store). I started working on implementing the hit impact particles etc for my game very recently, and I was very shocked to find out that there is no easy way to just 'scale down' a particle system, I had to manually change the location of each transform in each prefab, and either manually go through each renderer and set the scale, or do it at runtime.

How can we make it BETTER?
Add scalability!

 

We've given the particle system docs a minor makeover for 4.5 but there is a lot more stuff already in production.

 

Who are you?
A game developer at a small company in Tokyo. We're making a music game and we're using particles for a lot of decoration on each song. We want to reuse the particle systems as much as possible, and be able to reskin them, resize them, generally mess around with them programmatically. To manually create versions of each particle system for each material/mesh combination or each shape would be impossible.

What are the GOOD things about the particle system now you like?
It seems like a lot is possible? Maybe?

What are the BAD things about the particle system now you dislike?
The programmatic interface doesn't match the UI at all. Artists see a tonne of options and want me to set things up to access them programmatically, but the controls aren't exposed so I can't help them. The API itself is incredibly empty.

The particle system doesn't scale with the parent node. This makes re-using the same particle in different situations basically impossible. I've written a script to hack the starting size based on the parent's world scale but it doesn't really work.
I'm sure there's more but those two are the main ones that have driven me insane.

How can we make it BETTER?
Think about programmers first, and UI users second. If you cover the former, and the latter isn't fully-featured, the programmers can always add the UI you lack. If you do it the other way round, we're screwed.

 

I would like to start emmition by zero when I checked [prewarm] and selected [Distance] in Emmision.

 

I'm Asvarduil, a one-man-band who creates a variety of different games (see signature).

As above, I make all kinds - I've done a shoot-'em-up, RTS, and sidescrolling swordfighter. My next project is a JRPG, when I find time again.

Particles are used for a very wide variety of special effects. In my earlier games they didn't see much use as I didn't really know what I was doing all that much. While I know slightly more now, I still tend to be very careful, as I want my games to run smoothly on a wide variety of hardware, particularly legacy hardware - the rank-and-file gamer dosen't upgrade their systems as often as we tech-nerds do!

High Level Use Cases
Performance - I expect my users to be running older hardware, by at least 2 to 5 years. My development environment is a now-obsolete slimline PC, actually, specifically so that when testing my games, I can be sure that the performance will be sufficient.
Adaptable - I need a robust API to handle how I use particles. While things like being able to tell an emitter to fire a one-shot burst, or to tell an emitter to self-destruct it and its gameobject the next time all of its child particles are dead are nice, the ability to tell the system how to tint particles would be helpful. The ability to tell the particles where to start and how to flow is helpful (this is an interesting one - see below, in my concrete use cases section.)

Concrete Use Cases
Black Hole - In The Hero's Journey, a dummied out dungeon had singularities that were used to warp all over the place (presumably while the castle's boss was chasing you.) Shuriken could not implement a 'black hole' effect, so I had to revert to legacy particles.

A black hole effect has two main pieces:
1 - The particles start at a distance from the center/event horizon.
2 - The particles move towards the event horizon.

Shuriken in its current state can do neither of these two things, to my knowledge. In the legacy particle system, using a negative Z angular velocity (I'm at work, it could be another setting...) allows the motion towards the event horizon. In the legacy particle system, I was able to set the sphere that particles were generated within to create particles on the shell of the sphere.

Cutting Effect - One of the things holding me back on my JRPG project, is creating a good sword-cut effect. Shuriken particles move independently of their emitter; Legacy particles move with their emitter. Thus, by moving my legacy emitter, and careful attention to how I create and tint my particles, I can create a (reasonably) believable sword strike visual effect. I just can't do this with Shuriken.

Similarly, exhaust trails are better done in Legacy than Shuriken. Everything I said about the particle source moving also applies to rotation; in a brief experiment I did on my old SHMUP project, I gave the player fighter an exhaust trail. When I rotated, at some points my exhaust that should have been coming out of the engine nacelles was going back into the ship. Apparently, Shuriken particles only change their emit direction if you tell them to. Frankly, I've got bigger concerns in my projects than writing code to tell particles which way to go.

I love the UI; it allows easy access of the options that Shuriken does provide. The ability to edit various particle curves (size, tint, etc.) is particularly great and allows me to make some great effects.

Pretty much, everything else. Beyond the UI, there is nothing Shuriken does, that Legacy particles don't do better (and, I'm talking better in general. I ran The Hero's Journey at the point in development when I was switching from Shuriken to Legacy, and I noticed an (erratic) 5-15 FPS drop when I switched away from Shuriken, to Legacy. Part of it may or may not be my hardware, but it wound up helping some. I also realize I could have wrung more out of the game by doing some other things a bit differently, but that's not relevant to the particle system topic we're on here.

Rework the legacy particles to have a better UI, and call it Shuriken. Expose more parts of the API, so that we can programmatically customize as needed.

 

Who are you?
VFX artist, 3d artist, developer

What kind of game are you trying to build or would like to build?
Scifi 2.5D platformer with visuals aiming on the high end side





How does particles fit into that? What use-cases do you have?
They're a big part of getting the environment to be realistic and believable. Everything from sparks to explosions to smoke to fire, dust floating in the air, gas vents, etc. I've spent a LOT of time with shuriken.

What are the GOOD things about the particle system now you like?

-Really flexible, clean, and professional UI. Feels like it's own tool.
-Wind zones are fantastic, I've gotten really cool and realistic effects like when there's an explosion near a vent and the smoke getting sucked in
-Having particles that can emit particles is awesome
-There's more stuff, overall I'm pretty happy with it

What are the BAD things about the particle system now you dislike?
-There's not a whole lot that I actively dislike, at least not off the top of my head.
-Limitations when it comes to scripting I suppose, although it honestly hasn't been much of a problem for the stuff I've been doing.


How to make it better:

-This is probably shader related, but with some particles (even if you're using a soft particle shader), you sometimes get "popping" between particles. Like if you have a particle that's behind another one and it goes in front of it, its sort of just all of a sudden is there, rather than having some sort of blending. Messing around with the sorting fudge, normal direction, billboarding type, etc can help but there are still times when it happens no matter how much you play with the settings
My main use in this case is for realistic smoke effects using large numbers of smoke particles. It's mostly notable when you use multiple particle systems in the same space, even if they're using the same materials/textures.

-Ability to use multiple materials in the same particle system. Have shuriken randomly (or based on user input) choose between different materials for each particle, rather than having to have multiple particle systems. Having to have multiple particle systems just to have variations of the same type of particle isn't too practical and you also run into the problem above. This feature would be useful for everything from having variations in smoke/fire sprites to make it more believable, to using shuriken to have particles with textures of garbage (paper, leaves, etc) blowing in the wind.

-ability to use actual meshes/gameObjects as particles (rather than only sprites/billboards). This would be great for being able to use particle systems for stuff like weapon projectiles, or having explosions with debris and stuff like that where billboard objects don't cut it. VFX tools like Element3D and Thinking Particles are great examples of what you can do with that.

-This is also probably shader related, but I really want to be able to have a particle system of say smoke being able to have realistic shadows. The problem is you can't really do that with soft particles, it needs to be a cutout shader (looks bad with smoke obviously) or skip having shadows entirely.

-ability to have particles with unlimited lifetime that can simply be there forever. For example, maybe you want fire particles using sprites to just stay there forever, rather than eventually dying and reappearing (That said this feature might already be in and I just can't remember it)

-Autodestruct / one shot features! Bring them back! They were really useful in the legacy system and while it's not particularly hard to program, it's something I'd like to have back.

-The ability to specify the particle's collision box size/offset.This is an important one. There have been a number of cases where I might have a smoke particle or fire or something like that which is set to disappear when it collides with something. That works great, the problem is I might want it to intersect the object a bit before disappearing. One use case is a flamethrower -- shoot a wall and depending on the texture, the fire disappears before it even touches the wall (because of the transparent space around the particle/texture).

-The ability to make the particle be spawned and accept collisions but not be visible for a short time. Yes you can do this with some shaders by adjusting the color over life but this doesn't work with some other shaders. So the ability to basically keep the particle invisible for a set time would be useful (especially when using stretched particles).

-Another thing that would be useful would be the ability to reorder where all the different modules are, drag/drop them up/down. This way we can have only the ones being used be at the top and the rest at the bottom (or whatever order we want). Or maybe have them be color coded rather than just checkboxes so it's easier/faster to scan through and find the relevant ones.

-Ability to rotate particles on all axes. Currently, you can only rotate particles left or right relative to the camera but it would be nice if we could rotate them in any direction

-This is more of a general feature request but having shuriken support for more big features would be nice. Being able to do fire/smoke simulations like DX11 fluidity on the asset store, or millions of bright glowy gpu particles like TC Particles. I remember a while back there was a Unity blog post with an experimental feature (I don't think it was DX11 though) where I think the particles could collide with eachother (so you could have mist that gets pushed away and stuff like that). Lets see some of that stuff!

-Ability to set exposure times for particles. Basically this would allow you have particles that leave trails like this. But it's also great for small particles like embers and stuff like that which maybe move really fast and you want the particles to look stretched or bent (you can use stretch factor but then your previously round particle becomes pointy and there's no bending). Trapcode Particular 2.2 has this feature:


-Ability to scale whole particle systems. Being able to stretch/squash particles would be nice too.

-Ability for individual particles to have audio sources attached. If there's an explosion or something, it'd be cool if the sparks and debris could emit whizzing sound effects and stuff stuff like that as they fly near the camera.

-There have also been some cases where I took big performance hits from using particle systems that probably shouldn't have happened. In some cases it seemed like they should have been culled but weren't, things like that. I haven't investigated the problem enough to reproduce them though so for now that's on standby

-Perhaps a separate window for viewing the particle system while you edit, similar to when you're setting up a mecanim humanoid. This way you don't necessarily have to have a scene open and do the editing directly in the scene (or you could have the two open at the same time).

 

Who are you?
Single game developer hobbyist (i.e. I'm the only one working on my game)

What kind of game are you trying to build or would like to build?
I've been building an RTS for approximately 2 years now using Unity

How does particles fit into that? What use-cases do you have?
Currently I'm using particles and particle systems for blood effects when each unit dies and to show dust/smoke/light explosions whenever a building gets destroyed in the game.

What are the GOOD things about the particle system now you like?
Without too much experience with particles yet, I like being able to have decent effects that can be constructed relatively quickly.

What are the BAD things about the particle system now you dislike?
Particles seem to slow down my game a lot. So, performance seems to be bad with the particle system. As a previous poster mentioned, it looks like I cannot scale a particle system. I'd like to be able to simply make an entire particle system look the exact same, but simply bigger. Also, whenever I add or change anything related to particles or the particle system, for some reason my units can't move in my game (in the editor) unless I start and stop the game twice. The particle system just seems to do really weird things like that -- having to run the game once in the editor before my units will use the pathfinding or before the game runs like it usually does etc...

How can we make it BETTER?
My number one wish would be that the performance of the particle system be as good as possible. I want performance. Lots of particles for as little performance cost as possible. I know that's probably difficult, but that's what I would wish for Because I'm building an RTS game, my game tends to be heavily CPU bound right now. Just throwing that out there. Also, I'd like to be able to scale a particle system up -- and hopefully keep the same visual fidelity or close to it.

 

Hello I'm a 3d artist at a subsidiary of an established developer with several smaller titles in my track record. My background is mostly UDK and Unity (roughly 3 years) but also inhouse engine technology.
Most of my workday can be described as modeling, texturing, placing level objects/environments, writing shaders (now with the help of ShaderForge the fun came back as in the days of UDK), guiding team mates etc.
Doing particle systems is part of my job - though not very often.

Currently we are doing a manager game - typically aiming at the German market.
Before that I've been working on a racing game and an online jet fighter game.

Some of the particle systems we/I had to create in the past:

• Bow and stern wakes of ships
• Dust and splash hit effects from machine gun fire
• Nozzle effects
• Explosions
• Smoke (from teapot to industry chimney, from cigarette to wild fire - and did I mention explosions?)
• many more... and more to come

Most of these particle systems had to react to user input - either be spawned on an event, destroyed when that event finished or they had to be driven by certain player behaviour: say if his car speed increased the smoke had to become more intense.
So scripting was always a part of these systems.

Shuriken's strengths are its modules that you can enable/disable based on what you really need. Overall the GUI feels easy to use.
Also the absence of any abbreviations and crude exposed internal variable names is a good thing - Cascade (speaking about UDK) had some very strange names... all upper-case and underscore, very programmer like.
With Shuriken you can easily grasp the meaning of a variable. In Cascade you had to look up on many of them in the docs.

• Not all internal variables seem to be exposed in the API.
• What I dislike about Shuriken is its inconsistency with how you can alter variables over time.
  For some there is a way to let the system chose between two curves. For others there's only a random between values.
• I really miss scaling a particle system and getting meaningful behaviour from the result of that. See UDK for example. In a low budget production you really don't want to make 5 different sized smoke systems for your 5 ship types. You make one gorgeous looking system and scale it to fit the other ship classes.
• Not enough inbuilt shaders - normal mapped and lit particles + soft edge fading.
• In-editor particle animation is limited to the currently selected system - often times though you have multiple systems combined in a hierarchy and need to evaluate them all at once when tweaking the parameters of a single child system.

• Expose more/all variables to the API. Include GUI functions to quickly create custom modules with full functionality available to them.
• Try to make the user experience the same with as many parameters as possible. If there's a ramdom between curves on speed for instance please consider adding that to color as well.
• yeah well - make particle systems scaleable
• include more shaders. And please consider working together with Joachim from Shader Forge to make editing particle shaders a breeze for us artists.
• More WYSIWYG - when clicking on the top most particle system or gameobject give us the option to playback all sub particle systems at once so tweaking of sub systems can be done in relation to whats happening to the other systems.
• Please mimick UDK's dynamic parameters. Inject a second layer of vertex information into the particle mesh (different from vertex colors) so we can send particle information directly into our materials. Currently I am faking this by looking up the color over lifetime from a ramp texture. Leaves me 3 vertex color channels to pass other lifetime based values into the material... but that is hacky and a workaround.

Thx for reading. I surely missed some stuff.

 

Who are you?

Artist and combat guy at two man company; I do ALL of our effects.

What kind of game are you trying to build or would like to build?

Currently building a highly technical beat 'em up.

How does particles fit into that? What use-cases do you have?

There is a constant stream of fast-paced weapon and impact effects throughout our core gameplay segments.

What are the GOOD things about the particle system now you like?

I can make just about any effect I can think of. I enjoy using shuriken.

What are the BAD things about the particle system now you dislike?

There is one ANCIENT bug that has actually existed since...2007? Earlier? I originally encountered it in legacy but it has persisted. Horizontal billboards have a tendency to randomly explode in size to absurd proportions when in certain proximity to the camera. It's 100% noticeable by the player, looks awful, is unmistakably a bug, and is, again, ancient. I've tried to raise awareness of this for years but with no luck. I would LOVE LOVE LOVE for this to finally be fixed since we use so many billboards and always have. This bug is wrecking the oculus rift version of our game; it becomes unplayable randomly when tiny blood splatters on the ground suddenly become x1000 times bigger and the player can't see anything.

How can we make it BETTER?

I used to be able to do this thing in legacy where I could take a billboard system and orient it within the object hierarchy however I wanted, and it would not only preview in that orientation, but instantiate as well. This was always super crazy useful but it disappeared in shuriken.

It would also be nice to have some damping functionality like I had in legacy. I've heard people say it can be done in shuriken but I've built thousands of effects in shuriken and have never figured it out.

 

Small indie studio working on our first (2D) game

It's a 2D sidescrolling action RPG

Many of our weapons, attacks, armor, enemies, etc - just about all game objects can potentially give off effects.

2D Collision support. It would add a lot of value to our environments, and attacks if their particles collided with the 2D physics components