[Official] Particle System [Shuriken] Improvements

Here ya go:

http://docs.unity3d.com/ScriptReference/ParticleSystem.html
http://docs.unity3d.com/ScriptReference/ParticleSystem.Particle.html
http://docs.unity3d.com/ScriptReference/ParticleSystem.GetParticles.html
http://docs.unity3d.com/ScriptReference/ParticleSystem.SetParticles.html

It's basically like this:

Code (csharp):

1.  
2. void ModifySomeParticles()
3. {
4.     // Resize particle array if needed
5.     System.Array.Resize(ref myParticleArray, myParticleSystem.maxParticles);
6.     // Fill particle array with particles
7.     var particleCount = myParticleSystem.GetParticles(myParticleArray);
8.  
9.     for(int i = 0; i < particleCount; i++)
10.     {
11.         var particle = myParticleArray[i];
12.  
13.          // TODO: Do stuff here
14.  
15.          myParticleArray[i] = particle; // Don't forget to set the particle, particles are value types
16.     }
17.  
18.     // Set particle array
19.     myParticleSystem.SetParticles(myParticleArray, particleCount);
20. }
21.  

 

Sure - it's a piece of cake (and bear in mind you can just influence velocities if you don't want to handle positioning them manually) - and it's a lot faster than you think since it uses a reference to your array of Particle[].

First study http://docs.unity3d.com/ScriptReference/ParticleSystem.Particle.html
This is you bog standard single particle. You'll want an array of these matching the maximum size of your actual amount of particles you set in Shuriken.

Then you'll fiddle with the array as you like, before telling Shuriken to update them (ie whenever you make changes) with: http://docs.unity3d.com/ScriptReference/ParticleSystem.SetParticles.html

I wouldn't recommend using GetParticles unless for some reason you want to get the current state of affairs since this is more expensive, obviously.

edit: got beat by forum wizard above, but it's all good

 

You probably want to look into ParticleSystem.Particle instead of just the Particle class on its own.

edit: for some reason the rest of the posts didn't load for me. That's the thing you want though, as evidenced by the eight billion other people who replied.

 

9 billion, but who's counting.

 

Obviously not you, seeing as you forgot to carry the 2.

 

Who are you?
Jeff Johnson, CEO of Digital Ruby, LLC. I make iOS apps and Asset Store material.

What kind of game are you trying to build or would like to build?
I like RPG games and anything with lots of cool magic like effects.

How does particles fit into that? What use-cases do you have?
Right now I'm working on lightning. Hitting some performance cases which I'd like to offload some calculations to GPU such as calculating the size of a particle in screen space given a start and end point on a line. Very expensive on CPU. I don't see any way that Shuriken can currently pass these parameters on the GPU. I really want to pass custom data per vertex such as center points, start / end points, brightness, velocity, lifetime, etc.

What are the GOOD things about the particle system now you like?
It's fairly easy to get something setup and running. Lots of demos are available.

What are the BAD things about the particle system now you dislike?
Anytime I want to do something that is advanced (like high detail lightning), I run into CPU performance bottlenecks. There is also no way to access much of the particle system parameters via script (color over lifetime, etc.).

How can we make it BETTER?
Please provide a way to pass custom properties per vertex. I know this is a difficult feature to implement and make cross-platform, but most graphics API allow this (DirectX, OpenGL, Metal, etc.). Please provide a way to access all the particle system parameters via script.

 

Is something actually happening here? It's been a very long time since this post!

 

Yes, we have captured the feedback so far and are still monitoring this thread. Now that Unity 5 has shipped our focus is on extended quality improvement, and upgrading/improving current systems is also something we're working on. We don't have anything more info to share at this time

 

Cool to read this Bibbinator!

So this is going to be a long one. Since my last post, a lot o things has changed so I'll just answer the OP's questions again.

Who are you?
I am a VFX artist and junior Graphics Programmer at CreativeForge Games, previously worked as a freelance Motion Designer. I have been using UDK, UE4, Unity (since 3.5), GameMaker Studio.

What kind of game are you trying to build or would like to build?
Currently, I am using Unity to build effects for tactical weird-west game called "Hard West". After work I am developing semi open-world, low-fi exploration game. It's initial focus lies in maintaining your mobile base, exploring the planet.

How does particles fit into that? What use-cases do you have?
Let's start with Hard West game - it is set in late 1800' in a weird west world. The game is gritty, bloody and harsh. It has strong focus on so called "shadow play" which limits ability to see a character if he is hidden in the shadow. That's why properly lit VFX are crucial in this game. There are also a lot of abilities which have MOBA-like visualizations.

My hobby project is about surviving on a foreign planet and exploring it. I have day/night cycle, some vehicles, few shallow caves. Player often has to leave his mobile base and go out exploring. Player often use his anti-gravity vehicle which kicks up a lot of dust up in the air.

I'll highlight main use-cases for games I have developed in Unity or that I am still developing:

1. Lit particles.
As I mentioned above, it is crucial for Hard West to have properly lit particles. Imagine a man hidden in the shadows at sunset. He is almost invisible, hidden in pure black. He is shooting from building's corner and because he has black-powder revolver it emits a lot of smoke. The problem is that there are no transparent-shadow receivers so that I can't make muzzle-flash particles "come out of the darkness". I managed to create lit particles which accept directional light, ambient light etc. But developing proper transparent shadow receiver pipeline on my own is an overkill.

2. Specular particles.
There is a lot of blood in Hard West and I had to spent a lot of time to creating proper bloodbath visual style. For blood splatters I decided to create bumped-specular particles with animated texture sheets. Unfortunately, Shuriken generates camera-space normals which are unusable for specular calculations. Try assigning specular material to any Shuriken system - specular highlight is constantly traveling across a particle. Possible workaround for this is to pass _Camera2World matrix from script and convert camera space normals into world space normals but I havent tried that just yet.

3. Resizable emitters.
Before Hard West I was working on the game called Ancient Space. It is a RTS homeworld-like game with 3D movement. We had about 30 different ship models with varied size. The biggest ships are about 8x larger than the smallest. We also had ship abilities shared across all ships. For example, we had "repair" ability which was available for every single ship in the game. The easiest way to do the same particle VFX for all ships is to prepare one prefab and scale emitter size accordingly to the ship size. Unfortunately, Shuriken does not expose emitter size for scripting. I had to manually create separate prefabs for every shingle ship (30 prefabs) which were exactly the same but had different emitter sizes. Because there was about 10 abilities I had about 300 Shuriken prefabs at the end of development. But at some point it was clear for us that we need to resize some of the ships. Because of that, I had to manually resize emitters in about 100 Shuriken prefabs.

4. Beams.
During Ancient Space development we decided that we need beams for weapon effects and for few abilities. Unfortunately, we had too few programmers and they were really busy creating gameplay features and I was not skilled enough to create proper lightning system/beam system. Back in the day (Unity 3.5) there was no good beam solution available to buy at the asset store. We ended up using pre-modelled beam mesh which was stretched along given distance. The result was really ugly. During Hard West development I had enough time and resources to create my own lightning system which works really well but as a VFX artist I am disappointed that there is no built-in solution for such a common effect. Additionally, it is really hard to create beam system with editor real time preview.

5. Dynamic parameters.
It is one of the most lacking feature of Shuriken. All games that I have been developing had a lot of effects which could really benefit if there only was an option to assign per-particle shader parameter. UDK and UE3/4 users know dynamic parameters really well and they are using it constantly. Let me explain what dynamic parameter is. Dynamic parameter is a shader property which can be driven per-particle during it's lifetime or during emitter lifetime. For example, for UDK/UE users it is a common practice to create UV distortion for explosion particles and this distortion parameter has to be modulated per particle's lifetime to create proper results. Dynamic parameters are what makes UDK/UE particle effects so good. It is a foundation of good looking particle sprite. Unity user have this option to use "Color over lifetime" module to drive particle parameter over lifetime. One needs to write a shader which is driving certain parameter by vertex color. But at the same time, you are loosing ability to color your particles over lifetime. These are video references that will show you what is possible with dynamic parameters.

6. HDR color.
Shuriken particle colors are not HDR. By HDR I mean a possibility to create super-bright particles. In Ancient Space we had a lot of explosions from small flak cannon muzzle flashes up to nuclear explosions. In reality, nuclear explosion will emit more photons than a firecracker. Looking at nuke will start adaptation process in your eye. We wanted to imitate that effect with a proper post-process which changes exposure based on the brightest spot on the screen. The problem is that Shuriken's brightest output is pure white (1,1,1,1 in RGBA). There is no "super-white" to use for eye adaptation process. I have the same problem in my hobby project which have a lot of tonal variation in the screen. Also, UE4 has this really helpful post-process which creates glow around super-white objects. It looks really natural. Since Unity5 has realtime GI, PBR and better linear workflow it should a reasonable move to create HDR workflow for VFX.

7. Modules.
During Ancient Space development I had to create a black hole effect. I wanted do create particles spawning at the sphere's surface and accelerating towards the center of black hole. I achieved this effect but particle motion was not natural at all. It is possible to create sphere emitter, emit from surface and add negative speed for each particle. That way they are heading towards the center. But:
- it is not possible to make them gradually accelerating (linear speed is not natural) towards the center while having random initial speed
- it is not possible to kill particles at given point/volume
- it is not possible to create orbiting motion
Most of the things listed above are possible with c# scripting but they are so essential in VFX workflow that they should be built-in. Syncing c# scripts with Particle System Update is an issue, again. Testing your VFX at play mode is not the best solution.

We also have problem with rain falling through rooftops (because we can't use Physx in Hard West and we don't use colliders). A Kill Box module could solve our problems, but there is none.
https://docs.unrealengine.com/lates...icleSystems/Reference/Modules/Kill/index.html

8. Mesh rotation.
In Hard West I have a lot of mesh particles. I use them to emit debris, glass shards, meat chunks etc. In Ancient Space I had a lot of cutscenes with ships being blown up, emiting lot of metal elements. Current "rotation over lifetime" module does not allow you to create true XYZ rotation. Mesh particles are rotating only in one axis (in most cases). From visual standpoint, it is not acceptable to have mesh debris coming out of destroyed ship, rotating in one axis. That's why I had to remove a lot of mesh particles from Ancient Space and Hard West.

Ancient Space had also a lot of ship-speficic abilities which looked like HUD elements, Iron-Man-like. For various reasons I had to use mesh particles. Unfortunately, I quickly ran into the issue where I was not able to control particle rotation in chosen axis so I basically had to animate all the meshes and material parameters by hand, inside Unity Editor. Animating it in 3DS Max was not an option because I was not able to animate material and export that animation into Unity. Unity on the other hand has Animation window which can animate meshes and materials but can't handle custom bezier-handle lengths etc. Shuriken would be perfect but it couldn't handle mesh rotation.

8. Collision.
In Hard West we don't use PhysX at all, not even colliders. At the same time, it would be perfect to have some kind of particle interactions in the world. We have window-break system which spawns a lot of shattered glass particles. Because there are no colliders on the ground I can't make particles bumping from the ground. GPU particles with depth-map based collisions would be perfect. I know that there is GPU particles package on the asset store but if you sum all lacking features mentioned in this post you can end up with about 700$ worth packages required to create acceptable and up-to-date VFX. Additionaly, programming own solution is an overkill for small teams.

9. Light.
Current particles can't emit light. There is this workaround in which you GetParticles and assign a light at particle position but you don't have flexibility of setting Light Parameters via Shuriken interface. There is no "light color over lifetime" module or "radius over lifetime" etc.

10. Texture sheet blending.
In Ancient Space we had a lot of 3d particle based nebulas. One way of animating them was to bake sprite-texture sheet with fluid animation in it (common practice). The problem with this technique in Unity is that there is no between-frame blending. Imagine having a reaaaaaaly long living particle (8secs for example) with animated texture sheet. In order to make smooth sprite-animation you would have to bake a lot of frames into it, ending up with really big texture which takes a lot of memory. It would be much performance-wiser to create smooth frame blending. This would allow VFX artists to create smaller textures with fewer frames with proper, smooth animation.

11. Stats.
There are no particle stats at all. They are one of the most expensive elements of any game and yet, there are no statistics, informations about memory usage, cpu usage, particle count anywhere in the Shuriken. It is possible to check CPU/GPU footprint in profiler but having some live-updating stats in editor window would be a big plus.

12. Rectangular particles.
Currently, Shuriken have only stretched, horizontal, vertical, mesh and billboard modes. Having rectangular billboards would allow VFX artist to have additional visual fidelity. I don't have specific use case here but during my contractor job in UE4 I use it quite a lot for some smoke effects.

13. LOD.
There is no robust particle system LOD solution. Ancient Space had large, open space levels filled with particle systems. We could optimize them a lot if there only was some kind of robust LOD system which allows you to change some parameters depending on camera distance.

What are the GOOD things about the particle system now you like?
UI is really good. It is much superior to other particle systems that I have been using. I am particularly happy with how curves work. You can freely rearrange curve points, set their values, copy and paste whole curve into another curve field. Try doing that in Cascade Values descriptions are self-explanatory- other engines which I have used have voodoo parameters with unclear descriptions. Documentation is really good, most of the topics are covered. I can set-up basic effects in a matter of minutes. It is also super-duper easy to script it. I really love the way you expose parameters. If they are exposed they are very helpful and easy to use. Keep it up!

What are the BAD things about the particle system now you dislike?
Shuriken rarely gets any updates, new functionalities or bugfixes. It is really hard to expand it. It feels old and it does not catch up with new Unity lighting workflow. There is no easy way of syncing custom scripts with particle update in editor window. I also don't understand why it have modules drop-down list when there is no way of adding your own.

How can we make it BETTER?
- it would be perfect if you would open up the source code (the same way you did with UI). I don't know if its possible because Shuriken is probably written in C++ and only some stuff is exposed. But still, this would be perfect
- possibility to write custom Shuriken extensions which show up as a regular Shuriken module
- expose Shuriken UI elements. Default AnimationCurve does not have the same functionalities as Shuriken curves. Also, there is no lifetime gradient exposed to use in custom scripts
- expose more parameters such as emitter positions, size, rotation
- add editor particle-system update to that we could write custom extensions with editor runtime testing
- add dynamic parameters. Unity5 has a lot of UV aviable for meshes. Why not use Additional UV channels for dynamic parameters?
- disable automatic particle culling and allow user to determine culling bounds
- more built-in shaders
- HDR color workflow
- add _Camera2World matrix in Unity.cginc . Passing it via script is not a robust solution
- add possibility to generate world-space normals
- add separate axis mesh rotation rate
- GPU particles?
- built-in beam emitter with editor update
- light emitter with parameters control available in Shuriken UI
- particle system stats and LODing for easier performance optimizations

I also have a proposition for you, Unity guys. There is this perfect particle system called PopcornFX. It is the best particle system I have seen. They are struggling with integrating some of the features into Unity. You could help them or just expand Shuriken by heading into similar direction. I know that you simply acquired Mecanim guys and you have one of the best retargeting systems aviable. Enlighten is now integrated into 5.0. So, maybe you could give PopcornFX guys a try

 

In addition, world space velocities workflow is messed up. It is not possible to simulate particle system in world space and add some velocity in direction of local axis. For example, you can't add velocity in local Z axis while "simulation space" is set to "world"- particles will have local space velocity and some world-space speed. So when your object rotates, your particle rotates. You can add "world space" velocity over lifetime but adding velocity in Z axis will add velocity in world Z. Force over lifetime workflow has exactly the same flaws.

 

Who are you?
VFX Artist at WB Games

What kind of game are you trying to build or would like to build?
Currently working on mobile game projects

What are the GOOD things about the particle system now you like?
UI friendliness, Curves based system, Sub emitters

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

• Lack of non-uniform scaling particles (need to be able to keyframe billboard scale of width and height seperately.) Squash and stretch is a MUST for making awesome fx!!
• Locked rotations. Need to be able to keyframe any rotations we want on X,Y and Z. This should apply to both rotations and rotations over lifetime. If this is implemented you can remove the locked horizontal and vertical billboard modes, as they will no longer be needed.
• Need to be able to keyframe the scale and options for each emitter shape- IE.. scale the 'circle' emitter type to be bigger over the timeline of the emitter.
• Lack of a solid beam system. The linerenderer is unoptimized and very basic. We need a beam system that allows for different kinds of noise along the verts of the beam (sine/perlin etc), different frequencies... Also the beam system should have built in options for things like UVscrolling which are universally used. Add a Head and Tail segment so that the beams dont clip out with hard edges and instead can have custom textures for each.
• Better streak/trail renderer. Clean bezier lines of geometry, the ability to taper the ends of the streak and fade them out appropriately. There are some improvements on the appstore for this but it should really be a part of the package. Streaks should be able to use different X/Y/Z orientations too for maximum flexibility.
• Lack of good particle stats/ overdraw / fillrate etc for optimization. No LOD system either.
• Parametric / orbit system - the ability to animate the positions of individual particles. This allows you to make cool shapes like funnels, tornados, a single particle orbiting another... etc. As a vfx artist sometimes I want full control over how my particle animates, instead of relying simply on the basic forces and physics.
• Lack of pivot offsets. I want to be able to specify where on the texture the particle rotates from.. which is not always the center of the texture.
• Particle materials should run thru the HDR system, so that you can boost the brightness over your stuff past RGB255 values and really get bloom to pop!
• Dynamic parameters- see Unreal Engine.
• Randomize start frame of Texture Sheet animation
  
• Better support for texture Atlases.. allow us to pick UV coordinates for specific sprites on a large texture sheet.

How can we make it BETTER?

• Implement above stuff!
• Add more emitter shapes!
• Add more forces, turbulence, animation modules
• String particles.. emit strands of particles- See FORK particle system
• spline / path based particles

 

Who are you?
Vfx artist at Banzai Entertainment

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

How does particles fit into that? What use-cases do you have?
explosions, muzzle effects , smoke&dust, water , magic effect and others

What are the GOOD things about the particle system now you like?
the editor is easy to understand and i can easylly preview the pariticle effect in scenes.

What are the BAD things about the particle system now you dislike?
1. I can not change the pivot of the particles so that when I use the particle to do some scale, rotate and collision work it become kind of inconvenient especially in stretch billboard mode.

2.I do really need the unity to have the dynamic parameter function just like what Unreal Engine do !!!!!!! that will be soooo appreciated if you can add that function.

3.The texture sheet animation. I can edit the curve to control the speed and the frame range but now I can't set the first frame randomly and play the animation with a same speed. When I use Random between two curves the first frame can be set randomly but the speet of the animation will be randomly to.

4.I can't type in exact value to edit the key frame value of the particle curve.

5. The Vilocity over lifetime woks good when I need to creat come randome vilocity particle but when i want make particles move like a flow alone a coplicate path that function does not help alot.


How can we make it BETTER?
1. Implement those fuction above
2. maybe you can add some force field to control the particles' dynamic behavior
3. add "move alove curve" function or something like that
4.THE DYNAMIC PARAMETER REALLY MATTERS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

About Shuriken API. I am currently creating particle system which emits particles from weapon's mesh. Since there are many weapons in the game I would want to create one Particle System and assign weapon's mesh to "Shape" module via script. Because Shuriken does not have "Shape" in it's API I can't do this. Possible workarounds are silly - getting and setting particle positions to mesh vertices or creating separate prefabs for each weapon model. The first workaround is not performance friendly and the second is an overkill (hundreds of prefabs). So yea, "Shape" module exposed in API is welcome.

 

Man i'm really looking for particle pivot shift. . . .right now it's really weird for displaying directional Fire sprite with particle pivot in the center :/
EDIT :
Also Lit Particle. . . .

 

How can we make it BETTER?
There are many questions out there on how to access the ParticleSystem from script. For some reason, the modules inside the Shuriken ParticleSystem are completely hidden at runtime.

• http://answers.unity3d.com/questions/220483/shuriken-particle-system-accessing-the-emitter-mes.html
• http://answers.unity3d.com/questions/380205/how-to-access-shuriken-particle-system-modules-in.html
• http://answers.unity3d.com/questions/504434/how-do-i-access-the-shuriken-velocity-over-lifetim.html
• http://answers.unity3d.com/questions/483831/how-to-modify-particlesystem-from-editor-script.html

and more....

 

It is really hard to orient mesh particles towards given direction. Particle.Rotation is a single float so to implement "LookAt" functionality one have to use Particle.AxisOfRotation which is not documented at all. It gets event worse because Particle.AxisOfRotation is a Vector3 which accepts values from -1 to 1 instead of quaternion or euler angles. Also, it does not define actual rotation but an axis of rotation.

There is no "per particle ID/index". Currently, assigning per-particle parameter is horrible. There is no good way of telling which particle in Particle[] array is which. Lets say that I want to assign a particle to a certain position in the world and stay there until it dies. Sounds simple but when you have emission curve your particle[] array will have some random particles assigned to each index. particle[1] could hold many different particles in different points in time. If Particle class could contain Particle.index (int, double, hashtag, whatever) it would be much easier to assign per-particle parameter.

 

Recently we found mesh emitters to be vaguely uncontrollable. Would be nice to control orientation of spawned meshes properly & possibly replace whatever happens internally with instancing for speed (allowing higher poly meshes without screwing up shuriken's perf).

 

It would also be awesome if Shuriken would have multiselection. It's not top priority but I often enable looping during effect development and I disable it when effect is done. Toggling "looping" in 10 or more particle systems is laborious.

Yea. Unity is crashing if you spawn mesh particle with high triangle count. Rotation is also screwed - no controll over each axis rotation.

 

Blood effects again. Offsetting particle pivot would be appreciated. What you see on the picture is particle emitter and three stretched billboards. I'd like to offset pivot so that it starts on the beginning of the texture rather than on the edge. I can't really shoot out particles outwards in proper way right now. Offseting pivot would allow me to shoot them from the emitter rather than popping them in the air (screenshoted behavior).

It would also fix problematic particle orientation for stretched-particles. If you use gravity for your stretched billboards they will rotate around edge pivot which is not good-looking. They should be rotating around center point or any user-driven pivot point.

 

+1 for PopcornFX. It's an optimized and extremely powerful particle solution.

 

Who are you?

32 year old student

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

3D, often with procedural generation of some kind

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

The usual smoke simulation and similar, but also rain and other liquids falling from the ceiling

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

Easy to use and a large number of settings in edit mode

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

Many settings are not accessible during runtime.

How can we make it BETTER?

Make as many settings as possible available during runtime: First and foremost, being able to change the spawn mesh (the mesh that controls where particles appear, NOT the mesh of the particles themselves!). This is important for procedural generation.
Also, improving the particle collision system so that all convex shapes, at least primitives, are possible and correctly collide with the world (as opposed to only collidind with a particle's origin). Might be too hard on performance, though.

 

World space calculations are totally broken. In Hard West we have characters with normal biped hierarchy. I am spawning muzzle flash particles which are the child of weapon prefab which is a child of hand. Muzzle flash particles are located in world space but they are inheriting parent motion! This type of deep transforms dependency is causing other random problems. Particles are being spawned on random locations in the world or forward vector used for adding "Speed" is randomly rotated when parent moves in high speed. It seems that Shuriken can't properly handle world-space simulation if it is nested in long parent-child chain which is a regular practice for all characters in games.

My hierarchy which is causing problem:
root(Mecanim animator controller)->hand->weapon->weapon barrel->muzzle flash

Spawning particle with no parent fixes all the problems (but I can't do that for many reasons).

 

I have checked the interpolation stuff without any effect.

I think that this is not the case. I am not using "Inherit velocity" in my particles at all - it is set to 0. My character is a skinned mesh with kinematic rigidbody and single capsule collider. Body parts are driven by Mecanim which is playing proper animation. When my character is standing still, not moving at all a shooting animation is played and animation event is spawning particle system into weapon barrel transform. All rotations and orientations are fine but some particles are shooting upwards instead it's local Z+ axis. I have checked it few times, fellow programmers also checked what is going on. It is happening only on one animation in which hand is moving a little faster than the others. If I were to spawn particles at barrels position instead of spawning it as a child of barrel particles are fine (obviously). Other, slower animations are not causing the problem.

We also had a bug in earlier builds. Back then we had muzzle flash particles sitting all the time in the weapon's barrel transform and we would use Emit function when character was shooting. The problem was that sometimes particles were spawned somewhere else in the scene. We had interpolation turned on. And again- shooting only occured when character was standing still. Only animation was being played.

Is there anything else we might have overlooked?

 

It will be extremely hard for me to isolate this particular piece of game but I'll try to to this after the premiere.

Meanwhile, I have found another bug. Unity is modifying UV of mesh particle in unclear way. I have a shader which is distorting UV via another shifting texture. It looks as expected on horizontal billboard, billboard, vertical billboard, stretched billboard, on a mesh in the scene. The same material applied to the same mesh in Shuriken looks very different.




And the reason why I need to use mesh billboard is another Shuriken bug. Every particle that is close to the camera is either extremely large or is being shrinked no matter what "Max Particle Size" is set. This applies to all billboard modes. The only solution is to use mesh particle which does not change its size when it gets closer to the camera.

There is also another random bug. Sometimes shape gizmo is not visible with Shape module enabled and sometimes it is visible all the time. Sometimes it fixes when I deselect and select particle system but sometimes I have to restart Unity. I already reported this bug but it was closed because it was not reproducible.

 

I don't know if this is a feature or a bug. Consider this code:

Code (CSharp):

1. Transform particleSystem = Transform.Instantiate(Effect);
2.            
3. particleSystem .SetParent(chest);
4. particleSystem .localPosition = Vector3.zero;
5. particleSystem .localRotation = new Quaternion();

For some reason Particle System knows that it is firstly spawned in world (0,0,0) and then it is translated to chest position. It calculates velocity that was generated due this translation so if you are inheriting velocity and spawning by distance you will get buggy particles generated in the first frame.

This piece of code does not generate that behavior:

Code (CSharp):

1. Transform particleSystem = Transform.Instantiate(Effect, chest.position, chest.rotation);
2.            
3. particleSystem .SetParent(chest);

I can live with this but it seems pretty... weird. There are some situations in which you would like to spawn the particle system and move it few lines later.

 

Who are you?
A hobbyist game developer who works on stuff in their free time

What kind of game are you trying to build or would like to build?
A 2D action/arcade game

How does particles fit into that? What use-cases do you have?
Explosions, power up effects, ability effects, more explosions

What are the GOOD things about the particle system now you like?
Clean, easy to use, gets the job done

What are the BAD things about the particle system now you dislike?
None that I know of

How can we make it BETTER?
I also agree about the ability to resize the system as a whole
And would love to be able to have multiple materials, in which it uses a random one per particle, I thought it was a feature then got a bit disappointed when I tried to implement it

 

I don't get the idea behind Particle.Color. http://docs.unity3d.com/ScriptReference/ParticleSystem.Particle-color.html

It is a 32bit value but it can only be set in 0-255 range? New Unity have HDR color picker so why there is none for Shuriken? Also, if particles do support 32bit color value why all built-in particles are returning fixed4 value from pixel program ?

 

32 bit color is 8 bits per color channel, and 8 bit is a 0-255 range. This is also what fixed4 gives you, a four 8 bit float values between 0.0 and 1.0.

Yes we're missing float color in either 16 bit or 32 bit per channel. 16 bit float color per channel is more than enough for most things, and what I believe Unity uses for it's linear HDR pipeline.

The confusion here is how people talk about color.

32 bit color, 24 bit color, 16 bit color, and 16 bit float color are all very different in what people mean.

32 bit color and 24 bit color are the same thing in terms of the actual color, 8 bit per channel RGB, 3 channels x 8 bit = 24 bit. 32 bit just adds a fourth 8 bit channel for alpha.
16 bit color is 5 bits for red, 6 bits for green, 5 bits for blue. This is how DXT1 / BC1 stores it's color as part of its compression scheme.
16 bit float color now refers to each color channel, so an 16 bit float RGB color is actually 48 bit color, and RGBA is 64 bit color.

In Shuriken update news, particles are now generated in world space so there's no need to do the _cameraToWorld hack! Looks like they're starting to work on Shuriken at least in some capacity again.

 

Thanks for clarifying that. I was confused because I was equating 32bit color to 32bit floating point color.

As for the Shuriken updates. Yea- they started to improve it. I really can't believe it. I am using Unity since 3.5 and there was no real significant Shuriken update since then except collision callbacks and world collisions. World-space particles is a real thing. I am soooooo glad that they finally made it. Also they fixed these:

• Performance: Particle rendering optimizations (especially for VR), with speed improvements varying from 15% to 50% depending on geometry type
• Particles: Mesh particles now support the Texture Sheet Animation settings (finally!)

• Particles: Fixed culling issues when particles are set from script (this disallowed my company to update our game to Unity 4 - all particles that were set from code were culled improperly)

• Particles: Fixed curve editor preview not updating after undo
• Particles: Fixed Limit Velocity over Lifetime being framerate-dependent

• Particles: Fixed sub-emitters sometimes not firing (this broke a lot of my effects in Unity 3.5)

• Particles: Fixed some spawn parameters not being random enough (I have not yet tested if but if it's connected with particles on the left side of emitter with left sided values and right side with right side values that would be awesome)

The roadmap shows opening Shuriken API for scripting and built-in skinned mesh solution in 5.3. Great.

 

Don't know if someone said that already but :

- An integrated tool to bake particles into sprites is really needed for optimizations purpose !

 

That would work only in very specific situations. I can see that it might be helpful in games where your camera is at fixed angle or if you don't need any depth in your effects. If you want to have single sprite-sheet effect why won't you animate it in external software? As a VFX artist I would totally bake all my effects in After Effects where I can do a lot more for baking particle effect. I can see that it might be a problem if you don't have After Effects or similar software but it does not cost that much these days.

 

As a project manager I'd avoid it, and possibly the same as a tools guy.

If it's in-editor with the existing particle system then the workflow and resulting style will be identical for all particle systems. They won't look different based on whether they're real-time or pre-baked instances. So that's a win. Consistency is always a plus.

Also, if it's in-editor then it can more easily be automated with in-editor tools or, heck, perhaps even at runtime. It's a boon to your workflow if you don't have to know in advance which particle systems to create as baked sprites and which ones to have as real-time systems - just make them all the same way, and convert from real-time to baked sprites as needed at the performance balancing phases of your development (or at load time based on quality settings, perhaps).

Plus, the people making your particles don't need to know / have access to a 3rd party tool. Plus plus, you cut out a few steps of workflow if its done in-editor, because you don't have to bring in external sprites and turn them into a sprite sheet, the baking process should do all of that for you.

 

I have a feature request: HDR particle colors and color pickers would really help to use particles in HDR scenes with bloom effects etc.. Please see this thread where the question has come up originally:
http://forum.unity3d.com/threads/enabling-hdr-color-picker-for-shuriken-particles.354468/
I'm pretty sure there are others who would find this useful as well.

 

Hey, Hard West KS backer here, nice to see a developer here

About the emitter resizing: I resolved this by not putting the Partice System directly onto the gameobject (ship, or whatever), but rather as a seperate gameobject and make it a child of the ship. The child can be resized as needed and the emitter will be resized with it, of course. I uses it to be able to use one PS prefab for multiple weapon models (creating effects like fire and lighting around a sword blade, for example). By setting the PS object's xyz scale values, I was able to make it encompass the blade without needing one PS for every weapon. It'd still be great if the actual emitter shape could be changed, too (at runtime).

 

It looks like something big changed in particle collisions between 5.1 and 5.2. Particles used to get collisions whether the particle collider hit another collider or the collider hit the particle collider. Now it only appear to happen when the particles hit the other collider. For instance, this scene has a rising field of particles, with a sphere moving across them, with the particles dying and leaving a small burst of particles on death.
In 5.1, the result looked like this:

There is a column where the sphere destroyed the particles in it's path.
In 5.2, the same scene results in this:

Only the particles that rise and hit the sphere from the bottom seem to be effected.

Christian

[edit: images did not work in the first version]

 

The bug is reported (with the two projects) as 728693. I will check the patch.

 

I just checked the patch and the behavior is the same.

Christian

 

I don't want to hijack this thread, but it seems (tought I'm not sure) I ran into a similar problem with particles collision:
http://forum.unity3d.com/threads/what-can-cause-particles-to-go-through-colliders.358679/

Will try to revert my project to 5.1.3 and test with it.

 

@karl.jones I love you.

How many custom parameters will be available? Would it be possible to assign curve over lifetime per parameter?

 

Who are you?
I create and sell VFX and other art in the Asset Store

What use-cases do you have?
All types of effects for games. Explosions, smoke, fire, click effects, spells, magic portals and all that good stuff.

What are the GOOD things about the particle system now you like?
It's very intuitive and easy to learn.

What are the BAD things about the particle system now you dislike?
I've used the particle systems for a while now, and I think at this point I just want more features and extras to really make something special. There are however two things that bother me:

1. Not being able to scale the systems, but from what I understand, this is in the works
2. Lack of multi-editing several systems

How can we make it BETTER?
I'm not sure if everything listed here is feasible, but I think it would be interesting to play with.

1. Option for soft particles depending on the individual system, instead of only a global switch for it
2. Option to multi-edit some basic settings of particle systems, such as the Start Color. Perhaps the Start Lifetime could have a % slider option if you wanted to reduce the lifetime of several particle systems.
3. Option for the particle system to self-terminate itself once all the particles have died.
4. Option to add line-trails per particle
5. Option to let your particles leave decals on surfaces they collide with (or which their lifetime ends on).
6. Lit particles with a lot of lighting options! Curves, colors etc.

 

AD 1. You can somewhat do that. I have created my own set of particle shaders which allow you to disable/enable Soft Particles per material. I believe that you could create a script which would instantiate assigned material and then you could enable/disable Soft Particles per particle system (which would generate one draw call per material instance).

AD 3. You can do that with a very basic script. But yea. That should be built-in because it is essential.

AD 4. Agreed. You can also do that by assigning your own line renderer to be emitted from each particle but because there is no per-particle ID it is impossible to know if particle that you are emitting from died.

AD 5. This is very specific request. What I would like to have instead is some kind of API extensions which would allow you to sync your custom scripts with Particle System update. It is quite tricky right now. Doable but very tricky.

AD 6. I am developing my own lit-particles solution but it would be superb if Unity had it's own, built-in. I find it very disappointing that you can have really nice, dynamic lighting with all the GI but your particles won't sit in the scene at all. This is also connected with particles which don't have HDR color.

 

I have a question regarding performance. I'd like to use a generous number of smaller particle effects, a couple of hundred at the same time would be nice. I did a quick test to see if this is feasible and it seems that it takes too long on the CPU to have that many particle system instances. I have read in the past that people kept using the legacy particle system in such situations because it had less overhead. I can't find it though, is that deprecated already?

Any other solution I could try? My usecase is fire and smoke in a game with isometric perspective and the camera is pretty far away from the action. You see an area that is roughly 180m wide. So most of the individual particles will be very small in onscreen size.

 

Use one emitter in world space, translate it to desired location, use Emit function. This way you have one system with many particles. Could be cheaper.

 

Hi @karl.jones

Bit of feedback: I was thinking it would be a pretty good idea to have (per system) an option to render to a lower resolution buffer. In addition to this, the soft particles option would be extended to include a buffer size. This way you would perform soft particles and fill rate saving in the same step, saving a lot of time while increasing quality.

At recent Boston Unite, a developer demonstrated the savings from offscreen particles and I think it's especially relevant for both mobile and VR.

Finally, a question: Any plans to gpu accelerate particle rendering now things are multi threaded, or does Unity in general feel it's not worth the effort for the gains?