Invisible Objects DF Contribution

2026-01-09 08:24 UTC gpt-5-2 Open in ChatGPT ↗

Yep — you can do this with component rendering flags (don’t use Hidden in Game if you still want distance-field contribution).

Make it invisible but still in the Global Distance Field (UE 5.5)

On the StaticMeshComponent (or the Actor’s mesh component), set:

Rendering

✅ Visible = true
❌ Render in Main Pass = false (this is the big one) citeturn0search0

Optional, depending on how “completely invisible” you mean:

❌ Render in Depth Pass = false (so it won’t write depth / show up in depth-based effects)
❌ Visible in Reflection Captures = false
❌ Visible in Ray Tracing = false (if you’re using HW ray tracing)

Distance Fields

✅ Affect Distance Field Lighting = true (so it still participates in DF-based systems / GDF) citeturn0search18
Make sure the project has Generate Mesh Distance Fields enabled:
Project Settings → Rendering → Software Ray Tracing → Generate Mesh Distance Fields citeturn1search1turn1search10

If you also want no shadows

Turning off “Render in Main Pass” can still leave you with shadows (depending on shadow method), so also set:

❌ Cast Shadow = false
❌ Cast Hidden Shadow = false (if present / enabled)

Quick sanity check

Use Show → Visualize → Global Distance Field to confirm it’s still voxelized, while it remains invisible in the viewport.

If you tell me whether you’re relying on this for Lumen, DFAO/DFS, or a material node like DistanceToNearestSurface, I can point out the one or two extra flags that matter most for that specific pipeline.

In Niagara there isn’t a single “Max Particles” checkbox, but you control the cap indirectly, depending on the emitter type. Here are the correct, engine-idiomatic ways in UE 5.5.

1️⃣ GPU Emitters (most common)

GPU emitters do have a hard cap.

Steps

Open the Niagara Emitter
Select Emitter Properties
Set:
- Sim Target = GPU
- Max GPU Particles → set your cap (e.g. 50,000)

This is the absolute maximum particles the emitter can ever have at once.

If spawn rate would exceed this, Niagara silently stops spawning.

2️⃣ CPU Emitters (no built-in hard cap)

CPU emitters must be self-limited.

Recommended method (clean & safe)

A) Add a User or Emitter parameter

Create:

Emitter.MaxParticles (int)

B) In Emitter Update

Add:

Get Num Particles
Compare (< MaxParticles)
Use that condition to drive spawn logic

C) Limit spawn

In Spawn Rate (or Spawn Burst):

SpawnRate = (NumParticles < MaxParticles) ? DesiredRate : 0

This prevents new particles from spawning once the cap is reached.

3️⃣ Hard-killing excess particles (CPU or GPU)

If you want a strict clamp, even when bursts overshoot:

In Particle Update

Add:

Kill Particles
Condition:

Particle.Index > MaxParticles

⚠️ Use this carefully — it’s evaluated per particle every frame.

4️⃣ Burst-only systems (very common mistake)

If you’re using Spawn Burst Instantaneous:

Make sure the burst count itself is ≤ your desired max
Or drive Burst Count with:

Min(BurstCount, MaxParticles)

5️⃣ Debug & verify

Enable:

Niagara Debugger
Or add Get Num Particles → Print String

This helps confirm the cap is actually respected.

Best practice summary

Emitter Type	Best Method
GPU	Max GPU Particles
CPU	Gate spawn using Get Num Particles
Bursts	Clamp burst count
Safety net	Kill Particles (optional)

If you tell me:

CPU or GPU emitter?
Continuous spawn or bursts?
One-shot or looping system?

I can give you the exact module stack and expressions to copy-paste.

That’s expected — there is no “Max Particles” property in Niagara, and that name is often mentioned loosely (which causes a lot of confusion).

Here’s the exact place and names, depending on emitter type, in UE 5.5.

1️⃣ GPU emitter (the ONLY case with a real hard cap)

The property is NOT called “Max Particles”.

Where to find it

Open your Niagara Emitter
Click the Emitter Properties (top of the stack)
Set:
- Sim Target = GPU Compute
- Max GPU Particles ← this is the cap

🔎 If you don’t see “Max GPU Particles”:

Your emitter is still CPU
Or you’re editing a System instead of the Emitter asset
Or Sim Target ≠ GPU Compute

CPU emitters do not have a hard cap property.

2️⃣ CPU emitter (correct way to cap)

You must gate spawning yourself.

Minimal setup (recommended)

A) Create a parameter

Add Emitter → MaxParticles (int)

B) In Emitter Update

Add:

Get Num Particles

C) Modify Spawn Rate

In Spawn Rate:

SpawnRate = (NumParticles < MaxParticles) ? DesiredSpawnRate : 0

That’s the intended Niagara workflow.

3️⃣ If you are using Spawn Burst

There is no automatic clamp.

Do this instead:

BurstCount = Min(DesiredBurst, MaxParticles - NumParticles)

4️⃣ Common reasons people think the option is missing

Issue	Why
Looking in System Overview	Cap lives in Emitter, not System
CPU emitter	No hard cap exists
Hidden advanced settings	Expand Emitter Properties
Using Sprite Renderer only	Renderer has no particle count control

5️⃣ Quick sanity check

Open Niagara Debugger → Overview
You’ll see Current Particles climb until your logic stops it.

Bottom line

✔ Only GPU emitters have a built-in hard max (Max GPU Particles)
❌ CPU emitters never have one
✔ CPU caps are done by spawn logic

If you want, tell me:

Are you using CPU or GPU?
Spawn Rate or Burst?
Looping or one-shot?

I’ll give you an exact Niagara graph tailored to your case.

Perfect — that screenshot explains the confusion 👍
You’re already in the right place, but the setting you want is collapsed / below the fold.

In UE 5.5, Max GPU Particles is NOT in the main Emitter section. It lives in the GPU subsection of Emitter Properties.

Where Max GPU Particles actually is (UE 5.5)

In the panel you’re showing:

Click Emitter Properties (you already did)
Scroll down
Expand the section called GPU (or GPU Compute)
Expand Allocation

You will see:

GPU
 └─ Allocation
     ├─ Max Particles   ← THIS is the cap
     ├─ Initial Allocation
     └─ Resize Mode

👉 “Max Particles” only appears once:

Sim Target = GPUCompute Sim
GPU section is expanded

It is not visible in:

CPU emitters
Renderer settings
System Overview
The top-level Emitter section you’re currently viewing

Why you don’t see it in your screenshot

Your screenshot only shows:

Emitter (general)
Bounds
Determinism
Sim Target

The GPU section is further down and collapsed by default.

Niagara UI does not auto-scroll to it, which trips up a lot of people.

Quick checklist (just to be sure)

You’re good if:

✅ Sim Target = GPUCompute Sim (you have this)
✅ Editing the Emitter asset, not just the System
✅ Scroll down → expand GPU → Allocation

If GPU section still does not appear:

The emitter was created as CPU-only → duplicate it and convert to GPU
Or the stack is filtered (funnel icon) → clear filters

TL;DR

✔ The cap exists
✔ It’s called Max Particles
❌ It is not in the main Emitter section
✔ It’s under Emitter Properties → GPU → Allocation

If you want, tell me:

Niagara version exactly (5.5.0 / 5.5.1)
Sprite / Mesh / Ribbon renderer
Continuous spawn or bursts

I can confirm the exact default values you should use for performance.

Below is a parameter-by-parameter breakdown of Avoid Distance Field Surfaces (GPU) in Niagara (UE 5.5). This module uses the Global Distance Field (GDF) to steer particles away from geometry.

I’ll go top → bottom, explain what it does, how it’s used, and what happens if you change it.

🔹 Module: Avoid Distance Field Surfaces (GPU)

🔧 General

Active

Enables/disables the module.
Useful for LODs or debug toggles.
When off, no DF queries or forces are applied.

Write To Intrinsic Variables

Writes results directly into particle velocity/position.
ON (recommended): module modifies Particles.Velocity
OFF: outputs values but does not apply movement

Turn OFF only if you want to manually blend the force elsewhere.

Position

The point used to sample the distance field.
Default: Particles.Position
You can offset this (e.g., forward probe, feet, head).

Offsetting forward improves obstacle anticipation.

Normal Calculation Sample Radius

Radius used to estimate surface normals from the distance field.
Larger = smoother normals, fewer jitters.
Smaller = more precise, but noisy.

Typical values

Small particles: 0.5 – 1
Large particles: 2 – 5

🔹 Nearest Surface Avoidance (LOCAL repulsion)

Nearest Surface Avoidance Strength

(Disabled in your screenshot)

Pushes particles away from the closest surface, regardless of direction.
Acts like a repulsion field.
Uses gradient of the distance field.

Use when

Particles should “hover” away from walls
Ambient avoidance (dust, fog)

High values

Strong snapping away
Can cause jitter if too high

🔹 Oncoming Surface Avoidance (DIRECTIONAL)

This is the main obstacle-avoidance logic.

Obstacle Avoidance Strength

Force applied when a surface is detected ahead.
Scales the steering/deflection force.

Too low

Particles clip into geometry

Too high

Hard direction changes / popping

Typical range:

500 – 5000 (small particles)
5000 – 20000 (fast / heavy particles)

Max Trace Distance

How far ahead the module looks for obstacles.
Measured along the Trace Vector.

Too low

Late reactions, collisions

Too high

Over-avoidance, unnecessary DF cost

Rule of thumb:

MaxTraceDistance ≥ Speed × ReactionTime

Trace Vector

Direction used for the DF trace.
Default: Particles.Velocity

Common alternatives:

Custom forward vector
Velocity * scalar
Smoothed velocity

First Frame

Boolean to detect first simulation frame.
Prevents invalid traces before velocity is initialized.

Usually left as-is. Disabling can cause spikes on spawn.

Max Iteration Count

Number of ray-march steps through the distance field.
More iterations = more accurate detection.

Typical:

3–5  → good balance
8–12 → very fast particles

Performance scales linearly with this.

Min Trace Step Size

Minimum step size during ray marching.
Prevents extremely tiny steps near surfaces.

Lower

More precision
More cost

Higher

Faster
Can miss thin geometry

Trace Direction Convergence Rate

How fast the trace direction adjusts when avoiding.
Controls smoothness of steering.

0.0 → no adjustment
1.0 → immediate response

Lower = smoother arcs
Higher = sharper turns

Trace Width

Radius of the trace.
Effectively makes the particle “fatter”.

Think of it as:

“How wide is the particle for collision purposes?”

Large width:

Earlier avoidance
Less tight gaps

Use High Quality Trace Reflection

Enables more accurate reflection calculation.
Uses additional DF samples.

Turn ON when

Fast particles
Sharp glancing collisions

Turn OFF

For large particle counts

Trace Vector’s Coordinate Space

Space used for the trace direction.

Options:

Simulation (most common)
World
Local

Use Simulation unless doing local-space emitters.

Average Trace Direction Vector Over Time

Temporal smoothing of the trace direction.
Reduces jitter and rapid oscillation.

ON:

Smooth, natural motion (recommended)

OFF:

Immediate reactions (can jitter)

Write Out Debug Line Intersection Parame

Outputs debug data for visualization.
Useful with Niagara Debugger.

⚠️ Adds overhead — disable in shipping.

🧠 How this module actually works (conceptually)

Take particle position
March forward along trace vector
Sample distance field
Detect surface intersection
Compute avoidance direction
Apply force to velocity

All on the GPU, every frame.

✅ Recommended baseline settings

For typical GPU particles:

Obstacle Avoidance Strength: 3000–8000
Max Trace Distance: velocity * 0.2–0.5 sec
Iterations: 4–6
Trace Width: 2–6
Average Trace Direction: ON

If you want, I can:

Tune this for Lumen + GDF
Tune for very fast particles
Explain how this differs from Collision (DF)
Show how to debug GDF sampling visually

Just tell me what kind of particles you’re building.

In Niagara, “find neighbours” depends on whether you’re simming on CPU or GPU. GPU has proper spatial acceleration (fast). CPU is usually done via events or custom data structures (slower).

Here are the main ways people do it in UE 5.5:

1) GPU: Neighbor Grid 3D (the standard way)

This is the go-to for boids/flocking, separation, swarm, local density, etc.

What it does

It bins particles into a 3D grid (a spatial hash), then you query the grid cell you’re in (and optionally adjacent cells) to get nearby particle indices.

Setup (typical stack)

Emitter/System (GPUCompute Sim):

Add a Neighbor Grid 3D data interface (usually in System or Emitter parameters).
Clear / Reset grid (once per frame)
- Usually a module like Neighbor Grid 3D Clear in Emitter Update.
Write particles into the grid
- Module often called something like Neighbor Grid 3D Set / Build / Write in Particle Update (or a dedicated stage).
Query neighbours
- Use a module/script like Neighbor Grid 3D Query / Find Neighbors to iterate neighbor indices and accumulate forces (separation/alignment/cohesion).

Key knobs you’ll tune

Cell Size: sets neighbor search radius baseline (smaller = more accurate, more cost).
World Bounds / Grid Extents: defines the volume the grid covers (outside = no neighbors).
Max Neighbors Per Particle: clamps loop cost.

Rule of thumb: set Cell Size ≈ your desired neighbour radius (or a bit smaller), then check 1-cell radius or 2-cell radius around.

2) GPU: Particle Attribute Reader (only for small counts / special cases)

If you just need “neighbors” for, say, a few hundred particles, you can brute-force-ish:

Read positions from another emitter using Particle Attribute Reader
Loop over a limited number of particles
Compute distances and keep the closest N

This scales badly (O(N²)) so it’s not for big swarms.

3) CPU: use Events (closest “neighbor-like” thing)

CPU Niagara doesn’t have the same fast neighbor grid workflow by default.

What you can do:

Use Collision Events (e.g., “when particles collide, send an event”)
Or create custom “proximity events” by doing a simplified distance check (only viable for small counts)
Or handle neighbor finding externally (Blueprint/C++) and feed results back (heavy but flexible)

4) GPU Fluids / Grids: use Grid2D/3D when you want density-style neighbors

If what you mean by “neighbors” is more like:

local density
“how crowded is it here?”
flow field influence

Then you can rasterize particles into a Grid3D (or Grid2D), blur/smooth, then sample the field—often cheaper than explicit neighbor loops.

Quick: which one should you use?

Flocking / separation / swarm → Neighbor Grid 3D (GPU)
Small particle count, custom pairing → Attribute Reader
Crowding/density forces → Grid field
CPU sim → events or external logic

If you answer these 2 things, I’ll give you the exact module names/stack order for your case:

Is your emitter GPUCompute Sim or CPUSim?
Do you want neighbors within a radius (e.g., 50 units) or “closest N” (e.g., closest 8)?

Below is the clean, correct way to do this in Niagara using an HLSL Expression, with notes for GPU vs CPU and common pitfalls.

Goal

Set particle alpha based on distance from a point.

We’ll compute:

Alpha = 1 at Center
Alpha = 0 at MaxRadius

(with smooth falloff)

1️⃣ Where to put this

Add a Set Variables module (or Update Color / Scale Color)
In Particle Update
Set Particles.Color.A (or Particles.Alpha if you use it)

Choose HLSL Expression for the value.

2️⃣ Required inputs (recommended)

Create or use:

Particles.Position
User.CenterPoint (float3 / vector)
User.MaxRadius (float)

3️⃣ HLSL Expression (basic)

float d = distance(Particles.Position, User.CenterPoint);
float a = saturate(1.0 - d / User.MaxRadius);
return a;

What this does

distance → Euclidean distance
d / MaxRadius → normalized distance
1 - x → invert falloff
saturate → clamps to [0,1]

4️⃣ Smooth falloff (recommended)

float d = distance(Particles.Position, User.CenterPoint);
float t = saturate(d / User.MaxRadius);
return smoothstep(1.0, 0.0, t);

Smoother edge, no hard cutoff.

5️⃣ Inverse / soft core version

If you want full alpha near center, then a gentle drop:

float d = distance(Particles.Position, User.CenterPoint);
float t = saturate(d / User.MaxRadius);
return pow(1.0 - t, 2.0); // adjust exponent

6️⃣ Using a shell / hollow sphere

float d = distance(Particles.Position, User.CenterPoint);
float inner = User.InnerRadius;
float outer = User.OuterRadius;

float a = smoothstep(outer, inner, d);
return a;

7️⃣ 2D distance (ignore Z)

float2 p = Particles.Position.xy;
float2 c = User.CenterPoint.xy;

float d = distance(p, c);
return saturate(1.0 - d / User.MaxRadius);

8️⃣ Coordinate-space gotcha (IMPORTANT)

If your emitter is Local Space:

Particles.Position is local
User.CenterPoint is usually world

Fix:

float3 centerLS = TransformPosition(
    User.CenterPoint,
    World,
    Simulation
);

float d = distance(Particles.Position, centerLS);
return saturate(1.0 - d / User.MaxRadius);

(Only needed if spaces don’t match.)

9️⃣ Common mistakes

❌ Forgetting saturate → negative alpha
❌ Dividing by zero (MaxRadius = 0)
❌ Mixing world/local space
❌ Writing to Color but using a material that ignores vertex color alpha

10️⃣ Debug tip

Temporarily output to Color.RGB:

return float4(a, a, a, 1);

So you can see the gradient.

TL;DR (copy-paste)

float d = distance(Particles.Position, User.CenterPoint);
return saturate(1.0 - d / User.MaxRadius);

If you want:

distance-based spawn kill
distance-based size / velocity
support for moving center
optimized version for large particle counts

tell me what you’re building and I’ll tailor it.