I teamed up with my friend and veteran Unity user Attila Malarik to make a particle system for Unity: It’s called Another Modular Particle System or “Amps”.
Attila handles the lower level tasks (framework, resource management, etc), I cover high level system design and UX and when it comes to the middle layer (creating the reusable building blocks) we will share the work as we go.
The user interface
I’ve just finished the first iteration of the editor window. The controls are not linked to anything yet but the layout reflects the base idea behind Amps:
A particle emitter itself is a component on a GameObject. (So a particle system contains exactly one emitter so I’ll use those terms interchangeably.) The emitter has several stacks defining it’s behavior as seen on the left most column. Each stack can contain any number of modules and each module has several properties. While simpler property types can be edited right in the property list more complex ones get dedicated value pickers.
Now let’s see each part a bit closer.
Stacks
The Emitter stack is a special one as it contains exactly one module for setting up the particle system. Particle limits, LOD configuration, update rate and similar properties belong here.
The Rendering stack can contain one or more rendering modules which define how the abstract particle data is displayed. Point, arrow, sprite, ribbon and mesh modules are typical examples but it should be possible to extend the system beyond that including skeletal meshes for a very crude crowd simulation.
External Influences is about entities outside the particle system which affect it’s properties. For instance colliders directly change particle position, wind zones affect acceleration, color volumes adjust particle color.
The Spawn Condition stack defines when to spawn particles. If any of the modules in there return ‘true’ then a spawn cycle is initiated. Such a cycle lasts as long as the result of the Spawn Duration stack and will produce as many particles as indicated in Spawn Amount.
The next stack group deals with particle removal in a similar fashion: when to kill one and how long it will take for them to die.
The yellow stacks represent the standard set of particle attributes.
Typical usage scenarios for each stacks will be covered in separate articles so now let’s move on to the second column, the modules list.
Modules
Data flows downward between modules: the result of the first one is modified by the second one and so on like an upside down Photoshop layer stack. Also somewhat similar to PS is that modules generally have Weight and Blending mode properties which define how they change the result arriving from above them. Certain types of modules (like math operations) don’t have blending modes only weight. Another permanent property is the Description field where the user can take notes regarding the function of the module. It is a very important feature which keeps even complex particle systems easy to read.
The properties feed the internal mechanics of the module which – combined with the result of earlier ones – produce a single value to be passed on. Internally modules are treated as black boxes: they take a standard set of input parameters, create their own UI representation and eventually produce a vector4. This way third parties will be able to extend the system simply by following a few design rules.
Modules can be added, disabled, duplicated, instanced, rearranged, and deleted in this list view. Their properties are edited in the property list.
Properties
A module can contain any number of properties. They are grouped into logical units and frequently used properties are displayed at the top for easier access.
There are several property types: bool, integer (dropdown menus), string, scalar, vector4 and color. (The last one is really just a vector4 represented differently to the user.)
Scalars, vectors and colors can have a constant value, a random constant, a curve or a random curve. These more complex definitions have their dedicated value pickers in the right most column.
Value pickers
Here are the currently functional value pickers:
Random scalar |
Scalar curve |
Random scalar curve |
Vector |
Random vector |
Color |
The color picker is a replacement of the inbuilt one which doesn’t support high dynamic range values. (The three part color preview strip shows the clamped color, the tonemapped one and the visual alpha.)
I’ll also have to create our own curve editor because the default is rather limited: unable to display multiple curves at once, presets can’t be changed, there is no numeric input for the selected key.
And that concludes this introduction to Amps. If you have any questions or suggestions please don’t hesitate to contact me.
