[Official] Particle System [Shuriken] Improvements

I've spent a great deal of time with Shuriken recently in the last week since my previous post and would like to retract my comments. Here's my new findings:

Wishlist:
1. It could use some form of performance boost - especially with meshes.
2. Any form of gpu acceleration would be nice (if that actually makes sense - I guess by offloading from CPU)
3. I'd love attractors/repellors/gravity/spacewarp objects
4. more scripting access (just open everything up would be nice)
5. 2D support?

Things I struggled with:
1. It wasn't clearly documented that playing the parent would play the child, and having it not connected but still a child meant it would play at the same time yet not emit at the rate of the parent. This is good behaviour, but it needs better docs regarding the neat hidden features.
2. The orientation seems borked at the best of times. I didn't really like it's default orientations for 2.5D titles.
3. I seem unable to give them a proper noise during their paths, I'd like to make whimsical behaviour such as embers, snowflakes and leaves in wind act a bit better.

Overall, I do like shuriken, it's a strange beast and generally needs better performance and a more open API with better documentation

I wasn't even aware of wind zones.

 

Who are you?

I am a hobbyist developer doing this on my spare time. One man army. My background is primarily CG and writing.

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

I am making a fighting game.

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

I am using particles to create a bevy of effects such as smoke to blood spewing out of someone's face.

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

I haven't fuly utilised it enough to make an opinion, but I like that it is easy to setup and place in scenes.

What are the BAD things about the particle system now you dislike?
For me, it is the lack of tutorials on how to use it.

How can we make it BETTER?

From what I have seen, the particles can be opened up a bit to do effects like vicosity, shadow casting and self shadowing, especially for smoke effects. I would also love to see a physics set for things like fire, rain, and spawning without having to script it. For luminous effects like fire, especially with Enlighten on the horizon, I would love to see it emit lights without having to place a point light in it.

 

(You know who I am - 11 year game-industry vet, with two concurrent PRO licenses for my pro serious game development and indie personal projects with 3+ years of Unity.)

Requests for Shuriken
* Per-Axis Control over Emission - ex, restrict to a small XY plane arc, with 0 in the Z direction. Including initial placement, initial velocity, forces, etc...
* Support/integration with new 2D system.
* Full API support for ALL features/systems in the editor

Gigi

 

Who are you?
An FX artist since early 2k's, animator before that.

What kind of game are you trying to build?
RTS currently.

How does particles fit into that?
Combat, Environments, Abilities, etc.

What are the GOOD things about the particle system now you like?
It's a basic, simple to grasp tool that can put out a fair amount of particles.

How can we make it BETTER?

There are great improvements already listed, such as

• More access to the API code
• Allow any gameobject to be emitted
• Scaling of the whole particle system
• Shadowing and self-shadowing particle shader support
• XYZ billboard and mesh rotation controls
• More Profiler debug tools would be handy
• A forces module with attractors, flocking turbulence, etc.

I’d add:

Sorting issues! Particles sorted in prefabs have popping z-fighting issues and Sorting Fudge doesn't appear to fix this. It looks like Shuriken is using the emitted volumes to compute the sort depth. Can we add an option to use the Transform.position of the object? Or force the sort based on the hierarchy?

More variance support (curves, etc.) on everything: Duration, Start Delay, Gravity, Shape (Angle, Radius), Stretched Billboard Scales, and External Forces etc. More options are a good thing!

Can you move some Wind Zones parameters into the Particle System as a Module to allow curves and easier animation?

Multi-selectable modules/components. It’s a minor annoyance, but if we want to change multiple particle systems with the same value in say... Emission, we should be able to multi-select the Particle Systems and change the setting once, changing all of them, instead of having to open and repeat in each one. Less clicks means faster iteration.


Thanks for asking for input!

 

Having done some more particle work recently, I have another feature/module to request which is Relative Force Over Lifetime. Which is to say, to apply a force (or acceleration, or velocity) relative to the velocity of the particle. This would make swirling behaviour very easy to create, as well as explosions and implosions. It could also be done by adding extra options in the "Space" dropdown as well as local and world. This could work either as relative local, where x is the forward direction of the particle, and z is at right angles in the plane created by the velocity vector and the local z axis, or relative world, where z is in the plane of the velocity and the world z axis.

 

-Higher API code exposition [let me access anything in code no matter how useless doing that would be].
-Better support for volumetric effects and their integration with external DCC tools.

 

Hi everyone,
Thanks for all the input, posting a summary here. Let me know if I missed anything. This list doesn't mean it will be implemented, just capturing the feedback for internal discussion.

No particular order:

• Ability to scale a whole ParticleSystem
• Direct way to destroy the particle system by code
• Expose every property of the particle system to code
• Allow billboards to work with lighting
• Culling bounds should include all particles in system
• Better presets
• Ability to profile particle systems to understand performance bottlenecks
• Improve overall performance
• Ability for particles to follow a spline/path
• Ability to easily pass variables/values to shaders for the particle system
• Values can be per particle, not per system
• Independent time scale so particles can be used when time scale is 0
• Negative: forces, emission speed
• Ability to simulate backwards (implosions)
• Additional emission shapes
• Emission from skinned meshes
• Attractors/repellers/turbulence
• Mesh/GameObject particles
• Emit particles in a non randomized way to be able to make patterns
• Callback or event to emit particles
• Ability to control particle axis and center of rotation
• Sorting layer in inspector
• More advanced shaders that support lighting, effects
• Better prewarm options to setup and simulate particle system at start
• Ability to specify the particle's collision box size/offset
• Audio sources linked to particles
• Playback in editor allows to play all child systems too so the entire effect can be seen
• Inject a second layer of vertex information for use by shaders
• 2D collision support
• Ability for particles to cast shadows
• Better sorting of particles to prevent popping
• Autodestruct
• Ability to set particle exposure times (allowing for particle streaks)
• Inter-particle collisions

 

Also:
-Autodestruct
-Ability to set particle exposure times (allowing for particle streaks)
-Inter-particle collisions

 

Okay, added to list (edited).

 

Not suggesting this, but more curious. Could you fake particle streaks with a fullscreen image effect that controls exposure on a particle layer and then use the depth buffer to make sure the particles are properly occluded?

 

Looks like you've picked up most of the issues, thanks for asking!

Does this include my point on forces relative to particle velocity? (Over lifetime/with speed) Or as an axis option for the modules in general.

also:

should include texture-based/UV-based emission (ie. emission maps?)

 

Cool, thanks!

I thought about that...It could partially work, but I'm not sure how well it would work if you wanted to have a 3d camera moving around. With a post effect, I'm guessing it would sort of smudge along the screen, whereas what I'm talking about would be more like a 3d effect

There's an example in the video here (at 0:14 - 0:17)
http://www.redgiant.com/products/all/trapcode-particular/

 

Oh, yeah, I know what you mean, I've just been trying to tackle similar problems with Unity's limited particle system as it is.

 

Ability to move all the Legacy things to Shruken.


There are so many things on the Asset store that are legacy-only and very slow. If Unity can re-engineer the back-end so that Legacy becomes Shruken, that would be good idea.

 

Programmer of a small company

not games, we usually make real time visual effect for DJ and interactive stuff for promotion/advertisement

I don't want to cache pictures so i randomly grab pictures from Google.

We use Particle system to do some visual effect like this. Because it's not an usual way to use ParticleSystem, I think you may want to know it.

For the first example we use ParticleSystem to render meshes (with animation). I haven't tested it but i pretty sure it has better performance than doing it with individual GameObjects (especially when they have to be in different colour).

For the second one, we use ParticleSystem to do the spawning and animating. I code a component to read particles data and render the lines. Of course I can write everything without the ParticleSystem but I think it's easier for designer to use. It's just a small experimental thing, we don't want to make an editor just for this component.

It's very easy to use in editor and able to arrange lots of tiny detail.

There are many feature we cannot control in script

To improve the Mesh Render Mode:
1. a Quaternion rotation (it's painful to use axisOfRotation/rotation to do the above effect)
2. a Vector3 scale
Something probably extend the use of ParticleSystem but I am not sure:
3. a place to store extra data in particle
4. a better way to control the frame of sprite animation

 

Just wanted to +1 SunnyChow's post, toward the end: being able to set up various Quaternion rotations is essential for mesh particles. I've had to really super fake scaling tricks to get anything decent out of it before. i.e. a bunch of "shards" exploding out from a point, all pointing outward from an epicenter; it's very hard to do this (actually I still don't think I've figured it out).

Some kind of "look at" handle for the meshes? and optional "up" handle use on that? Sometimes you might want the rotation around the look axis to start randomly.

Short of that, just more access to individual particle settings. Maybe some kind of "void OnSpawn(Particle part){}" where you can set up your own orientations based on code any time there's an emission of a particle? (Just spitballing, here)

 

Please add features from the Legacy system that are still missing. I use Systematic extensively, so I have to use Legacy.

 

Trying to do some stuff with manual particles now for efficiency. Can we please get a particleSystem.SetParticles() call that doesn't allocate craploads of memory? This allocates 126KB *per frame* with 3600 particles. That allocation goes away when I comment away the last line:

Code (csharp):

1.  
2.     void Update()
3.     {
4.         int length = particleSystem.GetParticles(particles);
5.  
6.         for (int i = 0; i < length; i++)
7.         {
8.             var data = Grid.use.allData[i];
9.             particles[i].color = Color.Lerp(Color.white, Color.red, data.GetEnergy(EnergyType.Random) / 100f);
10.             particles[i].lifetime = 10f;
11.         }
12.  
13.         particleSystem.SetParticles(particles, length);
14.     }
15.  

Every frame:



And then every half second or so:


Pretty much makes it impossible to do your own particle behaviors, unless I'm missing something here...?

 

Hi all,

I'm an indie developer working on a turn based strategy game for the PC.

Forgive me for beating a dead horse, but exposing all shuriken attributes in the editor (including curve keys) really is critical for me. I was using the SerializedObject workaround (link) but apparently this doesn't work anymore when you try to build (works when testing in the editor). Recreating what I've done with Shuriken in the legacy system is too costly to be practical, so this is really a roadblock. As a quick alternative, allowing the use of SerializedObject from within the UnityEngine namespace would be sufficient.

Many thanks, I love Unity!

 

GPU particles as an option for supporting hardware, ideally the PhysX particle system available in PhysX 3.3.

A trail particle in shuriken.

 

Will Shuriken particles work with the new GUI? Haven't seen any reference to that anywhere.
Gigi

 

I'm a solo developer. I have been developing a 2.5 D explosive action game. My game uses a TON of explosions. Blood splatters and sparks are also very common. The bad thing about shuriken is the lack of features. I cant do as many things as I can in other engines. Its also very slow and looks ugly. The good thing is that you can quickly create basic effects.

To improve:
~Particle displacement
~Performance
~Audio per particle
~Refraction for each particle
~Lights per particle
~2D particle ray cast support
~GPU acceleration (I don't want to spend time programming my own)
~Particle stretching
~MORE SCRIPTING PARAMETERS
~Dynamic particle shadow casting / receiving (would look awesome with unity's Enlighten)

 

Hi
Can i talk about Trail Renderer && Line Renderer in this topic?

 

Ah, thanks superpig. I incorrectly assumed that the Unity folks hadn't exposed SerializedObject as a deterrent against poor practices. I can afford to wait for a while on this, so I've benched the feature for now. I'm sure it will be fine when the other parameters are exposed.

 

No. Not unless it's particle trails

 

More suggestions if you're still reading.

I'm having a lot of bother trying to get Shuriken particles lit by my shaders by vertex lights, would be nice for a solution here or a better way to define the normals. In a 2.5D game, the normals are generally just wrong for my view.

 

I'll say that if nothing else, I should be able to access EVERY particle component which can be set in the inspector in code as well.

For example I can change force effects on a particle system from the ui, but I can't access force for each individual particle from code(not even for the entire system..!). And similarly I can set texture sheet animations via the ui, but good luck accessing this from code (which is infuriating). I could do a lot of creative applications with access to individual particle sheet frames.

A second very welcome feature would be an overall performance improvement. Particle rendering performance in general is quite slow, at least when you need systems with more than just a few hundred particles in them...Automatic view culling, optional dx11 offloading etc. would be great.

And a third welcome feature would be an overhaul on how code access works. I don't want to have to loop through an entire particle system and reassign every particle just in order to access and change 1 particle. This seems very inefficient, and I would love to be able to grab one particle, change it's values and just reassign the changed particle to the stack.

 

Hi, I'm a solo game dev and also the VFX guy for DeadMage. Working on various games, 3D SideScroller, Fantasy RPG, 2D and...
Almost All I wanted to say has been mentioned already, but I wanted to really +1 posts #37 and #40.
There are 2 things I really want though:
1- NON-UNIFORM scaling of particles, that is stretching the particles in X/Y. I wonder why it's not being mentioned that much, only saw it once. This can help with MANY effects!
2- +1 to a really good scripting access, with that people can do whatever they want.

Thanks.

 

Who are you?
VFX Artist in a company with +-30 people in the team.

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

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

• Fantasy, Sci-Fi, technical, abstract,realistic war themed effects
• Environments, the four elements in general like leaves in wind, water splashes

What are the GOOD things about the particle system now you like?
I use Shuriken every day and I am very happy with it.
I like especially: Module based workflow, Curves, Show all/selected(but set to "selected" seems to be broken), "Emit from" options of the cone emitter

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

• Creating effects with a strong technical mood is difficult, requires a non chaos-based approach, see user "funshark"

• Color pickers are not very precise

How can we make it BETTER?

• Color pickers:
  • Resizeable like Gradient Editor for precise sliding
  • Color wheel

• More Rotation options(xyz) for "Start Rotation" and "Rotation over lifetime" especially with emitted meshes
• Gradient Maps to control custom shaders parameter
• More Shaders:…
  • Dissolve/Alpha Cut
  • Distortion like Heat

• Forces: Attractors, Splines
• Mesh Emitter as volume
• Particle View:
  • sort by name not creation date
  • Drag value increments are always too big. Preferences needs adustable steps for default, Alt, Ctrl

• Curves: switch behavior between default and Anim-Editor
• Curves for Inherit Vel. And Gravity Multiplier
• Import Collision meshes/use gameobject with meshfilter as collision

• Orientation of sub-emitters emitter

• Performance
• Adjust billboard aspect ratio
• Adjustable pivot, also outside of the billborad

• limit velocity over lifetime and * by speed doesn't work well together

• Lighting
• Can't get Cast/Receive Shadow to work
• Copy/paste single modules
• Rotation over lifetime seems to be rotation per second instead of lifetime

 

Who are you?
Hobbyist game developer with some 3D animation modelling experience.

What kind of game are you trying to build or would like to build?
2D Scrolling Shooter (R-Type, Gradius style game)

How does particles fit into that? What use-cases do you have?
I'm using particles for explosions and projectile attacks, as well as some other visual effects.

What are the GOOD things about the particle system now you like?
It's easy to use. I can typically get what I want from it.

What are the BAD things about the particle system now you dislike?
Bursts on particles are not random and in instances where the same particle effect prefab is used frequently this is somewhat noticeable. (I have a thread on the topic here.)

How can we make it BETTER?
More control over burst properties, with easier randomisation of their properties.

 

Who are you?
VFX Artist currently working at CreativeForge Games.

What kind of game are you trying to build or would like to build?
I am currently building Ancient Space game, 3d RTS game set in space (homeworld like)

and turn-based weird west tactical Hard West

How does particles fit into that? What use-cases do you have?
Cloud nebulas, explosions, clouds, mists, beam effects, special-ability effects, auras, projectiles, engine trails.

What are the GOOD things about the particle system now you like?
It is easy to set up and pretty straight-forward. It is easy to build a basic effect within minutes.

What are the BAD things about the particle system now you dislike?
Current particle system it not capable of generating complex, technical effects or very precise systems which for example follow a path. It it also not possible to create high-quality effects. I also don't like rare updates for Particle Systems- there are tons of reported bugs which are more than year old. Also, the way Shuriken randomizes things is actually not random at all. There are particles with "left" parameters spawned on on side of the system and with "right" parameters spawned on the right side. Explained in details here: http://effectronica.com/?p=866

How can we make it BETTER?
-every parameter should have "between two" option. Inherit velocity, gravity multiplier don't have that
-"Texture sheet animation" blending options should be added. Take a look at Unreal's Cascade where you have blending for in-between frames. This reduces the amount of frames you need to generate for smooth-looking effect
-lack of attractors of any sort such as gravitational pulls, wind, turbulence field etc.
-particles cannot drive shader parameters (take look at Unreal's cascade). It is not possible to create complex shader with dynamic parameter driven by particle lifetime, size, curve etc.
-can only emitt particles and meshes; support for lights, prefabs, gameobjects would be welcome
-limited number of subemitters. Let the user decide how many subemitters he needs
-lack of "macro uv" equivalent which is found inside Unreal Engine (read about macro uv here: http://udn.epicgames.com/Three/ParticleSystemReference.html ). It is extremely useful for adding textures shifting along every particle in the system
-culling issue is ASAP fix
-better build-in shaders such as shadow casters, shadow receivers, heat distortion
-GPU particles
-emitt from skinned mesh
-expose Shuriken to C#
-allow full randomization of Psystem

 

Who are you?
Ryan Gatts, independent game artist.

What kind of game are you trying to build or would like to build?
A minesweeper-style WW1 puzzle platformer where you have to find a safe path for your group through a minefield, losing as few members in doing so.

How does particles fit into that? What use-cases do you have?
We use particles for weather effects (rain, dust motes), for abstract lighting effects (fake god-rays), explosions, props (flies, background gunfire, smoke, fire), movement effects (dirt when jumping or digging).

What are the GOOD things about the particle system now you like?
I find a lot of sense in the way it is structured. I can make effects fairly quickly now, and I'm glad that I can access what properties I can through code.

What are the BAD things about the particle system now you dislike?
- The presets for some properties don't make sense. The default value for "length scale" in the stretched billboard render mode starts with a value of 1 which makes it so that particles will often spawn on the wrong side of the emitter (-1 represents the value that you will actually want to use most of the time). The Size by Speed and Rotation by Speed properties both have values that do not cause visible effects on the particle system when in their default values (inputting a constant into these properties doesn't make sense :/). Ditto color over lifetime (just start it with a fade-in/fade-out gradient).
-Additionally, the equation used for Limit Velocity over Lifetime does not match up well to real life drag effects; particles too quickly reach their terminal velocity.

How can we make it BETTER?
- Let me drive flipbooks by global time rather than lifetime values so that a looping effect can play 2 loops per second for however long the particle lives.
- Expose more properties to scripting (like flipbook frame #, emission rate, rotation, position/velocity of particles, external forces [custom per-particle force volumes would be an awesomely cool thing to script], emission shapes, etc.).
- Allow both emission over time and by distance on the same particle system (so that the effect looks consistent when moving and standing still!)
- Allow semi-arbitrary relations between particle system properties. Instead of having a "Size by Speed" section, just have a "size" section where I can set it to graph against speed or lifetime or rotation or whatever else by way of a dropdown list (similar to current implementation of picking between graphs, gradients, random constants, etc.).
- Optional Gaussian distribution for random numbers
- Make it easier to access world normal and world position values of particles in shaders (would allow lighting and fresnel effects -- maybe even some fake self-shadowing when particles are packed very densely).
- 3D rotations of randomly rotating meshes.
- Making custom emission shapes that have biasses (a cone-style emitter that shoots particles faster in the center) Maybe via a grayscale that can be mapped to different properties in the style mentioned above.
- Give a way of passing data out of shuriken into the shader other than the vertex color property (floats, colors, etc).
- Technical advancements like better sorting between different particle systems (especially if they're using the same material), post-emission turbulence, etc. are always welcome as well. Actually, anything that lets me controls particles after I've emitted them is A+ in my books (turbulence fields, point/spline/mesh attractors/repulsors, a more inclusive implementation of wind or custom script forces, etc).

Thanks for this

 

I am a technical and VFX artist who has worked on some AAA titles using Unreal and id tech 5. I currently use unity at a smaller studio and for my own projects.

Various kinds at the moment, predominantly a 3rd person adventure game with a heavy focus on aesthetics and Final Fantasy like visuals.

Everywhere from realistic atmospheric effects like fog and smoke to stylized magical effects.

The color over time gradient and curve editors are much better than what I have used in the past.
Sub emitter spawning is excellent.
Accessing the particles from script is nice. I have implemented many features this way.

I'll lump these two together.
The color is not high dynamic range. It wold be nice to have an over bright value.
Texture sheets do not blend between frames. This is frustrating when making animated smoke at low frame rates.
Have a height and width for billboards instead of just size, use these values for stretched billboards as well and have them animatable over time.
Add an option to offset a particles pivot point. This is useful if you want to have billboard particles point outwards, or have better control over "stretched" billboards. Necessary for high quality explosions.
Add access to some loose variables that just get passed into the shader that use the same curves and constants interface as everything else, like Unreal's dynamic parameter.
Add particle lighting, I have written some scripts that will light particles with a compute shader and it works pretty well but still not very convenient and it doesn't cover shadows for important things like sunlight.

Without changing the vertex data format for models I think most of this can be added. I would do it myself if I had the source code.
vertex.position = position of particle vertices
vertex.normal = normal of particle vertices, use model normals if spawning model particles
vertex.texcoord0 = the current frame of the texture sheet animation
vertex.texcoord1 = the next frame of the texture sheet animation
vertex.tangent.x = frame blending value
vertex.tangent.y = over bright value
vertex.tangent.z = free dynamic variable
vertex.tangent.w = free dynamic variable
vertex.color = particle color

If the normal w is free you could use that for frame blending and leave all 4 tangent values open for people to use however they saw fit. That would be the most flexible solution I think. We did this in id tech and the particle editor would show names for the values based on the shader you were using. The names for each value were written in the shader itself somewhere similar to where tags are written for Unity shaders.

Particle sorting is not easily solved and solutions like order independent translucency may be worse for some people than the original problem so I'm gonna leave that one alone.

 

I communicated some of this with you guys before, but I figured I'd repost here and add some additional information.

Who are you?
Josh Montoute, lead developer and head at Thinksquirrel. I work on extensions for the Asset Store. One of these is the leading fluid dynamics simulation for Unity, Fluvio.

What kind of game are you trying to build or would like to build?
We're currently working on a version 3 update for Fluvio, which integrates our fluid dynamics even more deeply with Shuriken as a custom module:


How does particles fit into that? What use-cases do you have?
The main use-case here is integrating fluid simulation into Shuriken effectively.

What are the GOOD things about the particle system now you like?
It's fairly optimized - Unity has no problem taking thousands of particles and batching them efficiently.

What are the BAD things about the particle system now you dislike?
I've been working extensively with Shuriken for Fluvio (our fluid dynamics package on the Asset Store) since 3.5 and time and time again, hit a few roadblocks.

Many, many features of Shuriken are inaccessible at runtime, yet these values can be tweaked at will while the particle system is running. It can be worked around in the editor using the SerializedProperty system, but there is pretty much no runtime access to a *lot* of modules. Out of everything here, I would prioritize this feature.

Even parameters that you guys may not want to have tweak able at runtime for performance reasons are inaccessible. I can't even tell if a particle system has collision enabled or not! With Fluvio we have to work around this by storing a bunch of variables, synchronizing them when in the editor, and shipping them with builds, just to figure out if a particle system was set up with collision or not.

There are some weird oddities also (I'll be reporting the following as bugs with test cases): Collision events don't work with ParticleSystem.Simulate (but collisions do), garbage allocation in the API on the C# side when dealing with SubEmitters, etc.

How can we make it BETTER?

2D collision - #1 requested feature we're getting from customers right now. We have to work around it by assigning 2D rigidbodies to each particle and updating positions manually. This is extremely wasteful, but there's no good alternative really. We also tried creating our own collision for 2D/3D, but that is

A) too slow using raycasts due to being limited to raycasting/testing on one thread when Shuriken's collision detection is much faster/multithreaded

B) way too much memory overhead if we take shapes from Unity and do our own broad phase, intersection tests and collision math. And still slower than just switching a scene to use PhysX, likely.

Particle ID - it would be great to have a frame-independent ID of a particle from emission to destruction. We have to use a pretty icky workaround here with Fluvio.

Individual particle access - being able to access single particles, or only some particles, can be very useful. Not so much in our case since we're doing fluid dynamics on everything, though.

Long term, consider supporting custom modules. We implemented Fluvio 3 as a custom Shuriken module (and also replaced the emitter module) in the editor to give a more consistent user experience. It took a lot of black-magic voodoo to make that happen. There's a lot of C# side editor code that went into the particle system that could be opened up a bit and hooked into from custom code.

Sorry for the rant, but it can be a bit frustrating to work with Shuriken when you *really* want to dig deeper into it. We've contemplated implementing our own particle system, but you guys have done a fantastic job with multithreading, 3D collision, culling, etc. so we've stuck with it. And there has been good progress here. Shuriken in 3.5 had quite a few bugs (not to mention plane collision only), and many issues were tackled and cleaned up during the 4.x cycle (hooray)! But please do consider some of these - even just API access to modules will go a *long* way here...

 

I know I'm a bit late to the party, but here goes?

Who are you?
Independent developer producing content for VRcade in Seattle.

What kind of game are you trying to build or would like to build?
Hard to explain, but basically an interactive display set in space.

How does particles fit into that? What use-cases do you have?
Currently trying to create the roiling surface of a small sun.

How can we make it BETTER?
Need to be able to orient billboards to the surface of a mesh emitter. Right now there are options for orienting towards the player, vertically, or horizontally, but nothing that takes into account the direction they are emitted from. I'm emitting swirling flame sprites from the vertices of a sphere and I need them to stay oriented to the vertex normal from which they are emitted, but there is no option for that. When the sprites face the camera, the edges cut through the sphere, ruining the illusion.

 

Oh, and another biggie while we're at it:
We need a number entry field in the particle curve editor for both value and time. Right now the only thing you can do is type in a number at the top of the vertical axis that scales the overall curve. This is nowhere near precise enough. The user needs to be able to select an individual control point and then enter numeric values for both value and time. Dragging the control point around and getting it to a precise location, especially when the vertical scale is quite large, is next to impossible (The animation editor has the same problem, but I take it that's someone else's responsibility.)

 

... and one more. I promise this will be my last

I could really use the ability to fade out mesh-rendered particles. I'm trying to simulate debris coming from asteroids that collide with each other. Currently I've got a lot of dust sprites, which fade just fine, but I've also got chunks that are particles set to the Mesh rendering mode with a texture on them. They look just fine, but the alpha channel of the "Color Over Lifetime" setting doesn't affect them, so instead of just fading out nicely at the end of their lifetimes, they suddenly pop off, which breaks the effect. I guess the material settings itself override all the color settings of the particle, which makes sense, but it does rather limit their usefulness.

 

Two more to add:

1. non-uniform scaling parameters per particle - think of strips of rain.
2. rotation values - please enable us to adjust them per axis

 

you can actually fix the problem you had with your meshes that don't fade out. You need to write a shader that will alphablend shade your geometry. That shader needs to take the vertex color alpha value and apply that to the alpha value for your fragment program. The particle color value is sent via the vertex color parameter in the shader, so you have to have a shader that's looking for that particular bit of info.

 

Has anyone asked for smart particles? In effect the particle emitter emits game objects.

 

Also more control over mesh rotations for mesh particles would be on the side of most cool, while we're still here.

 

Just found this thread. Not sure if it's still being watched, but:

Who are you?
Independent developer working on my second commercial Unity title (first title is in my sig).

What kind of game are you trying to build or would like to build?
Currently working on a 3D first-person exploration/simulation game.

How does particles fit into that? What use-cases do you have?
Right now, just using it for weather effects (currently working with snow).

What are the GOOD things about the particle system now you like?
Not sure, I only started working with Shuriken an hour or so ago (I had previously been using the legacy system).

What are the BAD things about the particle system now you dislike?
I was really surprised to find that so few properties are available for scripting at runtime, especially for a system that's been out for so long. This seems like a major oversight and makes the system a non-starter, as I want to be able to modify the weather at run-time through script. I just tried change the direction of some snow particles, which I had previously been doing via the worldVelocity property in the old system, but found that there's apparently no way to access the Force- or VelocityOverLifetime properties.

How can we make it BETTER?
Expose the system to the same level that other Unity components are exposed.

 

Who are you?
A 1 man team thats been developing for about 2 years

What kind of game?
At the moment, a top down shooter

How many particles?
Quite a few, for explosions and movement

How can we make it better?
2D collision support would be fantastic

 

Who are you?
Developer for a serious game company.

What kind of game are you trying to build or would like to build?
We build training software for emergency services. Instructors can design their own scenarios using the environments, items and logical building blocks we provide for them. These means that our software has to be flexible and scale well as there's no predicting what they'll build.

How does particles fit into that? What use-cases do you have?
As our software is meant for emergency service professionals we have a wide range of different fire, smoke, water and foam particle effects that the instructors can use. The instructors can place as many of these as they want in any position within the environment that they choose. This means that the individual effects need to be as lightweight as possible and must interact well with any type of environment, open or closed that they're put in.

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

What are the BAD things about the particle system now you dislike?
-Too little control from code. This makes it hard for us to give the users more control over smoke and fire behaviours.
-Low performance when you turn collision on.

How can we make it BETTER?
-Improve the collision performance (PhysX 3.3?)
-Open up the Shuriken API

 

Who are you?
3d artist, programmer, designer, solo dev. cat.

What kind of game are you trying to build or would like to build?
love all kinds of games but i really would love to work further on 3d action titles of my own.

How does particles fit into that? What use-cases do you have?
one of the first jobs i ever had in CGI was FX art. i love fx in general. they can really improve the look and feel of a game. impact of hits especially.

What are the GOOD things about the particle system now you like?
the ability to work with particles in the scene view is pretty useful.

What are the BAD things about the particle system now you dislike?
lack of API exposure.
lack of options.
lack of expandability.
lack of GPU acceleration support.
shaders need alot of work to get looking good.

How can we make it BETTER?
Expose more API. alot more.
more modules/options. the current systems lacks alot of options and customization. plus lacks the ability for me to add them.
allow better expandability. (custom C# modules, GPU modules, etc...)
gpu particles. (depth buffer collision, custom modules, etc...)
better particle shaders. transparent shadowing, order independent transparency, etc...
improve performance.

 

Stepping back for a bit: has any ETA or Unity build number been put forth as a time when Shuriken will get an update? The lack of scriptability/API exposure is a pretty constant complaint among all of the Unity devs I know, and for people working on professional projects it would be a huge help to know what's coming down the pipe. Pretty much anything would help: a target date, a target build number, a high level list of priorities so we know what's coming first vs. later, etc.

I know that no one at Unity can give firm promises, but again, for people making decisions on professional projects, even something high level like "We are hoping to have the first feature update out for summer this year if things go well, and our first priority is X" would inform whether to wait or start hacking around the system's limitations.

 

I'm sorry while I'm not Unity staff, what I understand from them is they can't put a date on updates of any kind except hopeful sometime in 5.x life cycle. So as a business, I would recommend you work with what it can do now. In fact this pretty much goes for all engines in this sector, it's really quite dangerous to bank on a feature being around when you expect.

But Shuriken can do an enormous amount if you become familiar with the Particle class, as you have control over every individual particle if you so desire (based on your hacking comment).

 

That's a good point! Do you have any links to useful reference for the particle class? Specifically, I'm looking to read from and write to the particle array before it generates the billboard geometry and goes to the renderer. All I seem to find when I look is in reference to the legacy particle system rather than actually integrated with shuriken.