[Official] Particle System [Shuriken] Improvements

https://issuetracker.unity3d.com/issues/linear-color-space-doesnt-reproduce-accurate-particle-colors

Is there any effort in fixing this long lingering issue? Since the ticket priority is not quite high. Indeed I can customize the shader to increase color saturation so I don’t need to modify the colors in all particle prefabs one by one, still this should be natively handled instead of user workaround.

 

Maybe Unity would default to linear for new project or hide gamma setting altogether, just like the rival engine? It is increasingly counterproductive to support gamma todays.

 

Hey! Great additions recently with ribbons!

I have a few ideas that I would like to share.

1) Axis lock for ribbons, trails, and mesh renderer modes.

For example - the ribbons are great tool for creating car tires trails but currently the ribbon is always facing the camera.
There are multiple reasons why this is usefull - check out this presentation for example:

2) Inherit color by mesh texture would be awesome too - I think we can now inherit by Vertex Color.

3) I've always struggled with distribution of particles in every shape modes. Evenly distribution of particles in shapes like Sphere, Cylinder or Box. Currently they spawn randomly inside or on surface, often one on top of another. Would be great if they could somehow be evenly distributed like in Circle Shape mode "Burst Spread' but inside a volume.
I know that I can use Mesh for a surface stuff but this is sometimes problematic. If I bump the emission higher than the vertex count it produces a lot of overdraw. Limiting particles to the number of verticies would be great.

I hope this is not too fuzzy

 

I'm replacing the legacy particle system with Shuriken as the old system is depreciated and I want to update to a new version of Unity. Performance differences have been a problem, but seemingly under control (and apparently will be much better once the switchover is complete and can update), but I am missing the Systematic option of the legacy system. This option places each new particle on the next vertex in vertex number order. Is there a similar option in Shuriken? I cannot find it so far.

I use Systematic in 2 ways:

1. I use the One Shot option (I assume Burst replaces One Shot?) with the same number of particles as there are vertices to create a shape I have built with a mesh, which then dissolves. Systematic means there is 1 particle on each vertex. Without it, randomness to the emission means some vertices get multiple particles, while others get none.

2. Have a particle effect appear to travel along a complex path laid out by the vertices of a mesh. Each new particle appearing one vertex along, while the older ones fade out causes the travelling effect.

 

Thank you, I hadn't seen that. Unfortunately Systematic is not mapped across. Continued exploration means I am pretty certain Systematic (or similar functionality) does not exist in Shuriken.

The only way I have thought of replicating my first use case so far is to have a particle system for each individual particle and activate them all at the same time. Plus some variation for the second use case. Of course this is a horrible method.

 

I'm busy with non-Unity work at the moment, so a video is not possible, but I will give a quick explanation.

My game is a jigsaw/dominoes hybrid. To mark certain special moves, I create a large jigsaw piece outline made of around 200 small jigsaw piece shaped particles, which then disperse. I do similar things with other shapes, such as the outline of completed puzzles.

Something else that I was doing was move confirmation. when a piece was placed, particles built up along the outline of the jigsaw piece. When the surround was completed, the move was confirmed (the player could tap to confirm or swipe to reject before completion). I have removed move confirmation, but was going to use a similar effect for the primary selection option on menus (buttons are often jigsaw piece shaped).

 

Thank you. I look forward to it.

 

+1 for this! Long before using Unity myself, my Custom Made Game Engine Particle System supported this and it would be nice to have this available on Unity! =)

 

Do you know when Systematic will be added to Shuriken? I cannot see it in the release notes for 2018.1 or 2018.2. I have stayed on 5.6 because of this, but will need to update before releasing on iOS in a couple of months. I would jump straight to the beta if I knew it had it.

 

Is it possible to make InheritVelocity module work with Custom simulation space?
Consider a 2d game with an orthographic camera and parallax layers which follow the camera to mimic the parallax effect.
In this case if we put a particle system inside one of parallax layers we can't use World simulation space because it won't look correct (the particle system will move in world space but stay static relatively to parallax layer). The only solution is to use Custom simulation space with parallax layer as relative transform.

 

Any feedback?
At first I thought that InheritVelocity does not work with Custom simulation space by design, but now I have a doubt because of this bug https://fogbugz.unity3d.com/default.asp?1046265_55al6968uo3r8a5v . Does it relate?

UPD. Also I've noticed that bug report ( https://issuetracker.unity3d.com/is...et-to-zero-when-using-custom-simulation-space ) has completely wrong description and sense. Expected behaviour is green and red particles being emitted because they have non-zero Rate Over Distance.

 

I am attempting ECS on Particle System before Job Systems because it seems slightly more attainable. I have an unimpressive but working ECS script. My question is how to avoid setting the module struct OnUpdate(). With the old OOP script I simply set it OnEnable() or Awake(). I know there is OnStart() for ECS, but I have trouble to make it work.

Code (CSharp):

1. using UnityEngine;
2.  
3. namespace Hybrid.Components {
4.     public class Particle_ECS_data : MonoBehaviour {
5.         public float _sizeScale = 2f;
6.     }
7. }

Code (CSharp):

1. using Hybrid.Components;
2. using UnityEngine;
3. using Unity.Entities;
4.  
5. namespace Hybrid.Systems {
6.    public class Particle_ECS : ComponentSystem {
7.        private struct Group {
8.            public ParticleSystem _ps;
9.            public Particle_ECS_data _data;
10.        }
11.        
12.        override protected void OnUpdate() {
13.            foreach (var e in GetEntities<Group>()) {
14.                ParticleSystem.MainModule _ps_main = e._ps.main;
15.                _ps_main.startSizeMultiplier = e._data._sizeScale;
16.            }
17.        }
18.    }
19. }

 

Hi again.
Dominykas from QA marked this bug ( https://fogbugz.unity3d.com/default.asp?1046265_55al6968uo3r8a5v ) as "not a bug". You may check his arguments by following that link.
However I believe that it is still a bug, because Rate over Distance must use velocity relative to Simulation Space and it does not matter which object is moving: the particle emitter or its Simulation Space transform.
If it would help I can upload a unitypackage with a project for reproduction.

 

I've just reported a bug in particle system: https://fogbugz.unity3d.com/default.asp?1049033_qrj3lrlfklgjg7pn
It looks like particle size and pivot are wrong with Rendering Mode set to Billboard Vertical or Horizontal.

Here you can see size problem:


And here you can see pivot problem:


This functionality is crucial for my current task. I will appreaciate if anyone from development team take a look at it.

 

Hi! It would be cool to be able to have in inspector the speed parameter in Texture Sheet Animation section.Currently if i have only 2 by 2 flame texture sheet it will look as if it is slow motion. and if i apply 10 by 10 texture sheet it appears to the viewer as if it plays mush faster. There is often a need to slow down or speed up the rate of going through tiles.
Thanks!

 

Thanks! cicles parameter in T.S.A section did the trick.
I`m making volley of fire arrows sent in an arch trajectiry towards target. to enable gpu instancing i`m using meshes in render section instead of billboards. It does the trick with them having right rotation turing the trajectory travel. But when they hit the ground they stop at the ground level as they shoud. But they go horizontal next moment they hit the ground.
Shouldn`t they rather stay at approaching angle to the ground instead of going perfectly horizontal pozition?
How do i make prticles keep theyr approashing angle after they hit earth`s collider ( roughly 45 degrees to ground plane)?
Thanks!

 

Hi! I have few hundred particle emiters for volleys of burning arrows. I used trails for fire and its quite performance heavy. I thought about making mesh with two materials one material for arrow and second for fire (animated sprite sheet via c# script)
Arrow mesh with two materials in it looks good enough in runtime. But it looks like i`ll not be able to use resulted prefab with shuriken. It will take only mesh with one material on it. So the only alternatives would be :
1 to make shader that takes two textures and apply them to corresponding material id`s and will animate fire texture (not sure if it will work with shuriken this way either)
2 If it is not an option then to actually use projectiles instead of shuriken. Given projectiles will do only a collision to spawn small fire(shuriken particle) will it be more performant than using shuriken arrows with trails(4 quads short trail)?
Thanks!

 

@richardkettlewell I'm not completely up to date (I'm still in 2017.4), but I had a couple of ideas lately when working.

1. Would it be possible for the Collission module to support different shape types such as a cube or use one or several custom meshes in a similar setup to the Renderer tab?

2. Multi-particle system editing is a great time-saver, but I had some issues when graphs are involved. When selecting two particle systems with different graphs, you just get a blank space you can't edit.



I think the only way to work them is if you edit them both from the start, or 'synchronize' them by using Preset graphs.

So the idea is to be able to right-click a module and copy/paste over the info to the same type of module in another particle system. Could be pretty handy.

 

@richardkettlewell What I mean is being able to alter the collider of the actual particles (not what they collide with) from the standard sphere to a cube or custom mesh. The only option related to this is Radius Scale.

I was imagining something like a one-shot particle system of cubes being thrown down the stairs where they'd tumble down and land realistically. I guess there would have to be an option for rigidbodies and different colliders. I don't know if this would be viable to implement?

 

In the blog post related to the Spaceship Demo project I've read this interesting point: Octagon Particle.
Is it possible to have as new primitive for billboard particles?
It should be a nice improvement both for everyone is not using HDRP and VFX Graph

 

I think he's asking for an Octagon billboard

 

You can have mesh particles face the camera in the Renderer tab, this way you could make it any shape. It would pretty much behave like a normal Billboard particle.

 

Oh that's new, since when???!!!!

 

@Reanimate_L Not exactly sure. I'm working in 2017.4 LTS and it's available there

 

Oh wait that option also work for mesh render mode!!??? oh wow!!!!

 

thank you guys.
I've never seen that we have "now" that option.... ok.. I'll do my Octagon Billboard

Thank you very much and thank you Unity devs.

 

Something I get asked a lot from my asset store customers is "How can I make particles work in the UI Canvas?". They talk about using particles to make buttons glow or catch fire, or emit confetti over win screens on mobile games.

Is there a recommended way to utilize particles for UI?

Some workarounds I found mentioned camera layering/stacking or using a hacked or custom shader to have particles render in the UI Canvas.

Maybe it could be an option in the Standard Particle Shader to have them render in the UI Canvas?

 

Edit Key option in the curve editor is really bugging me. It operates in normalised values which don't match up with what the Curve window values at all. View attachment 811730
Image shows this issue.


Keyframe has real value of Start Lifetime 0.2 and is placed at 0.02s time.
If I enter into Edit Key mode it shows the value of 0.65 (65% of 0.3) and time of 0.07 (always in 0-1 range).

This display system is very confusing and makes it hard to enter precise values quickly. I get it that there are those few occasions where editing in normalised values might come in handy but to be honest, I've never found this useful for particles. I'd rather have non-normalised values displayed in the Edit Key mode, or both normalised and real values side by side.

It would be awesome if you guys could consider this in future updates.

 

Some feedback on how selecting Random values could be improved.

I very often use Duration and then use curves to animate starting values of particles. Example: to create good looking spark effects you want to spawn particles with high speed first and then gradually set starting speed lower.

This is very easy to achieve with Curve on the Start Speed param. Issue is that the resulting visuals are very uniform as there is no randomness.

To fix the issue we have Random Between Two Curves. And this is where the problem begins.
1. This is the most expensive option out there, and I animate a lot of starting values using this technique. It quickly can become quite a performance issue
2. In great majority of cases the second curve is exactly the same as the first one but moved a bit down, to have lower values
3. Making the second curve the same as the first one is very slow as I have to constantly mess with Bezier handles and add/remove points. This is workflow issue

So I'm arguing that I'd love to see another option. I want to specify a Curve and set a value, let's call it Random. It would always be in 0-1 range.
Setting this to 0.2 would mean a particle can have a value of 100% to 80% of curve value.
Value of 0.5 would give 50% randomness (between 100% to 50% of the original value).

So if a Curve at current time would give me Speed of 10, Random of 0.7 would give me a Speed value between 10 to 3. It would always randomize downwards, not upwards (if you see what I mean).

The beauty of this solution is that to get more randomness you just drag a slider without having to re-author potentially up to two curves. Also I am pretty sure it is much cheaper as you don't have to evaluate two curves and randomize between them.

I would also take any other solution which would not require me to fiddle around with two curves all the time. I really don't ever use two curves to do anything else than made a second curve just like the first one but a bit lower down. I am sure people use it for other stuff so I am not saying it should be removed. I am just arguing it is a bit of an overkill for this simple (and quite common) scenario.

 

Parameter naming Feedback.

I'd love to see explicit naming of params which would explain if this gets interpolated over Particle Lifetime or is it a starting value interpolated over Emitter Duration.

Good example of bad naming is the Noise module.

• Strength.. over what? Is that over Particle Lifetime or Starting Strength for new particles?
• Scroll Speed over Emitter Duration or Particle Lifetime?
• Position Amount over Emitter Duration or Particle Lifetime?
• Etc.

Similar issue is present in few other modules and some get it right

• Rotation over Lifetime - good name!
• Rotation by Speed - good name
• Color over Lifetime - good
• Start Size - yup
• Light Intensity Multiplier - that a starting value or over Lifetime?
• External Forces Multiplier - starting value or over Lifetime?

 

For a particle system that use the Mesh Render Mode and have different meshes selected, I would love to set a precise amount, or maybe a percentage of likeliness of the particular mesh to spawn.

E.g. Let's say a car explodes and you use a particle system to simulate the parts coming off. The particle system uses a Burst of 15 particles. You'll have 4 wheels, 1 engine popping out and perhaps 10 metal chunks.

Previously I've had to experiment with setting specific Random Seed to get an effect like this, but that ruins the randomness of the rest of the effect.