Create a Niagara System

A guided example: create a Niagara system, add an emitter and modules, set inputs, and compile a working effect.

This builds a working spark effect from nothing: create the system, add an emitter, stack modules on it, set their inputs, expose a user parameter so gameplay can drive it, compile, and spawn it in the level. Niagara is the largest command category in the product, and the pattern below is the one that matters, because Niagara is a stack rather than a graph.

Before you start

An Unreal Editor must be open with the plugin enabled. Confirm with cfa health_check.

1. Create the system

Start empty, or from one of Epic's templates when you want a working effect immediately and intend to modify it.

An empty system:

bash

cfa create_niagara_system --asset-path "/Game/VFX/NS_Sparks"

Or from a template:

bash

cfa create_niagara_system --asset-path "/Game/VFX/NS_Fire" --template "Fountain"

2. Add an emitter

The flag is --emitter-name. You can add a fresh emitter from a template, or inherit an existing standalone emitter asset, which keeps the child in sync when the parent changes.

Add an emitter from a template:

bash

cfa add_niagara_emitter --system-path "/Game/VFX/NS_Sparks" --template "Fountain" --emitter-name "Sparks"

Or inherit a standalone emitter asset:

bash

cfa add_niagara_emitter --system-path "/Game/VFX/NS_Sparks" --emitter-path "/Game/VFX/E_Spark.E_Spark" --inherit=true

See what is in the system now:

bash

cfa get_niagara_emitters --system-path "/Game/VFX/NS_Sparks"

3. Stack modules on the emitter

A module goes into a specific stage of the stack, so --script-usage is required and is the flag people miss. The common stages are EmitterSpawn, EmitterUpdate, ParticleSpawn and ParticleUpdate. A velocity module in the wrong stage compiles fine and does nothing visible.

Modules are referenced by asset path, not by short name. Search for the one you want rather than guessing the path:

Find a module by name:

bash

cfa list_niagara_modules --search velocity

Add it to the particle update stage:

bash

cfa add_niagara_module --system-path "/Game/VFX/NS_Sparks" --emitter-name "Sparks" --module-path "/Niagara/Modules/Update/Velocity/VortexVelocity.VortexVelocity" --script-usage ParticleUpdate

See the whole stack for an emitter:

bash

cfa get_niagara_modules --system-path "/Game/VFX/NS_Sparks" --emitter-name "Sparks"

4. Set module inputs

The flags are --module-name, --input-name and --value, and --script-usage is required here too so the right stage is targeted. Input names can contain spaces, so quote them.

List the inputs a module actually has:

bash

cfa get_niagara_module_inputs --system-path "/Game/VFX/NS_Sparks" --emitter-name "Sparks" --module-name "SpawnRate" --script-usage EmitterUpdate

Set the spawn rate:

bash

cfa set_niagara_module_input --system-path "/Game/VFX/NS_Sparks" --emitter-name "Sparks" --module-name "SpawnRate" --input-name "SpawnRate" --value 500 --script-usage EmitterUpdate

An input whose name has a space:

bash

cfa set_niagara_module_input --system-path "/Game/VFX/NS_Sparks" --emitter-name "Sparks" --module-name "VortexVelocity" --input-name "Velocity Amount" --value 400 --script-usage ParticleUpdate

5. Expose a user parameter

User parameters are how gameplay drives an effect at runtime without touching the stack. Expose one here and a Blueprint can set it on the spawned component.

Add a user parameter:

bash

cfa add_niagara_user_parameter --system-path "/Game/VFX/NS_Sparks" --parameter-name "SparkColor" --parameter-type "LinearColor"

See what the system exposes:

bash

cfa get_niagara_user_parameters --system-path "/Game/VFX/NS_Sparks"

6. Compile and verify

Compiling is what surfaces stack problems. Check errors and validate the stack rather than assuming a clean compile means a working effect.

Compile the system:

bash

cfa compile_niagara_system --system-path "/Game/VFX/NS_Sparks"

Read any errors:

bash

cfa get_niagara_system_errors --system-path "/Game/VFX/NS_Sparks"

Validate the stack for issues:

bash

cfa validate_niagara_stack --system-path "/Game/VFX/NS_Sparks"

7. Put it in the level

Spawn the effect at a location:

bash

cfa spawn_niagara_effect --system-path "/Game/VFX/NS_Sparks" --location "[0,0,200]"

Check particle counts while it runs:

bash

cfa get_niagara_particle_stats --system-path "/Game/VFX/NS_Sparks"

When it does not work

The module was added but nothing changed. Almost always the wrong --script-usage. A module in EmitterUpdate that belongs in ParticleUpdate compiles happily and does nothing. Check the stack with get_niagara_modules.

Setting an input had no effect. The input name did not match. Run get_niagara_module_inputs for that module and use the name exactly as returned, including spaces.

Nothing renders. An emitter with no renderer produces no visible particles. Check with get_niagara_renderer_info and add one with add_niagara_renderer.

The module path was rejected. Modules are addressed by full asset path, and many live under /Niagara/Modules/ with a duplicated name segment, as in VortexVelocity.VortexVelocity. Get the path from list_niagara_modules rather than typing it.

Scratch pad HLSL

When no stock module does what you need, the assistant can write a scratch pad module in HLSL directly, then apply and compile it. See create_niagara_scratch_pad_module and set_niagara_scratch_pad_hlsl in the Niagara reference, which lists every stack, renderer, event and parameter operation.

Loading…

PreviousAuthor a Material Graph NextRig a Character with AI