Search Unity

Starting with Unity 5.3, you have full scripting access to the particle system’s modules. We noticed these new scripting features can be a bit confusing. Why do we use structs in an unconventional manner?

In this blog post, we will answer some of your questions, take a little peek behind the scenes and explain some of our plans to make the process more intuitive in the future.

Accessing Modules

An example

Here is a typical example in which we modify the rate property from the Emission module.

To anyone familiar with .NET, you may notice that we grab the struct and set its value, but never assign it back to the particle system. How can the particle system ever know about this change, what kind of magic is this!?

It’s just an interface

Particle System modules in Unity are entirely contained within the C++ side of the engine. When a call is made to a particle system or one of its modules, it simply calls down to the C++ side.
Internally, particle system modules are properties of a particle system. They are not independent and we never swap the owners or share them between systems. So whilst it’s possible in script to grab a module and pass it around in script, that module will always belong to the same system.

To help clarify this, let’s take a look at the previous example in detail.
When the system receives a request for the emission module, the engine creates a new EmissionModule struct and passes the owning particle system as its one and only parameter. We do this because the particle system is required in order to access the modules properties.

When we set the rate, the variable m_ParticleSystem is used to access the module and set it directly. Therefore we never need to reassign the module to the particle system, because it is always part of it and any changes are applied immediately. So all a module does is call into the system that owns it, the module struct itself is just an interface into the particle systems internals.
Internally, the modules store their respective properties and they also hold state based information, which is why it is not possible for modules to be shared or assigned to different particle systems.
If you do want to copy properties from one system to another, it is advised that you only copy the relevant values and not the entire class, as this results in less data being passed between the C++ side and the C# side.

The MinMaxCurve

A significant number of module properties are driven by our MinMaxCurve class. It is used to describe a change of a value with time. There are 4 possible modes supported; here is a brief guide on how to use each when scripting.

Constant

By far the simplest mode, constant just uses a single constant value. This value will not change over time. If you wanted to drive a property via script, then setting the scalar would be one way to do this.

1In script, we would access the constant like this:

Random between two constants

This mode generates a random value between two constants. Internally, we store the two constants as a key in the min and max curves respectively. We get our value by performing a lerp between the 2 values using a normalised random parameter as our lerp amount.This means that we are almost doing the same amount of work as the random between two curves mode.

1

This is how we would access the two constants of a module:

Curve

In this mode, the value of the property will change based on querying a curve. When using curves from the MinMaxCurve in script there are some caveats.
Firstly, if you try to read the curve property when it is in one of the Curve modes, then the you’ll get the following error message: “Reading particle curves from script is unsupported unless they are in constant mode”.
Due to the way the curves are compressed in the engine, it is not possible to get the MinMaxCurve unless it is using one of the 2 constant modes.We know this isn’t great, read on our plans to improve it. The reason for this is that internally, we don’t actually just store an AnimationCurve, but select one of two paths. If the curve is simple (no more than 3 keys with one at each end), then we use an optimized polynomial curve, which provides improved performance. We then fallback to using the standard non-optimized curve if it is more complex. In the Inspector, an unoptimized curve will have a small icon at the bottom right which will offer to optimize the curve for you.

An optimized curve

1

An unoptimized curve

1

While it may not be possible to get the curve from a module in script, it is possible to work around this by storing your own curve and applying this to the module when required, like this:

 

Random between 2 curves.

This mode generates random values from in between the min and a max curves, using time to determine where on the x axis to sample. The shaded area represents the potential values. This mode is similar to the curve mode in that it is not possible to access the curves from script and that we also use optimized polynomial curves(when possible). In order to benefit from this, both curves must be optimizable, that is contain no more than 3 keys and have one at each end. Like in curve mode, it is possible to tell if the curves are optimized by examining the bottom right of the editor window.

1

This example is very similar to the curve, however, we now also set the minimum curve as well.

Performance

We did some simple performance comparisons to see how these different modes compare. These samples were taken before our recent SIMD optimizations, which should provide a significant performance boost. In our specific test scene, we got these results:
1

Easing the pain

Reading curves from the MinMaxCurve class

We know that you really ought to be able to read particle system curves from script, regardless of what mode they are in. We are actively working on removing this limitation, so you can read/modify all those lovely curves in your scripts. Its also currently not possible to query the curve to check if the mode is using a curve, without an error being thrown. That’s also going to be fixed!

Changing modules from structs to classes

We are currently prototyping a change to move all the structs to classes. Functionally they will behave the same, however by using a reference type, it should be clearer that the module belongs to a system. It will also allow for setting/getting values without having to hold a temporary variable. However, this will mean we allocate them once in the constructor, which will generate garbage, but only at initialization time.

For example:

Finally

We hope this post has been of some use to you, please head over to this forum post to grab the examples and comment/discuss.
We will also add this information over to our documentation.

33 replies on “Particle System Modules – FAQ”

Have you guys thought about extracting some useful classes to be used in other non-particle related cases?

I could imagine a lot of places, e.g. in the AI, where I would need “a random value between two curves”. And benefiting from optimized 3-key curves never sounds wrong… not all animation curves are imported from 3DMax with 50+ keyframes ;)

Not sure if this is the place to ask, but in the event that MinMaxCurve becomes modifiable from script, will they be usable in custom inspectors for non-particle related things?

the blog is very interesting and will be much useful for us. thank you for sharing the blog with us. please keep on updating.

Any plans about the shader side ?

Would it be possible to add a special case where a custom geometry shader could be used to display particles ? So the mesh generated by shuriken could only contains a vertex for each particle (+ all interesting data to be used in the shader)

And in the current state, do you think passing particles data (age, lifetime, size, etc…) to the shader to be something doable ?

I can provide a bit more information on that.

In 5.5, we are hoping to introduce a Vertex Streams feature to the Renderer Module. You will be able to choose exactly what gets sent to your shader (positions, colors, velocities, rotations, lifetime information, etc). This should allow you to do a wide variety of custom shader-based effects.

Additionally, you will be able to set custom particle data from script, and pass that to your shaders too. So, to give an example, you could tag particles with a custom property to represent the “health” of each particle, and then use that in your script logic, or in your shader, or both.

You’ll need to be comfortable writing your own shaders in Unity, to be able to make the most of this feature, but in its basic form, it will finally allow you to properly use the Standard Shader to create normal mapped particles, by including the Tangent Stream.

Hi Karl,
These new changes are welcome, but would it be possible to _please_ have someone fill out the documentation with stub example usages for the Shuriken-related classes/structs/etc. on the Script Reference?

Those API features are indeed well overdue, thanks.
But we need better UI and UX with Shuriken, and maybe a buit-in previewer.

Thanks for the post. The struct mechanism was a little confusing to me at first as well. Will the classes in a future version simply be references to a private member variable then? I assume so from your post, but just wanted to make sure it wasn’t allocating a wrapper every time the property was accessed.

Why have I been seeing GetComponent() in a lot of Unity articles lately? Is this a new version of the method I have not seen, which has no parameters or generic parameters? Thanks!

Never mind. I realized it was because C# can infer the generic parameter type. Sacrifices a little clarity for brevity in this case, I suppose. =)

It’s actually plain old generic GetComponent , but since angle brackets have a special meaning in HTML this gets rendered incorrectly. And apparently no one ever proofreads these posts, so there.

Hi ! I like this article, this clarifies a lot of things with Particle System Scripting.

I downloaded the new Unity 5.4 beta and it was said that there are new ways to deal with Particle System events in the code, but I can’t found the documentation related to this.
Can you tell me where ?
Thank you !

I wonder why “Random between two Constants” isn’t faster than “Random between two Curves”. I also wonder why “Random between two Constants” is so much more expensive than “Constant”. Finding a random point between two constants doesn’t sound like an expensive feature.

Comments are closed.