Niagara Content Examples

1.1 Simple Sprite Emitter

An example of a simple sprite emitter using a Niagara Particle System.

1.2 Simple Mesh Emitter

An example of a simple mesh emitter using a Nigara Particle System.

1.3 Simple GPU Emitter

An example of a simple GPU emitter using a Niagara Particle System.

1.4 Sprite Facing

An example of a sprite facing particle system. It demonstrates sprites that can face the camera, or that can face any arbitrary vector. In this example, the vector between the center of the system and the particle itself. That vector is then itself based on the age of the emitter to create spinning sprites.

1.5 Blend Attribute by Value

This example uses a dynamic value to control the distance between a particle and the emitter origin to blend between attributes, such as color, scale, rotation, and other parameters.

2.1 Static Beams

This example demonstrates using static beams spawned using static start and end points rather than dynamically updating per frame. Unlike Cascade, each beam segment is a simulated particle which can be further influenced by forces or other effects.

2.2 Dynamic Beams

This example demonstrates dynamic beams that have end points and tangents which are recalculated every frame. Use Play or Simulate to see the endpoints and tangents update in real time.

2.3 Multiple Renderers

This example demonstrates a Niagara Particle System that on simulation can be used to drive multiple renderers. This one shows a one point simulation driving a sprite, mesh, and ribbon renderer.

2.4 Location Events

This example demonstrates a location event that uses a lead particle emitter that sends its location as an event to the other two emitters in this particle system, allowing them to spawn that location. The event is sent at the very end of the frame after the particle's position and velocity are solved.

2.5 Expressions

Expressions are small snippets of HLSL that can be used to create micro behaviors in line in the stack without needing to create new modules. This example shows that no modules are used to influence the simulation, and only direct setting of variables in conjunction with expressions and dynamic inputs is used.

2.6 Collision

This example shows how to handle collision events being sent to a different emitter which spawns particles in response to that collision event. Collision queries are done with either line traces on the CPU or depth buffer/distance field checks on the GPU. The query results are saved and can also be used by subsequent modules.

3.1 Static Mesh Sampling

This example uses a static mesh placed in the world that can be sampled by the particle system. This includes sampling its attributes, such as normal, UVs, vertex color, sample position, and Actor velocity.

3.2 Renderer Overrides

In this example, each default attribute which the renderers use can be overridden by arbitrary data in the simulation. The sprite renderer used here is being given a new position as an offset from the arrow mesh position, and it is being driven by a different color attribute than the arrow mesh. Both are part of the same, single emitter.

3.3 Skeletal Mesh Reproduction

This example uses a single particle system with a sprite-based mesh reproduction using a method for accumulating multiple influences per particle. The event system and a post solve blend allows it to lerp between distinct behavior patterns.

3.4 Texture Sampling

This example demonstrates how textures can be referenced within a GPU particle system by mapping a texture to a grid of particles in the scene.

1. Spawn From Houdini Array

This example demonstrates the minimum set of modules needed to spawn particles from a Houdini array. In the emitter update section, you have the Spawn Particles From Array Playback that controls how many particles to spawn at each tick. In the Particle Spawn section, the Handle Spawned Houdini Particles sets the initial position of the particles and any other Houdini attributes in the Houdini namespace.

2. Spawn by Type

Similar to the 1. Spawn From Houdini Array stand, changes to the module in the Particle Spawn section handle Spawned Houdini Particles by Type to kill any particles that don't match the type attribute.

3. Simple Event

This example is similar to the 1. Spawn From Houdini Array stand with two major differences: 1, a system parameter has been added called User.MasterCSV that allows multiple modules to share the same CSV Asset, and 2, there are two emitters instead of one. The first reads the Houdini Array data and sends a location event. The second reads the location event. This is the basis for spawning more complex particle systems from the data provided by the Houdini Array.

4. Creating Custom Events

Building on the previous example, 3. Simple Event , to access custom data from the Houdini Array. You need to create a custom Event and Event Receiver module. It also needs a struct to hold the data sent and received by the event.

5. Interpolate Array

This example builds on 3. Simple Event and 4. Creating Custom Events . If the Houdini Array also had ID and Life attributes, the system can interpolate position through an extra module called UpdatePosFromHoudiniArray in the Particle Update section. A custom event is used to pass the CSV Index (ID) to the ribbon ID so that the second emitter creates a ribbon for each letter in this demonstration.