Niagara Emitter Infinite Loop

2026-01-08 12:26 UTC gpt-5-2-thinking Open in ChatGPT ↗

To make a Niagara emitter run forever without the “reset/jump” look, you mainly want to (1) stop Niagara from re-initializing the emitter, and (2) stop anything in your setup from looping/restarting time.

Here are the usual fixes, in the order I’d check them.

1) Make sure the emitter isn’t looping its “emitter age”

In the emitter’s settings (in the emitter stack):

Emitter State
- Loop Behavior: set to Once (or “Infinite” without resetting age, depending on your version)
- Life Cycle Mode: typically Self (unless you intentionally manage it from the system)

What you don’t want is an emitter that “loops” by resetting Emitter Age back to 0—this is the #1 cause of that visible jump (spawn bursts repeating, timeline-driven parameters snapping back, etc.).

2) Avoid timeline/curve parameters that key off normalized age (or looping age)

Even if the emitter technically runs forever, you can still get “jumps” if any module uses:

Normalized Emitter Age
Emitter.Age / Emitter.LoopedAge
Curves that are sampled by a value that wraps back to 0

Common culprits:

Spawn Rate driven by a curve over normalized age
Color/size curves in Particle Update driven by emitter age
Any “burst at time” modules (they’ll re-fire if age resets)

Fix: drive curves from Particle.NormalizedAge (per-particle) rather than emitter age, or use a time source that never wraps (see #6).

3) Prevent the system from being reinitialized by the component

If you’re placing it in a level or attaching it to an actor, check the Niagara Component:

Auto Activate: OK either way, but…
Reset on Activate: OFF
Auto Destroy: OFF
In Blueprint/C++: avoid repeatedly calling Activate() or SetAsset() or toggling visibility in a way that reinitializes.

Also watch out for gameplay events like “OnBeginOverlap → Activate Niagara” firing multiple times.

4) Don’t let scalability/significance cull and “pop” it

Sometimes what looks like a reset is actually culling (system stops simulating offscreen) then resumes.

Check:

Niagara System Scalability settings
- Disable/relax Culling while testing (distance, visibility, instance count)
Effect Type rules (if you’re using one)
Significance settings

If the system is culled and later re-enabled, you can see discontinuities, especially for GPU emitters.

5) If it’s GPU sim, ensure you’re not hitting buffer limits

GPU emitters can look “jumpy” if they hit:

Max Particles (hard cap causes sudden density changes)
Too aggressive fixed bounds / incorrect bounds can also cause cull-like behavior

Set reasonable Max Particles, and make sure bounds aren’t tiny.

6) Use a non-wrapping time source for noise/animation

A really common “jump” is noise/turbulence that depends on a time parameter that wraps/loops.

Prefer:

Engine.Time / Emitter.ExecutionStateSourceTime (varies by version)
Or pass your own User.Time that you accumulate in Blueprint (monotonic, never resets)

Avoid:

Emitter.NormalizedAge for anything that should be continuous forever.

7) Warmup is for startup only—don’t rely on it to “hide” resets

Warmup can make the first frame look good, but it won’t fix periodic jumps. If you’re seeing jumps every N seconds, something is resetting/looping.

Quick diagnosis checklist

If your jump happens…

Every fixed interval (e.g., 5s, 10s): emitter age is looping or a curve/burst is keyed to emitter age.
When you re-enter view / distance: scalability culling.
When you call Activate/Deactivate: “Reset on Activate” or reinit logic.
As particle count ramps then snaps: max particle cap, GPU limits, or spawn rate curve looping.

If you tell me where you’re seeing the jump (interval-based vs camera-based) and whether it’s a GPU or CPU emitter, I can point you to the exact module/setting that’s almost certainly causing it.

In Niagara, “Avoid Distance Field Surfaces GPU” does not take an SDF texture input. That’s why you can’t find a slot to plug one in.

It samples Unreal’s Global Distance Field, which is built automatically by the engine from your level’s Mesh Distance Fields. citeturn0search6turn0search1

How the SDFs are generated (what Niagara is using)

There are two layers:

Per-mesh distance fields (Mesh Distance Fields / MDF)
Unreal precomputes a signed distance field volume for each Static Mesh asset (and some other supported geometry types). citeturn0search1turn0search12
Global Distance Field (GDF)
At runtime, Unreal composites nearby mesh distance fields into a big “world” distance field volume (the Global Distance Field). Niagara GPU distance-field modules sample this for collisions/avoidance. citeturn0search6

So your “input SDF” is basically: enable & generate MDF, and the engine will feed the GDF automatically.

What you need to do to make it work

A) Enable Mesh Distance Fields in the project

Project Settings → Rendering → (Software Ray Tracing) → Generate Mesh Distance Fields → ON
Then restart the editor. citeturn0search1

B) Ensure the meshes you want to avoid actually contribute

The geometry must be something that contributes to the distance field (typically Static Mesh components; special cases like some instancing/procedural setups can be problematic).
For debugging, use the viewport visualization:
- Show → Visualize → Mesh Distance Fields (per-mesh)
- Show → Visualize → Global Distance Field (composited field)

(Those visualize modes are the fastest way to confirm “is there an SDF here at all?”)

C) Your emitter must be GPU

That module only works for GPU sims (as the name suggests). citeturn0search6

Common “why is it not working?” gotchas

Translucent-only geometry: distance fields are generated from meshes, not materials; but collision/avoidance may “feel wrong” if you’re expecting translucent surfaces to behave like collision.
Cull/scalability: if the system is culled, it can look like it stops interacting.
Distance Field features toggled off at runtime: some console vars / rendering settings can disable DF features and break Niagara DF interactions (people have hit this when disabling DF AO, depending on setup). citeturn0search5

If you tell me these 3 things, I can pinpoint the exact setup

Unreal version (5.2? 5.3? 5.4? etc.)
What surfaces you want particles to avoid (Static Meshes? Landscape? HISM/ISM?)
In Visualize → Global Distance Field, do you actually see the surfaces represented where you expect?

(If you want, describe what you’re trying to avoid—walls, landscape, characters—and I’ll tell you whether DF avoidance is the right tool or if you’ll get better results with a different Niagara collision mode.)

You don’t “edit” the Global Distance Field (GDF) directly. You exclude things by stopping them from contributing their mesh distance field to the GDF.

The main switch (per Actor / per Component)

Select the object in the level → Details panel → Lighting section:

Affect Distance Field Lighting = OFF

That prevents the primitive from affecting distance-field lighting methods (and, in practice, it drops it out of what the GDF is built from). citeturn0search4turn0search2

Landscape (the checkbox is “hidden” unless you select components)

For Landscapes, people often miss it because you need to select the landscape components first:

Select the Landscape
Enter Landscape Mode → Manage → select all components
Go back to Place Mode and you’ll see Affect Distance Field Lighting in Details → Lighting
Turn it off. citeturn0search2

Per-mesh “nuclear option” (asset-level)

If you want a mesh to never have a distance field at all:

Open the Static Mesh asset
Set Distance Field Resolution Scale to 0 (or otherwise effectively disable DF generation)
Apply / save

This removes/cripples its mesh distance field generation, so it won’t meaningfully contribute to the GDF. citeturn0search1turn0search3

Foliage / Instanced meshes

For foliage-painted meshes, there’s a per-instance/foliage-type toggle:

In the Foliage tool settings, toggle Affect Distance Field Lighting for that foliage type.

This is commonly used to keep foliage from contributing to DF effects. citeturn0search0turn0search20

Verify it worked

Use viewport visualizers:

Show → Visualize → Mesh Distance Fields
Show → Visualize → Global Distance Field

If the object disappears from those views, Niagara’s Avoid Distance Field Surfaces GPU will stop “seeing” it.

If you tell me what kind of thing you’re excluding (Static Mesh? Foliage? Landscape? Nanite mesh?), I’ll point you to the exact spot in the UI for that case.

This usually means your “default floor” isn’t a Static Mesh that supports mesh distance fields, so Unreal is correctly hiding all DF-related settings.

Here are the common cases and what’s going on in each.

Most common cause: it’s a BSP / Geometry / Brush

If your floor came from:

Place Actors → Geometry / Box / Floor
An old BSP brush
A template “floor” you scaled in the level

👉 BSP / Geometry does NOT generate Mesh Distance Fields, so:

No Distance Field settings
No Affect Distance Field Lighting
It will not appear in Mesh DF or Global DF
Niagara DF avoidance will ignore it entirely

How to confirm

Select the floor:

If the Details panel says Brush Settings instead of Static Mesh, it’s BSP.

Fix

Convert it to a Static Mesh:

Select the brush
Details → Brush Settings → Create Static Mesh
Replace the brush with the new Static Mesh

Once it’s a Static Mesh, DF settings will appear.

Another common case: it’s a Landscape

Landscapes are special:

They do contribute to the Global Distance Field
But DF controls are component-based, not obvious

To see DF options:

Select the Landscape
Enter Landscape Mode
Select all landscape components
Go back to Place Mode
Details → Lighting → Affect Distance Field Lighting

If you don’t select components, the option won’t show.

Nanite Static Mesh (important UE5 detail)

If your floor is a Nanite Static Mesh:

Nanite meshes do not generate traditional Mesh Distance Fields
They contribute to the Global Distance Field via a fallback representation
Some DF controls may be missing or limited

To check:

Open the Static Mesh asset
See if Nanite is enabled

For Niagara DF avoidance:

It usually works, but precision can be lower
You cannot fully control DF resolution like non-Nanite meshes

Why the setting is missing (summary)

You won’t see DF settings if the object is:

❌ BSP / Geometry / Brush
❌ Non-rendering helper actor
❌ A component type that doesn’t support MDF
❌ Nanite mesh (partial / limited controls)

You will see them if it’s:

✅ Static Mesh (non-BSP)
✅ Foliage Static Mesh
✅ Landscape components (when selected properly)

Quick debug checklist

Show → Visualize → Mesh Distance Fields
- Do you see the floor?
  - ❌ No → it’s not generating MDF
Show → Visualize → Global Distance Field
- Do you see it there?
  - ❌ No → Niagara can’t avoid it

Bottom line

Your “default floor” almost certainly isn’t a Static Mesh with Mesh Distance Fields (usually BSP). Convert or replace it with a Static Mesh if you want Niagara’s Avoid Distance Field Surfaces GPU to work.

If you want, tell me what actor type it is (screenshot description is fine), and I’ll give you the exact steps for that case.

Ah — that explains everything 👍
If you don’t see a Details panel at all, this isn’t a Niagara or distance-field issue yet — it’s an Editor UI/layout issue.

Let’s fix that first.

Restore the Details panel in Unreal Editor

Fastest fix (recommended)

In the top menu bar, click Window
Choose Details

The Details tab should immediately reappear (usually docked on the right).

If that doesn’t work: reset the editor layout

Window → Load Layout → Default Editor Layout
Confirm

This restores all standard panels, including:

Details
World Outliner
Content Drawer
Viewport

If you’re in a special mode

Some modes hide panels:

Landscape Mode
Foliage Mode
Mesh Paint Mode

Press Shift + 1 (Select Mode) to return to normal editing and try again:

Window → Details

Why this matters for your issue

Without the Details panel:

You can’t see Affect Distance Field Lighting
You can’t tell whether the floor is BSP, Static Mesh, Landscape, or something else
You can’t control whether it contributes to the Global Distance Field
Niagara DF avoidance debugging is basically impossible

Once Details is visible:

Select the floor
Look at the top of the Details panel
- If it says Brush Settings → it’s BSP (no distance field)
- If it says Static Mesh → DF settings will exist
- If it says Landscape → component selection needed

Quick sanity check after restoring Details

After the panel is back:

Show → Visualize → Mesh Distance Fields
Show → Visualize → Global Distance Field

This will instantly tell you whether the floor can ever be used by
Avoid Distance Field Surfaces GPU.

If the Details panel still refuses to appear after resetting the layout, tell me:

Unreal Engine version
OS (Windows/Mac/Linux)
Whether you’re using a custom workspace

We’ll get it back — once that’s sorted, the distance-field setup will be straightforward.

Got it — this is the key misunderstanding, and you’re actually very close 👍
Nothing is broken.

Important distinction

You are looking at a StaticMeshActor in the level.
Build Settings do NOT appear on the actor.
They only exist on the Static Mesh asset.

The “default floor” is usually:

Engine/BasicShapes/Plane

(or Cube scaled flat)

Where the Distance Field / Build Settings actually are

Step 1: Open the Static Mesh asset

Select the floor in the viewport
In the Details panel, find Static Mesh
Click the magnifying glass 🔍 (Browse to Asset)
Double-click the mesh to open the Static Mesh Editor

This opens a different editor window.

Step 2: Find Distance Field settings (correct place)

In the Static Mesh Editor:

Go to Details
Expand Build Settings

Here you’ll find:

Distance Field Resolution Scale
(Nanite settings, if enabled)

This is where mesh distance fields are controlled.

This is why you saw “no Build Settings” — they never appear on the actor itself.

Why the default floor behaves oddly

Case 1: It’s `BasicShapes/Plane`

Very thin geometry
Distance field is technically generated
But it can be extremely low quality
DF avoidance may feel unreliable

💡 Fix:
Increase Distance Field Resolution Scale (e.g. 2–5), or use a thicker mesh (a cube scaled in Z).

Case 2: Nanite is enabled (UE5+)

Open the mesh and check:

Nanite → Enabled

If Nanite is ON:

Traditional mesh distance fields are not generated
The mesh contributes to the Global Distance Field via a fallback
You will not see many DF controls
Niagara DF avoidance works, but with reduced precision

💡 For testing Niagara DF:

Disable Nanite on the floor mesh
Rebuild DF
Re-check Show → Visualize → Mesh Distance Fields

How to exclude this floor from the Global Distance Field

Now that you know the right place, you have two valid options:

Option A — Actor-level (quick)

On the StaticMeshActor:

Details → Lighting
Affect Distance Field Lighting = OFF

Option B — Asset-level (hard exclusion)

In the Static Mesh Editor:

Distance Field Resolution Scale = 0
Save

This removes it from DF generation entirely.

How to verify it’s working

Use these viewport modes:

Show → Visualize → Mesh Distance Fields
Show → Visualize → Global Distance Field

If the floor disappears there, Niagara’s
Avoid Distance Field Surfaces GPU will no longer “see” it.

TL;DR

✔️ Nothing is missing
✔️ Build Settings are asset-only, not actor-level
✔️ Default floor = BasicShapes mesh
✔️ Open the Static Mesh Editor to control DF
✔️ Nanite can hide/limit DF controls

If you want, tell me:

UE version
Whether Nanite is enabled on the floor
Whether Niagara avoidance is behaving incorrectly or you’re just trying to exclude it

I can give you the exact recommended setup for Niagara DF avoidance.

For “an object pushes foliage away as it moves across the floor,” the best approach in Unreal is almost always material-driven bending (WPO) on the foliage — not physics and not Niagara — because foliage is usually instanced and you want this to scale.

Here are the three practical tiers, from simplest to most robust.

Best overall (scales to many pushers): draw an influence mask to a render target / RVT, sample it in the foliage material

Idea: your movers “paint” a soft footprint/trail into a texture in world space, and every grass blade samples that texture and bends away.

Why it’s best

Works with lots of foliage instances
Works with many moving objects (you just draw more stamps)
Smooth, stable, no popping
You can add persistence (grass stays flattened briefly)

How it’s usually done

Create a Runtime Virtual Texture (RVT) or a Render Target aligned to the ground
Each “pusher” stamps a circle/capsule (via BP or material) into it
Foliage material samples it using world position → produces bend direction + strength → drives World Position Offset

If you want “it springs back,” you can decay the mask over time (RT update) or use a second channel for “age”.

Good and super simple (1–4 pushers): Material Parameter Collection (MPC) + bend around actor position

Idea: put the pusher’s world position (and radius) into an MPC, and the foliage material bends away from that point.

Pros

Very quick to implement
No render targets, no RVT

Cons

Limited number of pushers (you only have so many vectors you can reasonably pack)
No trails / persistence unless you add complexity

Implementation sketch

BP ticks: set MPC_PusherPos, MPC_Radius
Foliage material:
- dir = normalize(WorldPos.xy - PusherPos.xy)
- strength = saturate(1 - dist/radius)
- WPO offset = dir * strength * BendAmount (usually only in XY, slight Z)

“Looks like true collision” but heavier: Distance Field–driven bending (GDF) in the foliage material

Idea: sample the Global Distance Field in the grass material and push vertices away from nearby solid objects.

Pros

No per-object plumbing (in theory)
Works for arbitrary nearby geometry

Cons / gotchas

Much harder to art-direct
Can be noisy/unstable on thin foliage
Depends on distance field availability/quality (Nanite / thin meshes / settings)
Overkill for “a character pushing grass”

This is better for ambient avoidance effects, less for “character brushes grass.”

If you need one character / one vehicle: MPC method (fastest, cleanest).
If you need many movers (AI crowds, multiple vehicles, projectiles): RVT / Render Target stamping (most scalable and controllable).
Avoid physics for instanced foliage unless it’s a tiny number of hero plants.

Quick question that decides the right path (answer in one line)

Is your foliage placed via the Foliage Tool (HISM/ISM instanced) and do you need more than ~4 objects to push it at the same time?

If you say “yes + many objects,” I’ll outline an exact RVT/RT setup (what to create, what to stamp, what nodes to use in the material) that works reliably.

If these “leaves” are loose triangles on the ground and you want lots of movers to blow them away, the scalable pattern is:

✅ Keep leaves as a single GPU Niagara sim, and feed it a global “impulse / wind field” that movers write into

Trying to have Niagara query “all active movers” directly (array of positions) doesn’t scale well; it turns into per-particle × per-mover work. The trick is to rasterize mover influence into a texture/grid once, then every leaf samples that field in O(1).

Best scalable setup: Render Target (or RVT) “push map” → Niagara samples it

1) Leaves = one Niagara GPU system

Represent leaves as GPU particles (sprites or mesh triangles)
Keep them constrained near the floor:
- collide against depth/DF or just clamp Z to a ground plane + small noise
Use:
- Drag (air resistance)
- Friction when “on ground”
- Optional “stickiness” (if speed < threshold, reduce motion a lot)

2) Movers write to a shared 2D field each frame (the scalable part)

Create a render target (e.g. 1024² or 2048²) covering your play area (or a moving window around camera).

Each mover “stamps” into it:

Direction (usually from mover velocity or outward radial from mover position)
Strength and radius
Optionally turbulence

Encode it like:

RT.RG = push direction (mapped 0..1)
RT.B = strength
RT.A = optional mask / falloff

You can draw stamps with:

a simple “Draw Material to Render Target” pass in BP/C++ (additive)
optionally blur/decay it each frame for nice dissipation

This makes “100 movers” cost ~100 stamps, not 100×Nparticles.

3) Niagara samples the RT and turns it into force

In Niagara GPU update:

Convert particle world XY → RT UV
Sample RT
Decode direction/strength
Apply Add Velocity / Add Force scaled by strength and leaf mass
Add noise to avoid uniform motion

Result: all leaves get pushed correctly with just one texture sample per particle per frame.

Alternative if your world is huge: “moving window” field

If the play area is large, don’t make a giant RT. Instead:

Maintain a camera-centered RT that represents, say, a 50m × 50m region
Stamp only movers in that region
Niagara uses the same mapping

This keeps resolution high and cost stable.

When to use Niagara Data Channels instead

Niagara Data Channels are great if you have a small-ish number of movers (dozens) and want direct influence. But if you expect lots (hundreds+) or you want a wide area effect, the RT/RVT field wins.

Practical tips so it looks good (and not “ice skating”)

Only apply strong push if leaf is “loose”:
- if speed < small_threshold and “resting”, require a stronger impulse to wake it
Add ground friction proportional to contact
Add a tiny random torque/rotation so triangles tumble
Clamp max speed so it doesn’t explode
Use Niagara fixed bounds + scalability culling

If you tell me:

UE version,
approximate area size (meters), and
rough max movers at once (10? 100? 1000?)

…I’ll recommend RT size, world→UV mapping strategy, and the cleanest Niagara modules to use (including a “decay + stamp” render-target loop that doesn’t smear).

Nice — the “push map” texture is the right backbone for scaling to lots of movers. Below is a UE 5.5–friendly way to build it entirely in Blueprint + materials, with:

Ping-pong render targets (so we can decay previous frame)
Additive stamping for many movers
Dummy movers driven by a 2D curl field (Perlin noise + finite differences)

I’ll describe it as a build recipe you can follow in the editor.

1) Create the textures: ping-pong Canvas Render Targets

You want two render targets so you can sample “previous” while writing “next”.

Create two assets

In Content Browser:

Add → Materials & Textures → Canvas Render Target 2D
- Name: CRT_Push_A
Duplicate it:
- Name: CRT_Push_B

For both CRT_Push_A/B set in Details:

Size: start with 1024 x 1024 (good default)
Clear Color: (0,0,0,0)
bAutoGenerateMips: Off (for now)
Render Target Format: RTF_RGBA16f (best for vector fields)
(RGBA8 works too if you’re careful, but 16f gives smoother directions.)

2) Decide on encoding (simple + practical)

Let’s pack this into the RT:

R,G = push direction in XY mapped from [-1..1] → [0..1]
B = strength [0..1]
A = optional (leave 0 for now, or use as “wake” mask later)

So stamp writes:

RG = dir * 0.5 + 0.5
B = strength
A = 0

3) Make the materials

3.1 `M_PushDecay` (full-screen pass)

This is a full-screen material that reads the previous RT and applies decay.

Create Material: M_PushDecay

Material Domain: Surface
Blend Mode: Opaque
Shading Model: Unlit

Parameters:

PrevTex (Texture2D parameter)
Decay (Scalar, e.g. 0.92 to 0.99 per frame)
StrengthDecay optional separate (Scalar)

Graph:

Sample PrevTex using TexCoord
Output: Prev * Decay
- You can decay direction and strength together initially:
  - Out = Prev * Decay
Plug into Emissive Color

That’s it.

This makes the field fade out smoothly unless new stamps add energy.

3.2 `M_PushStamp_Add` (draw many times, additive)

Create Material: M_PushStamp_Add

Material Domain: Surface
Blend Mode: Additive ✅
Shading Model: Unlit

Parameters:

CenterUV (Vector2)
RadiusUV (Scalar) (radius in UV space)
DirXY (Vector2) direction in world XY (expects normalized)
Strength (Scalar 0..1)
Softness (Scalar, e.g. 2–8)

Graph (core idea):

d = distance(TexCoord, CenterUV)
mask = saturate(1 - (d / RadiusUV))
soften it: mask = pow(mask, Softness)
Encode dir: encDir = DirXY * 0.5 + 0.5
Output:
- R = encDir.x * mask * Strength
- G = encDir.y * mask * Strength
- B = mask * Strength
- A = 0
Plug result into Emissive Color

Because it’s Additive, drawing multiple stamps accumulates.

4) Actor that owns & draws the field: `BP_PushFieldManager`

Create an Actor BP: BP_PushFieldManager

Variables

RT_Current (CanvasRenderTarget2D) → set to CRT_Push_A
RT_Next (CanvasRenderTarget2D) → set to CRT_Push_B
MI_Decay (MaterialInstanceDynamic)
MI_Stamp (MaterialInstanceDynamic)

World→UV mapping:

FieldCenterWS (Vector3) (center of the simulated area)
FieldSizeWS (Vector2) e.g. (20000, 20000) for a 200m x 200m field

Dummy movers:

MoverCount (int) e.g. 32 / 64
Arrays:
- MoverPosWS (Vector2)
- MoverVelWS (Vector2)

Tuning:

MoverSpeed (float)
StampRadiusWS (float)
StampStrength (float)
Decay (float 0.95–0.99)

BeginPlay

Create MI_Decay from M_PushDecay
Create MI_Stamp from M_PushStamp_Add
Initialize movers with random positions inside FieldSize

5) The ping-pong draw each frame

Tick flow (Event Tick)

Update dummy movers (curl field) → new positions + velocities
Draw to RT_Next:
- Full-screen decay pass sampling RT_Current
- Then stamp all movers additively
Swap RT_Current and RT_Next

5.1 Drawing: use the Canvas Render Target update event

Each CanvasRenderTarget2D has an event you can implement:

Open CRT_Push_B (and CRT_Push_A) → there’s an OnCanvasRenderTargetUpdate event you can bind to from BP, or easiest: create a Blueprint subclass of CanvasRenderTarget2D.
Easiest workflow: create a BP subclass:

Create Blueprint Class:

Parent class: CanvasRenderTarget2D
Name: BP_PushCanvasRT

Inside BP_PushCanvasRT:

Add variables:
- PrevTex (Texture)
- DecayMI (MaterialInstanceDynamic)
- StampMI (MaterialInstanceDynamic)
- MoversUV (Array of Vector2)
- MoversDir (Array of Vector2)
- MoversStrength (Array float)
- RadiusUV (float)

Implement event:

Event Receive Update (Canvas, Width, Height)

In that event:

Draw decay full-screen
- Set DecayMI.PrevTex = PrevTex
- Set DecayMI.Decay = Decay
- Canvas -> K2_DrawMaterial(DecayMI, 0,0, Width,Height)
Draw stamps
- For each mover:
  - Set StampMI.CenterUV, StampMI.DirXY, StampMI.Strength, StampMI.RadiusUV
  - Canvas -> K2_DrawMaterial(StampMI, 0,0, Width,Height)
    (Material itself uses TexCoord + CenterUV to “localize” the circle)

Because M_PushStamp_Add is Additive, drawing it repeatedly accumulates.

5.2 In `BP_PushFieldManager` Tick

Convert movers from WS→UV (see below)
Push those arrays into BP_PushCanvasRT (the one you’re updating)
Set PrevTex = RT_Current
Call UpdateResource on RT_Next (this triggers the Canvas draw)
Swap RT references

6) World ↔ UV mapping (critical)

Given:

FieldCenterWS (X,Y)
FieldSizeWS (width,height)

For a mover position Pws (Vector2):

min = FieldCenterWS.xy - FieldSizeWS * 0.5
uv = (Pws - min) / FieldSizeWS
Clamp 0..1 (or wrap for endless tiling)

Radius:

RadiusUV = StampRadiusWS / FieldSizeWS.x (if square field; otherwise handle x/y separately)

Direction:

Use mover velocity normalized, or radial away from mover center depending on effect.

7) Dummy movers with a 2D curl field (Blueprint-friendly)

Blueprint has Perlin Noise 2D (KismetMathLibrary). We can approximate curl using finite differences:

Let N(x,y) be noise.

Compute gradients:

dNdx = (N(x+e,y) - N(x-e,y)) / (2e)
dNdy = (N(x,y+e) - N(x,y-e)) / (2e)

Curl vector (2D incompressible field):

curl = ( dNdy, -dNdx )

Practical BP values

e = 25.0 world units (tune)
noiseScale = 0.002 (tune)
sample noise at p * noiseScale

Then:

vel = normalize(curl) * MoverSpeed
pos += vel * DeltaSeconds
Wrap pos around field bounds for endless motion

This gives you that nice swirling “active movers” pattern without hand animating.

8) How you’ll use this texture in Niagara later

Once RT_Current is updating, you’ll pass it to Niagara as a User Parameter Texture (or via a Niagara component binding), then per particle:

Sample push map at particle XY
Decode:
- dir = normalize((RG*2 - 1))
- strength = B
Apply force: Velocity += dir * strength * PushScale * dt

(We’ll wire this after the texture is alive.)

Good defaults to start

RT size: 1024
FieldSizeWS: 20000 x 20000 (200m square)
Decay: 0.97
MoverCount: 64
StampRadiusWS: 150
StampStrength: 1.0
Softness: 4
MoverSpeed: 600

Quick check: what you should see

Before Niagara, you can debug by:

Putting RT_Current on a plane as an emissive material (preview RG/B)
You should see drifting “stamps” leaving fading direction/strength trails.

If you tell me whether your world is top-down / third-person and roughly how large the active area should be (e.g. “~50m around camera” vs “whole level”), I’ll recommend:

fixed global RT vs moving-window RT
best resolution vs cost
and the cleanest way to feed it into Niagara in UE 5.5.

Good question — this is one of those Blueprint things that’s simple once you see it, but opaque before that.

Below is the exact, concrete way to initialize your movers with random positions (and optional initial velocities) in Blueprint, for the push-field setup we discussed.

Goal

At BeginPlay, create MoverCount movers with:

Random XY positions inside your field
Z ignored (2D field)
Optional random starting velocity (or zero, curl field will drive it)

Variables (recap)

In BP_PushFieldManager you already have:

MoverCount (int)
FieldCenterWS (Vector3)
FieldSizeWS (Vector2)
MoverPosWS (Array of Vector2)
MoverVelWS (Array of Vector2)

Make sure:

MoverPosWS and MoverVelWS are empty arrays at start

Step-by-step: BeginPlay setup

1️⃣ Clear arrays (important if you ever re-run)

In BeginPlay:

MoverPosWS → Clear
MoverVelWS → Clear

2️⃣ Compute field bounds

Still in BeginPlay, compute min/max once:

Min

MinX = FieldCenterWS.X - FieldSizeWS.X * 0.5
MinY = FieldCenterWS.Y - FieldSizeWS.Y * 0.5

Max

MaxX = FieldCenterWS.X + FieldSizeWS.X * 0.5
MaxY = FieldCenterWS.Y + FieldSizeWS.Y * 0.5

(You can store these in local variables or calculate inline.)

3️⃣ ForLoop to spawn movers

Add a ForLoop:

First Index: 0
Last Index: MoverCount - 1

Inside the loop:

4️⃣ Generate random position

Use Random Float in Range nodes:

RandX = Random Float in Range (MinX, MaxX)
RandY = Random Float in Range (MinY, MaxY)

Create a Vector2:

Pos = (RandX, RandY)

Then:

Add Pos to MoverPosWS

5️⃣ Initialize velocity (two good options)

Option A — Start at rest (recommended)

Curl field will immediately take over.

Vel = (0, 0)

Add to MoverVelWS.

Option B — Small random velocity (looks more “alive” at start)

DirAngle = Random Float in Range (0, 360)
Dir = (cos(DirAngle), sin(DirAngle))
Vel = Dir * InitialSpeed   (e.g. 100)

Add to MoverVelWS.

Blueprint node summary (visual mental map)

Inside BeginPlay:

Clear MoverPosWS
Clear MoverVelWS

ForLoop (0 → MoverCount-1)
 ├─ Random Float in Range (MinX, MaxX)
 ├─ Random Float in Range (MinY, MaxY)
 ├─ Make Vector2 → Pos
 ├─ Add Pos to MoverPosWS
 ├─ Make Vector2 (0,0) → Vel
 └─ Add Vel to MoverVelWS

That’s it. No spawning actors, no transforms — just data.

Optional: wrap-safe initialization

If later you use wrap-around logic (when movers exit the field), this initialization already matches that system, so movers won’t “teleport oddly.”

Sanity check (highly recommended)

After BeginPlay:

Print MoverPosWS.Length
Should equal MoverCount
Print first element to ensure values are within bounds

What happens next

On Tick, you’ll:

Read MoverPosWS[i]
Compute curl velocity
Update MoverVelWS[i]
Update MoverPosWS[i]
Convert position → UV
Stamp into the render target

If you want, next we can:

🔹 Implement the curl field update step-by-step in Blueprint
🔹 Or wire this RT directly into Niagara and test leaves reacting

Just say which one you want next.

In Blueprint, you do NOT pre-size arrays like in C++.

Instead, you create the correct number of elements by adding them — that is the initialization.

If you try to “set length” mentally, that’s where the confusion comes from.

Below is the correct and idiomatic Unreal Blueprint way, plus the one thing that will break things if you do it wrong.

The correct way (99% of cases)

Pattern

Clear the array
ForLoop
Add one element per iteration

That’s it.

Example (your movers)

BeginPlay:

MoverPosWS.Clear
MoverVelWS.Clear

ForLoop (0 → MoverCount - 1)
 ├─ Compute random position
 ├─ Add → MoverPosWS
 └─ Add → MoverVelWS

After the loop:

MoverPosWS.Length == MoverCount
MoverVelWS.Length == MoverCount

This is exactly how Blueprint expects you to do it.

What NOT to do (common trap)

❌ Do not:

Call Set Array Elem on an empty array
Assume it “auto-resizes”

Set Array Elem only works if the index already exists
(or if you explicitly check “Size to Fit”, which you almost never want here).

Using it on an empty array → silent failure or out-of-bounds bugs.

Alternative (valid, but rarely needed): Set Num

There is a node called Set Array Length / Set Num (exact name varies by version):

It resizes the array to N elements
Elements are default-initialized (zero vectors, zero floats)

When to use it

Only if:

You must write by index later (e.g. parallel arrays updated by index)
And you want to guarantee the size up-front

Example

MoverPosWS.SetNum(MoverCount)
MoverVelWS.SetNum(MoverCount)

ForLoop (0 → MoverCount - 1)
 ├─ Set Array Elem (MoverPosWS, Index, RandomPos)
 └─ Set Array Elem (MoverVelWS, Index, ZeroVel)

This is fine — just more verbose.

Which should you use?

For your case:

✔ Use Add in a loop
It’s simpler, safer, and idiomatic Blueprint.

You’re already looping over movers every Tick anyway.

Mental model (important)

Think of Blueprint arrays as:

“Lists that grow as you Add to them”

Not:

“Buffers with a fixed size”

Once you adopt that model, a lot of Blueprint friction disappears.

Quick debug check

After BeginPlay:

Print:
- MoverPosWS.Length
- MoverVelWS.Length

If either ≠ MoverCount, something is wrong.

If you want, next we can:

Implement the curl-field Tick update cleanly
Or connect the RT to Niagara and verify leaves react correctly

Just tell me which step you want next.

That error means you’re trying to plug a value of one type into an array pin of a different type.

In Blueprints, arrays are strictly typed — a Vector2D is not compatible with a Vector (3D), and neither is compatible with a custom struct.

The most likely mismatch

You named it “Mover Pos WS” (world-space), so you probably made it a Vector (X,Y,Z) at some point, but you’re generating a Vector2D (X,Y).

Fix option A (recommended): make everything 2D

If your movers are 2D:

In My Blueprint → Variables

Set MoverPosWS type to Vector2D
Set MoverVelWS type to Vector2D

When you create a random position, use Make Vector2D (not Make Vector)

Pos2D = Make Vector2D(RandX, RandY)

Use Add on MoverPosWS and plug in Pos2D

✅ Now the pins will connect.

Fix option B: keep world-space as 3D Vector

If you want proper world-space positions:

Set MoverPosWS type to Vector (not Vector2D)
Create a Make Vector:

Pos3D = Make Vector(RandX, RandY, FieldCenterWS.Z) (or 0)

Add that to the array.

✅ Now the pins will connect.

How to quickly verify what’s mismatched

Click the variable MoverPosWS in the Variables list and look at:

Variable Type (Vector? Vector2D? something else)
If it says Array of … (that “…” must match your value type exactly)

Also: make sure the node you’re feeding is the correct “Make …” node:

Make Vector → outputs Vector (3D)
Make Vector2D → outputs Vector2D (2D)

Common gotcha

There are two different “Vector2” concepts people mix up:

Vector2D (Blueprint type)
A custom struct like “Float2”/“Vector2f” (plugin or C++ exposed)

Those are not compatible either.

If you tell me what the type of Target Array is (Vector? Vector2D? a struct name?), I’ll tell you exactly which variable to change so you don’t have to rewire half the graph.

You’re at the exact right stumbling block — this is where the mental model of Material Instance Dynamics (MIDs) has to “click”.

I’ll explain it precisely and concretely, then give you the exact Blueprint nodes you need.

Key rule (read this once)

You do not set parameters on the Material asset.
You set parameters on a Material Instance Dynamic that was created at runtime.

If you try to skip this, nothing will connect or update.

What you need (recap)

You already have:

Material: M_PushDecay
- Parameters:
  - PrevTex (Texture2D)
  - Decay (Scalar)
Render Targets:
- CRT_Push_A
- CRT_Push_B

You need:

One MID created from M_PushDecay

Step-by-step: creating and setting the MID

1️⃣ Create the MID (BeginPlay)

In BP_PushFieldManager → BeginPlay:

Nodes

Create Dynamic Material Instance
- Source Material: M_PushDecay
Store result in a variable:
- Variable name: MI_Decay
- Type: MaterialInstanceDynamic

Blueprint flow:

BeginPlay
 └─ Create Dynamic Material Instance (M_PushDecay)
     └─ Set MI_Decay

⚠️ Do this once, not every frame.

2️⃣ Set `PrevTex` on the MID

Whenever you are about to draw the decay pass (every frame):

Node

Set Texture Parameter Value

Parameters:

Target → MI_Decay
Parameter Name → "PrevTex" (must match exactly)
Value → RT_Current

Blueprint snippet:

Set Texture Parameter Value
 ├─ Target: MI_Decay
 ├─ Parameter Name: PrevTex
 └─ Value: RT_Current

3️⃣ Set `Decay` on the MID

Same idea:

Node

Set Scalar Parameter Value

Parameters:

Target → MI_Decay
Parameter Name → "Decay"
Value → your Decay float (e.g. 0.97)

Blueprint snippet:

Set Scalar Parameter Value
 ├─ Target: MI_Decay
 ├─ Parameter Name: Decay
 └─ Value: Decay

You can set Decay:

once in BeginPlay (if constant), or
every frame (if you want it adjustable)

4️⃣ Use the MID when drawing to the render target

This is the most common missing step.

When you draw the full-screen decay pass:

Node

Canvas → K2_DrawMaterial

Parameters:

Render Material → MI_Decay ✅ NOT M_PushDecay
Position: (0,0)
Size: (Width, Height)

If you accidentally draw M_PushDecay instead of MI_Decay,
your parameters will be ignored.

5️⃣ Minimal working order (important)

Each frame, in this order:

Set MI_Decay.PrevTex = RT_Current
Set MI_Decay.Decay   = DecayValue
Canvas.DrawMaterial(MI_Decay)

Then:

draw stamps
swap RTs

Common mistakes (check these!)

❌ Setting parameters on the Material asset
❌ Forgetting to store the MID in a variable
❌ Drawing the base material instead of the MID
❌ Parameter name typo (prevTex ≠ PrevTex)
❌ Using Texture instead of Texture2D parameter

Quick debug trick

To confirm it’s working:

Temporarily set Decay = 0.0
The RT should clear to black every frame

If it doesn’t:

You are not drawing the MID correctly

TL;DR (mental model)

Materials are templates
MIDs are the live, writable objects

You always:

Create MID
Set parameters on MID
Draw/use MID

If you want, next I can:

Walk you through stamping movers into the RT (same parameter logic)
Or help you debug why the RT is still black / static

Just tell me what you’re seeing on screen.

Great questions — these are exactly the two concepts that usually block people here.
I’ll answer them very concretely, with zero hand-waving.

1️⃣ What is `K2_DrawMaterial`?

Short answer

K2_DrawMaterial is the Blueprint node that draws a material onto a Canvas, which is how you write into a Canvas Render Target.

You never call it “directly” — it only appears inside a Canvas Render Target’s update event.

Where it exists (this is critical)

K2_DrawMaterial only exists in this context:

A Blueprint that inherits from CanvasRenderTarget2D
Inside the event: Event Receive Update (Canvas, Width, Height)

If you’re in a normal Actor BP, you will not see it.

What it actually does

It says:

“Draw this material to the render target, using the given Canvas, at this rectangle.”

In C++ it’s part of the Canvas API — K2_ just means “Blueprint-exposed wrapper”.

How you get it

Step-by-step

Create a Blueprint:
- Parent Class → CanvasRenderTarget2D
- Name: BP_PushCanvasRT
Open it
Right-click in the Event Graph
Add: Event Receive Update

Now:

Drag off the Canvas pin
Search for Draw Material

You’ll see:

Draw Material
(which is internally K2_DrawMaterial)

That’s the node.

Correct usage (example)

Inside Event Receive Update:

Canvas → Draw Material
 ├─ Render Material = MI_Decay
 ├─ Screen X = 0
 ├─ Screen Y = 0
 ├─ Screen W = Width
 └─ Screen H = Height

This draws your decay pass full-screen into the RT.

2️⃣ How do the two Blueprints connect?

You have:

BP_PushFieldManager (logic, movers, ping-pong, Tick)
BP_PushCanvasRT (knows how to draw into the RT)

They connect via:

Variables + calling UpdateResource()

No casting, no interfaces, no events.

The relationship (mental model)

BP_PushFieldManager
 ├─ owns movers
 ├─ owns render targets
 ├─ sets parameters
 └─ tells the RT when to redraw

BP_PushCanvasRT
 ├─ receives parameters
 └─ draws into itself when updated

Step-by-step wiring

1️⃣ Create two RT instances of your Canvas RT BP

In BP_PushFieldManager, add variables:

RT_A (type: BP_PushCanvasRT, Object Reference)
RT_B (same)

In BeginPlay:

Create Render Target 2D → NOT needed here
Instead:
- Create two assets of type BP_PushCanvasRT in Content Browser
  (e.g. RT_Push_A, RT_Push_B)
- Assign them to RT_A and RT_B in Details

(They behave like textures, but are Blueprint-backed.)

2️⃣ Pass data into the RT BP

In BP_PushCanvasRT, create variables:

PrevTex (Texture)
MI_Decay (MaterialInstanceDynamic)
MI_Stamp (MaterialInstanceDynamic)
Arrays:
- MoversUV (Array of Vector2D)
- MoversDir (Array of Vector2D)
- MoversStrength (Array of float)
RadiusUV (float)
Decay (float)

These are inputs.

3️⃣ Manager sets those variables each frame

In BP_PushFieldManager → Tick:

RT_Next.PrevTex = RT_Current
RT_Next.MoversUV = ComputedUVs
RT_Next.MoversDir = ComputedDirs
RT_Next.MoversStrength = Strengths
RT_Next.RadiusUV = RadiusUV
RT_Next.Decay = Decay

Just normal variable assignment.

4️⃣ Tell the RT to redraw

Still in Tick:

RT_Next.UpdateResource()

This:

Triggers Event Receive Update in BP_PushCanvasRT
Which calls Draw Material internally

5️⃣ Swap references

After update:

Temp = RT_Current
RT_Current = RT_Next
RT_Next = Temp

Classic ping-pong.

Important rule

❗ Never draw from the Manager

No Canvas
No Draw Material
No Update event

❗ Never UpdateResource inside the RT BP

That causes recursion

Minimal working mental model

Manager feeds data → RT BP draws → UpdateResource triggers draw

Quick debug checklist

If nothing appears in the RT:

Are you calling UpdateResource()?
Are you drawing a MID, not the base material?
Is Event Receive Update firing? (Print string inside it)

TL;DR

K2_DrawMaterial = Canvas draw node, only inside Canvas RT BP
Manager BP sets variables on the RT BP and calls UpdateResource()
The RT BP’s Update event does the actual drawing

Next good step:

I can give you a minimal “hello world” Canvas RT (just clears to red)
Or wire the stamp pass fully

Tell me which you want and I’ll walk it line-by-line.

Got it. Here’s the clean, minimal, exact setup to build a “push map” texture in UE 5.5 using one Canvas Render Target + one manager actor, with dummy movers. No extra blueprint classes, no ping-pong yet. (Once this works, adding ping-pong/decay is easy.)

What you will build

A texture (RT_Push) that updates every frame.
A manager actor (BP_PushFieldManager) that:
- generates dummy mover positions,
- draws “stamps” into RT_Push.

You will verify it by putting RT_Push on a plane.

Step 1 — Create the Render Target

Content Browser → Add → Materials & Textures → Canvas Render Target 2D
Name it: RT_Push
Open RT_Push and set:
- Size X/Y: 1024 / 1024
- Clear Color: Black (0,0,0,1)

Step 2 — Create the stamp material (draw a circle)

Content Browser → Add → Material
Name it: M_Stamp
Set in Details:
- Material Domain: Surface
- Blend Mode: Additive
- Shading Model: Unlit
Create these Material Parameters:
- CenterUV (Vector2 parameter) (you’ll set per mover)
- Radius (Scalar parameter)
- Strength (Scalar parameter)
Build this logic:
- UV = TextureCoordinate
- d = Distance(UV, CenterUV)
- mask = saturate(1 - d / Radius)
- mask = pow(mask, 4) (soft edge)
- Output color = mask * Strength (plug into Emissive Color)

Save.

For now the RT will store just intensity (white circles). Direction can come later.

Step 3 — Create the manager actor

Content Browser → Add → Blueprint Class → Actor
Name it: BP_PushFieldManager

Add these variables:

A) References

PushRT (type: Canvas Render Target 2D Object Reference)
StampMaterial (type: Material Interface)

Set defaults in the BP Details (or later in the level):

PushRT = RT_Push
StampMaterial = M_Stamp

B) Field settings

MoverCount (int) default 32
RadiusUV (float) default 0.03
Strength (float) default 1.0

C) Arrays

MoverUVs (Array of Vector2D)

Step 4 — Initialize movers (BeginPlay)

In BP_PushFieldManager → Event BeginPlay:

Clear MoverUVs
Add a ForLoop
- First Index: 0
- Last Index: MoverCount - 1
Inside the loop:
- RandX = Random Float in Range (0, 1)
- RandY = Random Float in Range (0, 1)
- UV = Make Vector2D(RandX, RandY)
- Add UV to MoverUVs

That’s the whole initialization.

Step 5 — Move them every frame (Tick)

In Event Tick:

ForLoop i = 0 .. MoverCount-1
For each mover:
- Get UV = MoverUVs[i]
- Update UV using a simple motion (dummy):
  - UV.X = frac(UV.X + DeltaSeconds * 0.10)
  - UV.Y = frac(UV.Y + DeltaSeconds * 0.07)
- Set MoverUVs[i] = UV

(That’s enough to prove drawing works. Curl noise later.)

Step 6 — Draw into the render target (the key step)

Still in Event Tick, after updating movers:

Create a Dynamic Material Instance ONCE (do this in BeginPlay):
- Node: Create Dynamic Material Instance
- Source: StampMaterial
- Save result into variable MI_Stamp (type MaterialInstanceDynamic)
Every frame, call:
- Node: Update Canvas Render Target
  - Target: PushRT

✅ This triggers RT_Push’s draw event.

Step 7 — Implement the draw event on RT_Push

Open the asset RT_Push.

There is an event graph for Canvas Render Target assets:

Add event:
- Event Receive Update (Canvas, Width, Height)
First clear it:
- Use node: Canvas → K2_DrawBox
  - Position (0,0)
  - Size (Width, Height)
  - Color (0,0,0,1) (Or use Canvas → Clear if available in your build)
For each mover in the manager:
- This is the only “connection” point you need: the RT asset needs to know the manager.
- Easiest: In the manager, set itself on the RT as a variable.

So do this:

7A) Add a variable to RT_Push

In RT_Push (the Canvas RT asset), add a variable:

Manager (type: BP_PushFieldManager Object Reference)

7B) Set it from the manager (BeginPlay)

In BP_PushFieldManager BeginPlay:

PushRT → Set Manager = self

7C) Now draw stamps in RT_Push update event

In RT_Push Event Receive Update:

Get Manager
Get Manager.MoverUVs
ForLoop over UVs:
- Set parameters on MI_Stamp:
  - CenterUV = UV
  - Radius = Manager.RadiusUV
  - Strength = Manager.Strength
- Canvas → K2_DrawMaterial
  - Material: MI_Stamp
  - X=0, Y=0, W=Width, H=Height

Save.

That’s it.

Step 8 — Visualize the texture (confirm it works)

Create a new material: M_ShowRT
- Unlit
- Sample Texture Parameter PushTex
Create a material instance, set PushTex = RT_Push
Apply to a plane in the level

You should see moving soft circles.

If you don’t see anything, check only these 3 things

Is BP_PushFieldManager placed in the level?
Is Update Canvas Render Target being called every Tick?
Does RT_Push’s Event Receive Update fire? (Put a Print String inside it.)

If you confirm you can see moving circles, next step is easy:

upgrade RT to RGBA (dir+strength)
add ping-pong + decay
replace dummy motion with curl field
then sample it in Niagara

Say “I see the circles” or “RT stays black” and I’ll give the next exact steps accordingly.

Perfect — this is the core misunderstanding, and it’s not your fault.
In UE 5.5, a Canvas Render Target asset does NOT have an Event Graph.

👉 Only a Blueprint that inherits from CanvasRenderTarget2D has an Event Graph.

So let’s reset and do this the correct, minimal, UE-5.5-correct way.

The correct mental model (1 sentence)

A Canvas Render Target asset is just a texture.
A Canvas Render Target Blueprint is where the drawing logic lives.

You were opening the asset, expecting Blueprint behavior — that will never work.

EXACT steps (clean, minimal, correct)

STEP 1 — Create a Canvas Render Target Blueprint

Add → Blueprint Class
In the parent class picker:
- Search for CanvasRenderTarget2D
Select it
Name it:
BP_PushCanvasRT

✅ This Blueprint will have an Event Graph

STEP 2 — Configure the render target

Open BP_PushCanvasRT

In Class Defaults:

Size X: 1024
Size Y: 1024
Clear Color: Black

STEP 3 — Add the draw event (this is what you were missing)

In BP_PushCanvasRT → Event Graph:

Right-click
Add: Event Receive Update (Canvas, Width, Height)

🎉
THIS is the event that replaces the “missing EventGraph” you were looking for.

STEP 4 — Test with the simplest possible draw (proof of life)

Inside Event Receive Update:

Drag off Canvas
Add node: Draw Material (this is K2_DrawMaterial)

Use:

Material: any solid-color unlit material (or make one that outputs red)
X = 0
Y = 0
W = Width
H = Height

Save.

STEP 5 — Trigger the draw (manager actor)

Create a normal Actor:

BP_PushFieldManager

Add variable:

PushRT (type: BP_PushCanvasRT Object Reference)

In BeginPlay:

Create node: Create Canvas Render Target 2D
Class: BP_PushCanvasRT
Save return value into PushRT

In Tick:

Call: Update Resource on PushRT

That’s it.

STEP 6 — Verify visually

Create a material:
- Unlit
- Texture Sample → PushRT
- Plug into Emissive
Apply to a plane

If everything is wired correctly: ➡️ the plane will turn solid red

Why this works (and the asset didn’t)

Thing you opened	Has Event Graph?	Can draw?
Canvas RT asset	❌ No	❌ No
Canvas RT BP	✅ Yes	✅ Yes

Unreal does not expose drawing logic on the asset itself.

Stop here and confirm

Before adding movers, stamps, decay, curl, anything:

👉 Do you now see a color appearing on the plane when Tick runs?

Reply with YES or NO.
If YES → next step is stamping movers.
If NO → I’ll tell you exactly which single wire is wrong.

Yes — C++ is actually the cleanest way to do this in UE5.5, because you can:

own the render target lifecycle in one place
update it deterministically each frame
avoid Blueprint plumbing between a “manager” and a Canvas RT BP

There are two clean C++ approaches:

Option A (recommended): Use a normal `UTextureRenderTarget2D` + draw materials into it

This avoids UCanvasRenderTarget2D entirely and is the simplest to scale to many “stamps”.

What you do

Create a UTextureRenderTarget2D (RGBA16f) at runtime
Each frame:

Clear it or apply decay
Stamp all movers using UKismetRenderingLibrary::DrawMaterialToRenderTarget (or batched canvas, see note)

Minimal skeleton

Manager actor header

#pragma once

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "PushFieldManager.generated.h"

UCLASS()
class APushFieldManager : public AActor
{
  GENERATED_BODY()

public:
  APushFieldManager();

  virtual void BeginPlay() override;
  virtual void Tick(float DeltaSeconds) override;

  UPROPERTY(EditAnywhere, Category="PushField")
  int32 Size = 1024;

  UPROPERTY(EditAnywhere, Category="PushField")
  FVector2D FieldSizeWS = FVector2D(20000.f, 20000.f);

  UPROPERTY(EditAnywhere, Category="PushField")
  int32 MoverCount = 64;

  UPROPERTY(EditAnywhere, Category="PushField")
  float StampRadiusWS = 150.f;

  UPROPERTY(EditAnywhere, Category="PushField")
  float StampStrength = 1.f;

  UPROPERTY(EditAnywhere, Category="PushField")
  float Decay = 0.97f;

  // Materials you author in editor:
  UPROPERTY(EditAnywhere, Category="PushField")
  UMaterialInterface* DecayMaterial = nullptr; // M_PushDecay (PrevTex + Decay)

  UPROPERTY(EditAnywhere, Category="PushField")
  UMaterialInterface* StampMaterial = nullptr; // M_PushStamp_Add (CenterUV, RadiusUV, DirXY, Strength)

  UPROPERTY(VisibleAnywhere, Category="PushField")
  TObjectPtr<class UTextureRenderTarget2D> RT_A;

  UPROPERTY(VisibleAnywhere, Category="PushField")
  TObjectPtr<class UTextureRenderTarget2D> RT_B;

  UFUNCTION(BlueprintCallable, Category="PushField")
  UTextureRenderTarget2D* GetCurrentRT() const { return bUseA ? RT_A : RT_B; }

private:
  bool bUseA = true;

  UMaterialInstanceDynamic* MID_Decay = nullptr;
  UMaterialInstanceDynamic* MID_Stamp = nullptr;

  TArray<FVector2D> MoverPosWS;
  TArray<FVector2D> MoverVelWS;

  FVector2D WorldToUV(const FVector2D& P) const;
  void UpdateMovers(float Dt);
  void DrawField();
};

Manager actor cpp

#include "PushFieldManager.h"
#include "Engine/TextureRenderTarget2D.h"
#include "Kismet/KismetRenderingLibrary.h"
#include "Kismet/KismetMathLibrary.h"
#include "Materials/MaterialInstanceDynamic.h"

APushFieldManager::APushFieldManager()
{
  PrimaryActorTick.bCanEverTick = true;
}

static UTextureRenderTarget2D* MakeRT(UObject* Outer, int32 Size)
{
  UTextureRenderTarget2D* RT = NewObject<UTextureRenderTarget2D>(Outer);
  RT->RenderTargetFormat = ETextureRenderTargetFormat::RTF_RGBA16f;
  RT->ClearColor = FLinearColor::Black;
  RT->InitAutoFormat(Size, Size);
  RT->UpdateResourceImmediate(true);
  return RT;
}

void APushFieldManager::BeginPlay()
{
  Super::BeginPlay();

  RT_A = MakeRT(this, Size);
  RT_B = MakeRT(this, Size);

  if (DecayMaterial) MID_Decay = UMaterialInstanceDynamic::Create(DecayMaterial, this);
  if (StampMaterial) MID_Stamp = UMaterialInstanceDynamic::Create(StampMaterial, this);

  // init movers
  MoverPosWS.SetNum(MoverCount);
  MoverVelWS.SetNum(MoverCount);

  const FVector2D Min = FVector2D(GetActorLocation()) - FieldSizeWS * 0.5f;
  const FVector2D Max = FVector2D(GetActorLocation()) + FieldSizeWS * 0.5f;

  for (int32 i = 0; i < MoverCount; ++i)
  {
    MoverPosWS[i] = FVector2D(
      FMath::FRandRange(Min.X, Max.X),
      FMath::FRandRange(Min.Y, Max.Y)
    );
    MoverVelWS[i] = FVector2D::ZeroVector;
  }

  // Clear initial RT
  UKismetRenderingLibrary::ClearRenderTarget2D(GetWorld(), RT_A, FLinearColor::Black);
  UKismetRenderingLibrary::ClearRenderTarget2D(GetWorld(), RT_B, FLinearColor::Black);
}

void APushFieldManager::Tick(float DeltaSeconds)
{
  Super::Tick(DeltaSeconds);

  UpdateMovers(DeltaSeconds);
  DrawField();

  bUseA = !bUseA; // ping-pong swap
}

FVector2D APushFieldManager::WorldToUV(const FVector2D& P) const
{
  const FVector2D Center = FVector2D(GetActorLocation());
  const FVector2D Min = Center - FieldSizeWS * 0.5f;
  FVector2D UV = (P - Min) / FieldSizeWS;
  UV.X = FMath::Clamp(UV.X, 0.f, 1.f);
  UV.Y = FMath::Clamp(UV.Y, 0.f, 1.f);
  return UV;
}

void APushFieldManager::UpdateMovers(float Dt)
{
  // Simple dummy motion (replace with curl later)
  const FVector2D Center = FVector2D(GetActorLocation());
  const FVector2D Min = Center - FieldSizeWS * 0.5f;
  const FVector2D Max = Center + FieldSizeWS * 0.5f;

  for (int32 i = 0; i < MoverCount; ++i)
  {
    // drift
    MoverVelWS[i] = FVector2D(600.f, 420.f);
    MoverPosWS[i] += MoverVelWS[i] * Dt;

    // wrap
    if (MoverPosWS[i].X > Max.X) MoverPosWS[i].X = Min.X;
    if (MoverPosWS[i].Y > Max.Y) MoverPosWS[i].Y = Min.Y;
  }
}

void APushFieldManager::DrawField()
{
  UTextureRenderTarget2D* Prev = bUseA ? RT_A : RT_B;
  UTextureRenderTarget2D* Next = bUseA ? RT_B : RT_A;

  // 1) Decay pass: Next = Prev * Decay
  if (MID_Decay)
  {
    MID_Decay->SetTextureParameterValue(TEXT("PrevTex"), Prev);
    MID_Decay->SetScalarParameterValue(TEXT("Decay"), Decay);
    UKismetRenderingLibrary::DrawMaterialToRenderTarget(GetWorld(), Next, MID_Decay);
  }
  else
  {
    // fallback: just clear
    UKismetRenderingLibrary::ClearRenderTarget2D(GetWorld(), Next, FLinearColor::Black);
  }

  // 2) Stamps (additive material)
  if (!MID_Stamp) return;

  const float RadiusUV = StampRadiusWS / FieldSizeWS.X; // assuming square-ish field

  for (int32 i = 0; i < MoverCount; ++i)
  {
    const FVector2D UV = WorldToUV(MoverPosWS[i]);
    const FVector2D Dir = MoverVelWS[i].GetSafeNormal();

    MID_Stamp->SetVectorParameterValue(TEXT("CenterUV"), FLinearColor(UV.X, UV.Y, 0, 0));
    MID_Stamp->SetScalarParameterValue(TEXT("RadiusUV"), RadiusUV);
    MID_Stamp->SetVectorParameterValue(TEXT("DirXY"), FLinearColor(Dir.X, Dir.Y, 0, 0));
    MID_Stamp->SetScalarParameterValue(TEXT("Strength"), StampStrength);

    // Draw onto Next; stamp material must be additive to accumulate.
    UKismetRenderingLibrary::DrawMaterialToRenderTarget(GetWorld(), Next, MID_Stamp);
  }
}

Notes on this option

It’s very clean, but stamping with DrawMaterialToRenderTarget in a loop can become expensive if you do hundreds/thousands of movers.
For “dozens to low hundreds”, it’s typically fine.
If you need “many hundreds+”, you’ll want batching (Option B) or a compute shader.

Option B (more scalable): One draw call that stamps many movers in the shader

Instead of drawing N times, you draw once and the shader loops over movers.

How:

Put mover data into a GPU-readable buffer:
- Niagara has ways, but you want pure C++: use a Texture (data texture) or StructuredBuffer (RDG / global shader).
Stamp in a single full-screen material pass.

This is “real scalable”, but it’s more engineering:

easiest stepping stone is a data texture (RGBA32f) where each pixel encodes one mover (pos.xy, dir.xy/strength), then the stamp material loops over a fixed max count.

If you tell me your expected max simultaneous movers (50? 500? 5000?), I’ll point you to the right tier.

Where `UCanvasRenderTarget2D` fits (and why I didn’t lead with it)

You can do this with UCanvasRenderTarget2D (override the update callback and use FCanvas drawing), but in 5.x it’s often less straightforward than the UKismetRenderingLibrary path above, and you still face the “many stamps = many draw calls” issue unless you batch.

Hooking this into Niagara

Once you have GetCurrentRT(), you feed that render target into Niagara as a User Texture parameter and sample it in a GPU update script.

If you answer just one thing—how many movers max at once (order of magnitude)—I’ll tell you whether Option A will hold up or whether you should jump straight to the “single-pass batched stamp” (or compute shader) implementation.

32 movers is perfect for the clean C++ + ping-pong render targets + per-mover stamp draw approach. You’ll be well within budget, and it stays simple.

Below is the exact minimal C++ implementation I’d use in UE 5.5.

What you’ll create in the Editor (2 materials)

1) `M_PushDecay` (Unlit, Opaque)

Parameters

PrevTex (Texture2D)
Decay (Scalar)

Graph

Emissive = TextureSample(PrevTex) * Decay

2) `M_PushStamp_Add` (Unlit, Additive)

Parameters

CenterUV (Vector2)
RadiusUV (Scalar)
DirXY (Vector2) (normalized)
Strength (Scalar)

Graph

d = distance(TexCoord, CenterUV)
mask = saturate(1 - d / RadiusUV)
mask = pow(mask, 4)
encode direction into RG:
- enc = DirXY * 0.5 + 0.5
Emissive.rgb = float3(enc.x, enc.y, 1) * (mask * Strength)
- (B = strength mask; you can adjust later)

Keep it simple for now: RG=dir, B=strength.

C++ Actor: `APushFieldManager`

This actor owns:

RT_A / RT_B (RGBA16f)
MID_Decay / MID_Stamp
32 movers (dummy motion now; curl later)
per-frame update: decay pass + 32 stamp draws + swap

#pragma once

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "PushFieldManager.generated.h"

UCLASS()
class YOURMODULE_API APushFieldManager : public AActor
{
  GENERATED_BODY()

public:
  APushFieldManager();

  virtual void BeginPlay() override;
  virtual void Tick(float DeltaSeconds) override;

  UPROPERTY(EditAnywhere, Category="PushField")
  int32 RTSize = 1024;

  UPROPERTY(EditAnywhere, Category="PushField")
  FVector2D FieldSizeWS = FVector2D(20000.f, 20000.f); // 200m x 200m

  UPROPERTY(EditAnywhere, Category="PushField")
  int32 MoverCount = 32;

  UPROPERTY(EditAnywhere, Category="PushField")
  float StampRadiusWS = 150.f;

  UPROPERTY(EditAnywhere, Category="PushField")
  float StampStrength = 1.f;

  UPROPERTY(EditAnywhere, Category="PushField")
  float Decay = 0.97f;

  UPROPERTY(EditAnywhere, Category="PushField")
  UMaterialInterface* DecayMaterial = nullptr; // M_PushDecay

  UPROPERTY(EditAnywhere, Category="PushField")
  UMaterialInterface* StampMaterial = nullptr; // M_PushStamp_Add

  UFUNCTION(BlueprintCallable, Category="PushField")
  class UTextureRenderTarget2D* GetPushRT() const;

private:
  TObjectPtr<class UTextureRenderTarget2D> RT_A;
  TObjectPtr<class UTextureRenderTarget2D> RT_B;
  bool bUseA = true;

  UMaterialInstanceDynamic* MID_Decay = nullptr;
  UMaterialInstanceDynamic* MID_Stamp = nullptr;

  TArray<FVector2D> Pos;
  TArray<FVector2D> Vel;

  FVector2D WorldToUV(const FVector2D& P) const;
  void InitMovers();
  void UpdateMovers(float Dt);
  void DrawField();
};

CPP

#include "PushFieldManager.h"
#include "Engine/TextureRenderTarget2D.h"
#include "Kismet/KismetRenderingLibrary.h"
#include "Materials/MaterialInstanceDynamic.h"

APushFieldManager::APushFieldManager()
{
  PrimaryActorTick.bCanEverTick = true;
}

static UTextureRenderTarget2D* MakeRT(UObject* Outer, int32 Size)
{
  UTextureRenderTarget2D* RT = NewObject<UTextureRenderTarget2D>(Outer);
  RT->RenderTargetFormat = ETextureRenderTargetFormat::RTF_RGBA16f;
  RT->ClearColor = FLinearColor::Black;
  RT->InitAutoFormat(Size, Size);
  RT->UpdateResourceImmediate(true);
  return RT;
}

void APushFieldManager::BeginPlay()
{
  Super::BeginPlay();

  RT_A = MakeRT(this, RTSize);
  RT_B = MakeRT(this, RTSize);

  if (DecayMaterial) MID_Decay = UMaterialInstanceDynamic::Create(DecayMaterial, this);
  if (StampMaterial) MID_Stamp = UMaterialInstanceDynamic::Create(StampMaterial, this);

  InitMovers();

  // Start clean
  UKismetRenderingLibrary::ClearRenderTarget2D(GetWorld(), RT_A, FLinearColor::Black);
  UKismetRenderingLibrary::ClearRenderTarget2D(GetWorld(), RT_B, FLinearColor::Black);
}

void APushFieldManager::Tick(float DeltaSeconds)
{
  Super::Tick(DeltaSeconds);

  UpdateMovers(DeltaSeconds);
  DrawField();

  bUseA = !bUseA;
}

UTextureRenderTarget2D* APushFieldManager::GetPushRT() const
{
  return bUseA ? RT_B : RT_A; // "Next" we just drew into
}

FVector2D APushFieldManager::WorldToUV(const FVector2D& P) const
{
  const FVector2D Center = FVector2D(GetActorLocation());
  const FVector2D Min = Center - FieldSizeWS * 0.5f;
  FVector2D UV = (P - Min) / FieldSizeWS;
  UV.X = FMath::Clamp(UV.X, 0.f, 1.f);
  UV.Y = FMath::Clamp(UV.Y, 0.f, 1.f);
  return UV;
}

void APushFieldManager::InitMovers()
{
  Pos.SetNum(MoverCount);
  Vel.SetNum(MoverCount);

  const FVector2D Center = FVector2D(GetActorLocation());
  const FVector2D Min = Center - FieldSizeWS * 0.5f;
  const FVector2D Max = Center + FieldSizeWS * 0.5f;

  for (int32 i = 0; i < MoverCount; ++i)
  {
    Pos[i] = FVector2D(
      FMath::FRandRange(Min.X, Max.X),
      FMath::FRandRange(Min.Y, Max.Y)
    );
    Vel[i] = FVector2D::ZeroVector;
  }
}

void APushFieldManager::UpdateMovers(float Dt)
{
  // Dummy motion for now (replace with curl later)
  const FVector2D Center = FVector2D(GetActorLocation());
  const FVector2D Min = Center - FieldSizeWS * 0.5f;
  const FVector2D Max = Center + FieldSizeWS * 0.5f;

  for (int32 i = 0; i < MoverCount; ++i)
  {
    Vel[i] = FVector2D(600.f, 420.f); // constant drift
    Pos[i] += Vel[i] * Dt;

    // wrap
    if (Pos[i].X > Max.X) Pos[i].X = Min.X;
    if (Pos[i].Y > Max.Y) Pos[i].Y = Min.Y;
    if (Pos[i].X < Min.X) Pos[i].X = Max.X;
    if (Pos[i].Y < Min.Y) Pos[i].Y = Max.Y;
  }
}

void APushFieldManager::DrawField()
{
  if (!MID_Decay || !MID_Stamp) return;

  UTextureRenderTarget2D* Prev = bUseA ? RT_A : RT_B;
  UTextureRenderTarget2D* Next = bUseA ? RT_B : RT_A;

  // 1) Next = Prev * Decay
  MID_Decay->SetTextureParameterValue(TEXT("PrevTex"), Prev);
  MID_Decay->SetScalarParameterValue(TEXT("Decay"), Decay);
  UKismetRenderingLibrary::DrawMaterialToRenderTarget(GetWorld(), Next, MID_Decay);

  // 2) Stamps additively onto Next
  const float RadiusUV = StampRadiusWS / FieldSizeWS.X; // assuming square-ish field

  for (int32 i = 0; i < MoverCount; ++i)
  {
    const FVector2D UV = WorldToUV(Pos[i]);
    const FVector2D Dir = Vel[i].GetSafeNormal();

    // Vector2 params are set via VectorParameter as RG
    MID_Stamp->SetVectorParameterValue(TEXT("CenterUV"), FLinearColor(UV.X, UV.Y, 0, 0));
    MID_Stamp->SetScalarParameterValue(TEXT("RadiusUV"), RadiusUV);
    MID_Stamp->SetVectorParameterValue(TEXT("DirXY"), FLinearColor(Dir.X, Dir.Y, 0, 0));
    MID_Stamp->SetScalarParameterValue(TEXT("Strength"), StampStrength);

    UKismetRenderingLibrary::DrawMaterialToRenderTarget(GetWorld(), Next, MID_Stamp);
  }
}

How to see it on screen (1 minute)

Create M_DebugPush (Unlit)
Sample a Texture Object Parameter PushTex
Plug into Emissive
In a material instance, set PushTex to the RT from the actor:
- easiest: expose GetPushRT() to BP and assign it at runtime to a MID used by a plane

If you want, I’ll give the exact BP snippet to:

get GetPushRT()
set it as a texture parameter on a plane’s MID

Next: replace dummy motion with 2D curl

Once this is drawing, the curl field is just replacing UpdateMovers() with:

Perlin noise samples
finite difference gradient
curl = (dNdy, -dNdx)

Say the word and I’ll drop in the exact C++ UpdateMovers() curl implementation (tuned so it looks good at 200m field size).

Great question — this is pure Unreal C++ boilerplate, not something you invented.

Short answer

YOURMODULE_API is an export/import macro for your game module.
You must replace it with your actual module’s API macro, or remove it if you’re not making a plugin.

What it actually does (1-paragraph explanation)

Unreal builds each module (your game, plugins, engine) as a separate DLL (on Windows).
Classes that need to be visible outside the module must be marked with an *_API macro so the linker knows whether to export or import them.

Unreal auto-generates one macro per module.

What to do in your case (most likely)

If this is normal game code (99% chance)

Replace:

UCLASS()
class YOURMODULE_API APushFieldManager : public AActor

with:

UCLASS()
class APushFieldManager : public AActor

✔ This is perfectly valid for game code
✔ No downside
✔ No linker issues

If you want to do it “by the book”

Find your real module API macro:

Open:

Source/<YourProjectName>/<YourProjectName>.h

You’ll see something like:

#pragma once

#include "CoreMinimal.h"

#define MYPROJECT_API

or in older setups:

#include "MyProject.generated.h"

Then your class would be:

UCLASS()
class MYPROJECT_API APushFieldManager : public AActor

But again — not required unless:

you’re building a plugin, or
another module needs to link against this class

Why I wrote `YOURMODULE_API`

I used it as a placeholder, because I don’t know your project/module name.

Unreal tutorials often do this to avoid guessing.

TL;DR

YOURMODULE_API = placeholder
For your project:
- Delete it, or
- Replace with <YourProjectName>_API
Your code will compile either way (for game code)

If you want, tell me:

Is this a game module or a plugin?

I’ll tell you exactly which form you should use and why.