Particle system overview

Here you will find an overview of the high-level concepts of hh-fx particles, with some definition of common terms that will be used throughout this wiki, such as particle mediums, evolvers, samplers, etc...

For an overview of the editor's interface, see Editor interface overview.

Birth

hh-fx particles are added into the world through 'Particle spawners' When editing, spawners are seen in the realtime editor as Particle layers, and they contain the whole particle definition. A particle is defined by a list of properties, called 'Particle fields', They store things like Position, Color, Velocity, Life duration, etc... When added to the world, the particles are initialized by a Spawn script, before being added to a special particle container called a Particle medium. Particle mediums have a simulation definition, called an evolve state attached to them, telling the hh-fx runtime how to update the particles. Each evolve state contains a list of 'Particle evolvers'.

8 Particle spawners/layers in the treeview

Simulation

'Particle evolvers' are objects that take a list of particles each simulation frame, and applies some operation to them. Notable particle evolvers are the Physics evolver, the Rotation evolver, and also the Field evolver, that allows you to animate a particle property through time using a user-defined curve. For performance considerations, a particle medium will often contain particles coming from different instances of the same spawner, and even from instances of different spawners, that share the same simulation state. A spark effect with a single layer, spawning 10 particles, will use a single particle medium, that will contain 10 particles. If 10 000 instances of that spark effect are spawned into the game world, there will still be a single particle medium, that will contain all the 100 000 particles of all the instances.

Displaying particle-medium bounds in the realtime editor viewport

Rendering

Particles are rendered through 'Particle renderers'. As there are particle mediums for the simulation, there are particle render mediums for the rendering. A particle render medium can render one or more particle mediums. For example, if two particle layers have different evolve states, but share the same particle renderer (the settings are the same), then they will share the same render medium, and be rendered in a single geometry batch / draw call.

Mesh particle renderer

Advanced

Particle scripts can use 'Particle samplers', either to directly set into a particle field, or to use in some intermediate computation. Notable particle samplers are the Shape sampler, the Curve sampler, and the Procedural turbulence sampler. Particle events can be triggered when something special happens, such as when a particle is born, dies, or collides with the physical world. They can trigger the instantiation of other particle effects. The C++ runtime also allows user game-code to be notified when a specific particle event is triggered. Particle events are useful for many things, ranging from fireworks, to spawning sparks, decals or even sounds when particles collide with the world. Last but not least, Particle effect attributes can be defined. They are vector values global to a specific instance of a whole particle effect, and can be accessed from scripts anywhere inside any layer of the effect. Particle attributes are useful to allow gameplay code to control particle effects behavior on a per-instance scale.

Turbulence sampler, 120K particles

Debugging & Optimization

The effect editor also has a few debugging and optimization tools, namely: 1- The Performance budget indicators Displays easy-to-read rough performance/memory indicators for the current effect 2- The Trace report It allows you to mouse-pick any particle in the realtime viewport, and inspect its fields 3- The Particle history When activated, it records all the previous simulation frames, up to a maximum user-defined amount, and allows you to play them back and inspect them. 4- Some Performance warnings Telling you very explicitely when something unusual could badly hurt performance. 5- The Debug render buffers Not directly related to particles, but can be useful to see what's going on when rendering custom backdrops, if it doesn't produce the result you'd expect. Although not intended to be used directly by fx-artists (see the 'For developers' section in the main wiki page): 6- The Realtime profiler Allows accurate timing of code-sections, and allows to view an entire frame, and what took time computing. also helps tracking memory transactions and threading issues.

Particle-picking in the trace report mode