Use this skill when working with Niagara particle systems, VFX, effects, emitter, Niagara component, or Niagara parameter in Unreal Engine C++. Covers spawning systems, setting parameters, data interfaces (SkeletalMesh, StaticMesh, Curve, Array), OnSystemFinished delegate, and performance tuning. Se

UE Niagara Effects You are an expert in controlling Unreal Engine's Niagara VFX system from C++. Context Check Read .agents/ue project context.md before proceeding. Confirm: The Niagara plugin is listed under enabled plugins ( Plugins/FX/Niagara ). The target module's Build.cs has "Niagara" (and optionally "NiagaraCore" ) in PublicDependencyModuleNames . Platform targets: note whether mobile or dedicated server builds are in scope, because Niagara is typically suppressed on dedicated servers and may need LOD simplification on mobile. Information Gathering Before writing Niagara C++ code, clarify: 1. Effect lifecycle — one shot (fire and forget) or persistent / looping? 2. Parameter needs — which Niagara User Parameters must be set from gameplay (positions, colors, scalars)? 3. Data interfaces required — SkeletalMesh, StaticMesh, Curve, Array, or custom? 4. Simulation target — CPU or GPU sim? (affects which DI features are available) 5. Performance budget — pooling required? Mobile scalability tier? 6. Completion handling — does gameplay need a callback when the effect finishes? System Structure (UE Concept Map) Key rule : authors expose parameters to C++ by setting their namespace to User. in the Niagara editor. Only User. parameters can be overridden at runtime from C++. Spawning Niagara Systems Fire and Forget (One Shot) at World Location Attached to a Component (Persistent / Looping) Persistent Component on an Actor (Preferred for Repeated Use) Lifecycle Control Setting Parameters from C++ All setter variants accept the parameter name as FName prefixed with its namespace. User exposed parameters use the User. prefix. Blueprint Accessible Legacy Signatures (prefer FName variants above) Parameter Namespaces Reference Namespace prefix Settable from C++ Description User. Yes User exposed; main runtime override System. No (read only) System level built ins (Age, DeltaTime, etc.) Emitter. No (internal) Per emitter variables Particle. No (internal) Per particle variables See references/niagara parameter types.md for the full C++ type to Niagara type mapping. Data Interfaces from C++ Data interfaces (DIs) are UObject derived assets that expose structured external data to Niagara scripts. They appear as User. parameters of DI type in the Niagara editor, and are overridden at runtime via SetVariableObject or the specialized function library helpers. Binding Skeletal Mesh DI Binding Static Mesh DI Reading / Modifying an Array DI at Runtime Direct DI Object Access (Advanced) See references/niagara data interfaces.md for the full built in DI catalogue. Custom Data Interfaces : Subclass UNiagaraDataInterface , override GetFunctions() to define available functions, GetVMExternalFunction() to bind C++ implementations, and optionally ProvidePerInstanceDataForRenderThread() for GPU access. Register in the module's StartupModule . This enables game specific data (inventory, terrain) to feed directly into Niagara systems. Completion Callbacks Performance: Pooling ENCPoolMethod controls the pool behavior on every spawn call: AutoRelease — component returns to the world pool automatically when the system finishes. Pass bAutoDestroy=true ; the pool handles actual reclaim. ManualRelease — you control when the component returns; call ReleaseToPool() to reclaim. None — no pooling; component is destroyed when finished if bAutoDestroy=true . Pool capacity is configured per system in the UNiagaraSystem pooling settings (not a global CVar). Relevant global pool CVars: FX.NiagaraComponentPool.Enable (1/0) and FX.NiagaraComponentPool.KillUnusedTime (seconds before idle components are culled). Performance: Scalability and LOD Scalability per platform is configured in the UNiagaraEffectType asset assigned to the UNiagaraSystem . The effect type defines quality tiers (Low / Medium / High / Epic) and which emitters are stripped at each tier. This is data driven; no C++ changes needed per platform. GPU vs CPU simulation trade offs : CPU sim: particle data is readable/writable from C++ each frame; lower particle counts; supports all DI types. GPU sim: supports hundreds of thousands of particles; DI support is limited (not all CPU side DIs have GPU equivalents); particle data is not readable back to CPU without readbacks. Determinism : GPU simulations are inherently non deterministic. For multiplayer VFX that must match across clients, use CPU simulation with FixedTickDelta on the emitter. Cosmetic only effects should spawn client side only — skip them on dedicated servers entirely. Warm Up, Server Handling, and Events Pre simulation (warm up) : seek to a desired age before the effect is visible. Dedicated server : SpawnSystemAtLocation returns nullptr on dedicated servers. Always null check the returned component and guard VFX spawns with !IsRunningDedicatedServer() where needed. Gameplay events to Niagara : Niagara's internal event system (Location Events, Death Events, Collision Events) is configured in the Niagara editor between emitters. From C++, trigger a gameplay driven burst by updating a User bool parameter that the spawn script reads: Required Build.cs Common Mistakes and Anti Patterns Spawning a new system component every tick Wrong parameter namespace Type mismatch between C++ and Niagara Setting parameters after system completes Forgetting to check nullptr on spawn (especially on server) Not removing delegates before destruction Niagara Fluids (experimental) : The Niagara Fluids plugin provides GPU based fluid and gas simulations. It is experimental, GPU only, and carries a high performance cost — profile carefully before shipping and restrict use to hero effects where visual impact justifies the budget. World space vs local space : Use local space simulation for effects attached to moving actors (particles inherit the parent component's transform and move with it). Use world space simulation for effects that should remain stationary after emission (e.g., a ground impact crater where particles should not follow a moving actor). The space setting lives on each emitter in the Niagara editor. Related Skills ue actor component architecture — component creation, attachment, lifecycle ue materials rendering — particle material setup, dynamic material instances ue cpp foundations — UObject lifetime, delegates, UPROPERTY references

ue-niagara-effects