A Niagara authoring language for Unreal Engine
DreamFXLang
Describe Niagara effects in .dfs / .dfe / .dfm source files. The DreamFX plugin compiles them into standard UNiagaraSystem, UNiagaraEmitter and UNiagaraScript assets — and decompiles any existing Niagara system back into source. The text is the authoring surface; the asset is build output, and can always be thrown away and regenerated.
DreamFX · Text to UE Niagara
What it looks like
One file, one command, one Niagara system
A complete .dfs, not an excerpt. Module calls across the stacks, a user parameter, renderer properties — all of it text, and the build turns it into an ordinary UNiagaraSystem under /Game.
System(Name="Effects/NS_Hello", Root="Game"){ Properties = { float Speed = 150.0; } Emitter Motes { Settings = { SimTarget = CPU; Determinism = true; } EmitterUpdate = { EmitterState(LifeCycleMode = Self); SpawnRate(SpawnRate = 20.0); } ParticleSpawn = { SystemLocation(); AddVelocityInCone(VelocityStrength = User.Speed); } ParticleUpdate = { ParticleState(); GravityForce(Gravity = (0, 0, -400)); SolveForcesAndVelocity(); } SpriteRenderer Core { FacingMode = FaceCamera; } }}builds /Game/Effects/NS_Hello — no editor required
pwsh -File Plugins/DreamFX/.skill/dfx.ps1 build DFX/Effects/NS_Hello.dfs
Workflow
Text in, Niagara assets out — and back again
Generation is headless: one command, one asset. With the editor open, saving a source rebuilds it, so a Niagara preview window doubles as a live preview. The reverse direction is not a convenience export — it is a contract.
Source
.dfs declares a system, .dfe a reusable emitter, .dfm a module or dynamic input. Six stacks, event handlers, simulation stages, renderer properties and bindings — all of it is text.
Build
The commandlet parses, generates modules → emitters → systems, runs the Niagara compile, and stamps provenance on the asset: source hash, generator version, module version GUIDs.
Verify
A four-step CI: lint → build → verify → corpus. verify is the one that catches a source edited and committed without a rebuild — build alone can never see it, because build fixes it.
Round-trip
Decompilation is byte-for-byte idempotent, and anything the language cannot express is written into the file header as an explicit gap. Adopt re-exports and compares before taking an asset over.
Tooling
Plugin, command line, editor integration, agent skills
A menu is an entry point, never a second implementation: every button in the editor runs the same pipeline as the command line, and reports the same diagnostic codes.
DreamFX plugin
Parser, generator, decompiler, file watcher, Content Browser actions, toolbars — and -NoDreamFXEditor to turn the whole interactive surface off.
dfx.ps1 / ci.ps1
build · verify · lint · decompile · mirror-diff · asset-diff · coverage · schema · index · corpus, all runnable with the editor closed.
Four-layer round trip
L1 text, L2 mirror compile, L3 SimCache runtime equivalence, and asset-diff — reflection-walked facts that route around the exporter itself.
Agent skills
Four skills ship with the plugin: create, verify, diagnose, decompile — a coding agent can author and debug effects headlessly.
Documentation
Enter the docs from here
The homepage is for orientation; the docs hold the full reference. Pick the entry that matches the task in front of you.
Getting started
Check the plugin is on, write a first .dfs, and learn the save-and-rebuild loop.
Language reference
The three file kinds, the six stacks, the four value modes, and the eight L rules.
Events and stages
OnEvent handlers, named simulation stages, and the hard limits on each.
Generation and round trip
The build pipeline, provenance, decompilation, Export vs Adopt, engines and backends.
Diagnostics
All 143 DFXnnnn codes in eight families, each with its cause and its fix.
Changelog
What each release covers, plus the 1.0.0 known-issue list.