Introduction to the Particle System

Introduction

A particle system in general is a framework to create and control visual effects in your application. It "is a technique in game physics, motion graphics and computer graphics that uses many minute sprites, 3D models, or other graphic objects to simulate certain kinds of fuzzy phenomena, which are otherwise very hard to reproduce with conventional rendering techniques - usually highly chaotic systems, natural phenomena, or processes caused by chemical reactions" (cited from ​Wikipedia's Particle System entry). Particle effects can be 3D and 2D, can be purely aesthetic or visualize a dataset, can be randomized or react to several inputs like user interaction.

In Ventuz there are several use cases for a particle system, some of which are:

• Create visually appealing high resolution backgrounds. It might be a lot faster to render a background in real-time than to render it to a movie and play that back - especially at high resolutions. Also the background can react to real-time inputs, like touch and thus make your application appear a lot more responsive to the user.
• Create visually appealing representations of big data sets. There are Emitters and Modifiers that directly pass a set of data to your particles. Furthermore particles can react to touch input using the Touch module.
• Create small visual effects like rain, fireworks, smoke or flames.

See the Particle Presets demo project in the Project Browser for a lot more examples.

This document will cover a basic introduction of the Particle System, its limits, differences between the Functional- and Simulated Particle System, module order and sorting, and lastly the explanation of Fretboard. For an in-depth overview of each and individual module please refer to the modules list for the particle system.

Create a Particle System

There are two different presets to create a Particle system. You will find the Particle System node and the Particle System - (Source + Sprite) node available to select from.

The Particle System will create a simple and empty particle node which has no inline stream nor any kind of module or modifier. You would need to create the inline stream and the according modules on your own, you start with the very basic empty particle system in this case. The Particle System - (Source + Sprite) starts with a very basic system, which contains of an emitter (Source) and a renderer to at least create a basic fontain without gravity. The last system is used to have a rough starting point and is good for basic "try outs". The mentioned Inline Stream is basically where you start a particle system in. The stream goes from module to module and therefore changes or alters the behavior of a particle - they read and write to the attributes. Basically the most compact stream would be the Particle System (Source + Sprite), it contains as mentioned above just of a source emitter and a renderer. Therefore the stream would look like : Particle got born - "emitted", has basic values like lifetime, size and direction and got "rendered"... and hence the lifetime it will die. As another alternative to understand the inline stream or the stream itself the section for the fretboard would be a good further reading.

Differences Functional-/ Simulated System

The simple differences from a designers perspective between a functional and a simulated particle system is that you would be able to scrub the particle time in a functional system. This makes it possible to pause, forward and play the particle system also backwards. This way you can have an explicit timing possible - you have full control over the timing. You would enable the timing control by using the EnableFunctionalTimeOverride boolean and use the FunctionalTimeOverride value to scrub or animate the time.

A simulated particle system can be created by simply using the according module for it - Simulation. As soon as you use the module Simulation the Functional Override or the Functional System will no longer work. Enabling the Time Override and Scrubbing will be ignored and have no effect. With a simulated system you can now use the Collision- and Curl Node, as well as some more which would need to have a simulated system. The reason is the difference in the Particle system internal calculation. A Simulated Particle System will need to calculate the next frame for the single particle based on the attributes from the last simulation step (or frame), therefore it is possible to have a collision or bounce from a collision plane only if we can change the velocity-, speed- and direction change based on the actual frame. The information for such are stored on a per frame basis. These information can then be used for the next frame to estimate the new position and behavior for the particle. This calculation is then called a Simulation loop.

You might be confused why it is possible to still have Modules or Modifiers behind the simulation loop. Keep in mind that the attributes are written only until the point where it reaches the Simulation module. Therefore it is still possible to modify the attributes for a particle, but they will not be written. That way you can decide what attributes should get written and kept for the next simulation loop.

At this point it is important how you sort/order the modules. This is covered in the modules subsection and for the Modifiers you can find relevant information in the modifiers subsection of this page.

The Fretboard

The above Image shows a typical Fretboard from an example Particle System. The Fretboard is made to help you understand whats happening inside the Particle System and guides you which module uses a certain channel and modifies that, such as the Position, Velocity, Age, Color, Alpha, Size and so on. The Fretboard can be read and understood as follow: On the very left side you mostly see an emitter - even a secondary emitter which is depending on an already existing stream. On the very right side you see the used and available channels, for example Age:

The Source particle starts with an Age, the Age is used for several modifiers, like the Gravity, and three times by the Gradients. In the case for the Gradients you can see that the Source is the Age and the Target for each Gradient is Size and two times for the ColorAlpha. That means for the over time (Age) the color or alpha (ColorAlpha) will change for the particles. So by analyzing the Fretboard you can see what individual channels control or where they are used for - at which point a value gets grabbed and modifies something else.

Modules

Our Particle Systems is made of Modules. These Modules are grouped into categories like Emitters, Renderers, Specials and Modifiers. Also take note that you always would start with an Emitter to generate particles and would need to have at least one Renderer to render the generated particles.

Emitter

Emitter are the base for each and every particle system. The most common used are Source, Secondary, Grid, Mesh and Path the others are mostly used in certain conditions, like for example the DataEmitter which is used when using data visualisation from external data. An Emitter is always needed since this will create or generate the particles. A full list of all the available Emitter can be found here.

Modifier sorting and order

The right hand list (indicated by green icons) are the Modifiers - these really modify the attributes for a particle stream. A Modifier therefore writes into the particle attributes at the position it is placed. So there is a chance that the order of several modifiers may affect the appearance of a particle depending on their arrangement. There are certain Modifiers that require to be used inside the Simulation loop. Such a Modifier is the Curl Modifier. You would get a red error message indicating that the modifier needs to be sorted inside the loop. To do so, you can simply drag&drop  the Modifier Module into another place (preffered inside the simulation loop) or select the module and press CTRL +  ← / →.

You will notice there seems to be no way to use a Gradient Modifier module inside a simulation loop - the reason is simple: If you would use a specific color inside the loop it will use the modifiers default operation, which is Add. This would cause the color to add up each simulation loop it passes on the old color value and therefore it would result in black very quickly. This can be prevented by using the Operation: Overwrite - this will overwrite each simulation loop the colorvalue with the selected one.

Path - Follow and Emitter

The Path Emitter can use any 2D SVG ,3D imported- or vpath to generate particles from. There is an option to use multiple paths. The difference is that the particle system will take for example a text as a single path or each indiviual letter. If you shorten the Extend value to 0.5 animate the Mid value from the Path Emitter you can see the particles emitting as a flow from letter to letter:

If you check the MultiplePaths property you can see that each individual letter will emit particles at once:

Mesh Emitter

The Mesh Emitter will generate particles from each available vertex. You can choose to use animated geometries as well.

Secondary Emitter

The Secondary Emitter makes it possible to hook another stream onto an existing particle by using the LinkName. This way it is possible to create trailing particles, which follow a single particle which has been emitted by another emitter. If you combine the Secondary emitter with events from another module you can trigger the burst of the secondary emitter to emit particles as well. A good example of this is a raindrop creating a splash when it hits the ground or a firework rocket. Please refer to the Buffers and Events section in this document.

Interaction

Touch interaction

With the Touch interaction module it is possible to fire an event if you touch a particle, get the position, or have a specific feedback. For example, to get the !ParticleID you would set the FeedbackSelect : ObjectID. This way you can link a anything to the output of the Particle System and receive a FeedbackValue (Float) which reads the touched Particle/ObjectID.

Basic interaction / transformation

You can use the Transform property to change for example the position of a particle system. One of the best use cases is to have the Particle System follow your mouse position. To do so you can bind the X/Y/Z values of the particle system transformation to your actual mouse cursor position. Another useful option is to use the Anchor and the Anchor node instead of a manual transform.

The best result for a moving particle system would be a simulated particle system, since the particle source only will follow your mouse, and the already emitted particles will stay in place.

Buffers and Events

Buffer

With a Buffer you can write the particles attribute to access it from the same stream at another point or a complete different inline stream. Modules that can create and write into a buffer are the Simulation and LinkOut. For these modules you have the option to set a LinkName. This creates a named buffer and the attributes can then be accessed by using an according module which rely on the same name, for example the secondary emitter or the Link in module.

Event

The particle system has an internal event system which you can use for several use cases such as firing the burst for another inline stream. Events can be fired from a Collision-, Simulation- and Touch module.

You would need to enable the send of the events by set the appropriate boolean and set a unique name for the buffer to write the event into (Out2).

A receiver for such events could be a Secondary stream, which would fire the burst for this stream - in this case whenever the event named Out2 has been fired.

Events can be send upon a hit on the collsion or a bounce off the surface, if a particle is dead because its lifetime is exceeded or manually by using the Touch module.

Conclusion

This is just a very basic overview of the Particle System. See the Particle System Reference Page for a more in-depth look at its exact work-wise. Also make sure to learn about Real Time Rendering to not only learn about its advantages but also about the problems that might arise while working with real-time graphics. Particle Systems can get performance hungry very quickly - so keep a close look at the Performance Statistics as well.

Copyright 2025 Ventuz Technology