Disable Actor Component UE

2026-01-09 11:31 UTC gpt-5-2 Open in ChatGPT ↗

Yes — in Unreal Engine you can disable an Actor Component without deleting it, and there are several ways to do it depending on what you mean by “disable”.

1. Disable the component’s functionality (most common)

Blueprint

Select the component
Call Deactivate
Later, call Activate to re-enable it

This works for most components that inherit from UActorComponent.

Example (Blueprint nodes):

Deactivate
Activate

📌 Notes:

The component still exists
It won’t tick or perform its active behavior
Not all components auto-activate by default (see #4)

C++

MyComponent->Deactivate();
// ...
MyComponent->Activate();

2. Disable ticking only (component still “active”)

If you just want to stop updates:

Blueprint

Set Component Tick Enabled → false

C++

MyComponent->SetComponentTickEnabled(false);

✅ Useful when:

You want it visible or functional
But not updating every frame

3. Disable rendering / collision (for scene components)

For Scene / Primitive Components (Mesh, Collider, etc.):

Hide visually

SetVisibility(false, true);

Disable collision

SetCollisionEnabled(ECollisionEnabled::NoCollision);

Blueprint equivalents:

Set Visibility
Set Collision Enabled

4. Prevent activation at startup

If you want the component to exist but start disabled:

Blueprint

Uncheck Auto Activate in the component details panel

C++

MyComponent->bAutoActivate = false;

Then manually call Activate() when needed.

5. Temporarily disable the entire Actor (affects all components)

If you want a “soft disable” of everything:

SetActorTickEnabled(false);
SetActorHiddenInGame(true);
SetActorEnableCollision(false);

⚠️ This affects all components, not just one.

Summary

Goal	Best Option
Disable component logic	`Deactivate()`
Stop updates only	`SetComponentTickEnabled(false)`
Hide component	`SetVisibility(false)`
Disable collision	`SetCollisionEnabled(NoCollision)`
Start disabled	`bAutoActivate = false`

If you tell me:

Blueprint or C++
Which component type (mesh, audio, movement, custom)
What behavior you want disabled

I can give you the exact setup you should use.

Got it — this helps 👍
You’re looking at a custom Actor Component (TileScaler_Main) and you simply want it to NOT run when you hit Play, but still exist in the actor.

Here are the correct + minimal ways to do that.

✅ Best / Cleanest Solution: Disable Auto Activate

In the Details panel (what you’re already looking at)

Select TileScaler_Main
In Details → Activation
Uncheck ✅ Auto Activate

That’s it.

🔹 Result:

The component will not activate on BeginPlay
No ticking
No logic runs
You can still activate it later via Blueprint or C++

If it’s STILL running (very common gotcha)

If your component overrides BeginPlay() or manually starts logic, Auto Activate alone won’t stop it.

In that case, do this instead 👇

✅ Safe Blueprint-side fix (recommended)

In the TileScaler_Main Blueprint:

Event BeginPlay
→ Branch
    Condition: IsActive
        True → Run logic
        False → Do nothing

This makes the component fully respect activation state.

✅ C++ equivalent (if applicable)

If this is a C++ component:

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

    if (!IsActive())
    {
        return;
    }

    // Your logic here
}

Optional: Hard-disable ticking too

If the component ticks and you want to be 100% sure:

Blueprint

Set Component Tick Enabled → false

C++

PrimaryComponentTick.bCanEverTick = false;

(or toggle it dynamically)

Quick checklist (most people miss #2)

✅ Uncheck Auto Activate
✅ Ensure logic checks IsActive()
✅ Disable ticking if not needed

TL;DR

Uncheck Auto Activate on TileScaler_Main.
If it still runs, your logic is starting in BeginPlay without checking activation.

If you want, you can tell me:

Is this Blueprint-only or C++?
Does it use Tick, Timers, or BeginPlay logic?

I’ll give you the exact fix for your setup.

Yep — that behavior is real (and confusing at first): Auto Activate only controls whether the component becomes Active at startup.
It does not stop the component from existing, being registered, or having its BeginPlay / OnRegister run.

So your component can “still run” if any of these are true:

You have logic in Event BeginPlay (Blueprint) / BeginPlay() (C++)
You start timers, latent actions, async tasks, delegates, etc. in BeginPlay or OnRegister
You have Tick enabled anyway (or it’s being enabled somewhere)

Here’s how to actually stop it.

Fix 1 (most common): Gate your BeginPlay logic by Active state

Blueprint (inside `TileScaler_Main`)

Do this at the top of Event BeginPlay:

Is Active → Branch
- False → return / do nothing
- True → run the rest

Blueprint flow:

Event BeginPlay
Is Active
Branch
- True → your logic
- False → (nothing)

This makes Auto Activate actually mean “don’t run”.

Why this works: BeginPlay fires regardless, but “Active” won’t be true if Auto Activate is off.

Fix 2: Explicitly Deactivate + stop Tick in BeginPlay

If you want it totally dead even if something else activates tick:

Blueprint (BeginPlay)

Deactivate
Set Component Tick Enabled (false)

This is the “belt + suspenders” approach.

Fix 3: Something is starting it anyway (find the culprit fast)

Common places that re-enable it:

A) Another Blueprint calls `Activate` / `Set Component Tick Enabled(true)`

Search in Blueprints:

Activate (TileScaler_Main)
Set Component Tick Enabled
Set Active
Set Timer by Function Name/Event that targets the component

B) Logic is in OnRegister / InitializeComponent

These happen even if not active. If you bind delegates or start timers there, it will “run”.

C) It’s running in the editor (not game)

If you see it happening before play, check:

Construction Script
Any code guarded by “Run in Editor”
OnConstruction / editor utility behavior

The key Unreal rule (why you’re seeing this)

Auto Activate = off → component starts Inactive
But BeginPlay still executes, and the component can still be registered
If your BeginPlay starts timers / logic without checking IsActive, it will run

Quick “make it obey Auto Activate” pattern

Blueprint component template:

BeginPlay:
- if NOT IsActive → return
- else → start timers, bind events, enable tick, etc.

If you paste (or screenshot) the first few nodes of TileScaler_Main’s BeginPlay (or tell me if it uses Tick or timers), I can tell you exactly which piece is causing it to “run” and what to change in one step.

Looking at your graph, the “game gets stuck” when you tweak instance variables during Play is almost always because your component is doing a lot of work every frame, and when you drag a value in the Details panel Unreal applies that change many times per second (each tiny slider step = a property change). That means you’re effectively forcing your heavy Tick logic to run while the editor is also pushing updates → hitch / freeze.

What in your blueprint is causing it

From the screenshot, your component:

Runs on Event Tick
Checks Influencers length
Does a ForEachLoop over influencers
For each influencer it:
- Gets locations, distances
- Evaluates a curve
- Computes target scale
- Calls Set Relative Scale 3D on one or more mesh components

If you have many tiles and/or many influencers, this becomes expensive fast. While you drag MinScale/MaxScale/MaxEffectDistance/etc., you’re forcing the system to recompute and re-apply scale repeatedly, and that can lock the game thread.

Also: you have an UpdateInterval variable, but your logic is still on Tick, so it’s still trying to run every frame unless you explicitly throttle it.

Fix 1 (best): Stop using Tick, use your UpdateInterval with a Timer

In BeginPlay:

Set Timer by Event (Looping = true, Time = UpdateInterval)
Timer event calls your “update scaling” logic (the whole chunk you currently run on Tick)

Then remove Event Tick entirely (or disable tick).

This alone usually turns “freeze while editing” into “smooth”.

Fix 2: Only apply scale when it actually changed

Right now you’re likely calling Set Relative Scale 3D every update.

Add a small guard:

Get current scale
If NearlyEqual(CurrentScale, NewScale) → do nothing
Else → set scale

This prevents spam-setting transforms (which is surprisingly costly across many components).

Fix 3: Don’t rebuild / fetch arrays during updates

Make sure you are not doing things like:

“Get Components by Class”
“Get All Actors of Class”
Rebuilding TileMeshes every frame

Do those once in BeginPlay and cache the array.

Fix 4: Slider-drag protection (editor spam)

If you insist on realtime tweaking in PIE, add a “cooldown” throttle:

On Tick/Timer, run only if TimeSinceLastUpdate >= UpdateInterval
Or temporarily disable updates while the user is editing (simpler: increase UpdateInterval while tuning)

Quick reality check

If you have, say:

500–2000 tiles (mesh components)
and 3–10 influencers …and you’re scaling per-tile per-influencer, that’s thousands to tens of thousands of operations per update. While dragging a slider it can become catastrophic.

The fastest thing you can do right now

Replace Tick with a looping timer using UpdateInterval
Only call SetRelativeScale3D when scale changes
Cache TileMeshes + Influencers once

If you tell me roughly how many TileMeshes you have (10? 100? 1000?) and how many Influencers you typically use, I can tell you whether you need just throttling, or whether the algorithm needs restructuring (e.g., “find nearest influencer” instead of looping all).

180 tiles by itself shouldn’t hard-freeze Unreal… so when it “gets stuck” while you tweak an instance variable in PIE, it’s usually one of these two things happening:

What’s actually happening when you drag a value in the Details panel

While you drag MinScale / MaxScale / MaxEffectDistance etc., Unreal is applying that property change many times per second (every tiny mouse move). If your component reacts by doing the whole “loop tiles → loop influencers → curve eval → set scale” work, you’re effectively forcing a big recalculation dozens/hundreds of times per second, on top of your normal Tick. That can absolutely hang the game thread.

With your graph, you’re doing:

Event Tick → ForEach Influencers → math/curve → SetRelativeScale3D
likely for all 180 tiles each update

So during slider-drag, you’re doing that work way more than once per frame.

The #1 fix for your blueprint: stop running the heavy logic on Tick

You already have an UpdateInterval variable — use it to throttle updates.

Do this:

Remove/disable Event Tick (or at least don’t run the heavy chain from Tick).
In BeginPlay, use a looping timer:

Blueprint:

Event BeginPlay
Set Timer by Event (Looping = true, Time = UpdateInterval)
Timer event → runs your “update scales” logic

This makes updates happen at (say) 20 Hz instead of 60+ Hz, and prevents the “slider spam” from multiplying your workload.

Important: Clamp UpdateInterval so it can’t become 0:

set a minimum like 0.02 or 0.05

The #2 fix: don’t call SetRelativeScale3D unless the scale changed

Even with 180 tiles, repeatedly setting transforms can be expensive.

Add a guard:

Get current scale
If “nearly equal” to new scale → do nothing
Else → SetRelativeScale3D

This cuts out a ton of work when changes are small.

The sneaky cause that makes it feel like a freeze

If you’re editing variables with a slider, Unreal may send hundreds of intermediate values (and your Tick is also running). That’s why typing a value often behaves better than dragging.

If you want a quick test:

In PIE, type a value into MinScale/MaxScale instead of dragging. If it doesn’t freeze, that confirms “property spam + Tick” is the culprit.

Quick profiling check (takes 10 seconds)

Run PIE and open console:

stat game
stat blueprint

If “Blueprint Time” spikes when you drag, you’ve nailed it.

If you want, tell me: how many “Influencers” are usually in that array?

With 180 tiles, the difference between 1 influencer vs 20 influencers is massive, and it changes whether you should:

loop all influencers, or
compute nearest / early-out, etc.

No — changing an instance variable in PIE does not recompile the Blueprint.

What does happen is:

The property change is applied immediately (often many times per second while you drag).
Blueprint components can receive editor/PIE callbacks like Construction Script reruns (for actors) and “property changed” updates (in the editor).
Your logic can end up re-running more often than you think, especially if it’s on Tick and also gets triggered by property edits.

So you’re not crazy: it can feel like “it recompiles”, but it’s really the game thread being hammered by repeated updates.

Two Unreal-specific gotchas that match your symptoms (even with 180 tiles, 1 influencer)

1) Construction Script is rerunning during play

If those variables are on the Actor (Tile_BP) and you tweak them in Details, Unreal can rerun the Construction Script (or re-run component setup) while in PIE depending on what you’re editing and how.

How to confirm fast

Put a Print String in the actor’s Construction Script (or in the component’s “OnRegister/BeginPlay” if you have those).
Change a variable while playing.
If it spams prints → that’s your “freeze”.

How to stop it

Move any heavy setup OUT of Construction Script into BeginPlay (runtime) or an explicit “Initialize” function.
In the Construction Script, guard it:

Blueprint pattern:

Is Game World (or Is Playing) → Branch
- True → do nothing
- False → editor-only setup OK

In Blueprint you can use:

Is Game World (node exists in UE5)
Or Get World → World Type checks (Editor vs PIE vs Game)

Goal: Construction Script should be light and ideally editor-only.

2) You’re effectively doing “update per slider tick” + Tick

Even with 180 tiles, if you drag a slider, Unreal may apply the value dozens/hundreds of times, and if your scaling logic runs every time, you’ll hitch.

Unity’s inspector often feels smoother because it doesn’t always force the same kind of immediate runtime propagation the same way (and C# code patterns differ), but Unreal absolutely can choke if you inadvertently run heavy work on property-change frequency.

If you want realtime tuning without hangs: use an explicit “Apply” or a debounced update

Option A (best for tuning): “Apply Settings” button

Make your variables editable.
Add a BlueprintCallable function ApplySettings()
Only recompute scales when you press the button (or when you release a slider).

In pure Blueprint you can simulate this by:

Adding a boolean bDirty
When variable changes, set bDirty = true
Your timer checks bDirty, runs update once, sets bDirty = false

Option B: Debounce changes (smooth realtime)

When a variable changes:

Clear an existing timer
Start a one-shot timer for e.g. 0.1s
When timer fires, run the expensive update once

This prevents “100 updates per drag”.

Practical answer to your direct question

“Does it recompile every time I change a variable?”

✅ No, not a compile.
❗ But it can rerun Construction Script / reinitialize / trigger repeated runtime updates, which feels like a recompile because it stalls.

What I’d do in your exact setup (180 tiles, 1 influencer)

Make sure nothing heavy is in Construction Script (or guard it with Is Game World).
Replace Event Tick heavy chain with either:
- a looping timer (UpdateInterval), or
- debounced “dirty” updates while editing.
Add a “scale changed?” guard before SetRelativeScale3D.

One question I won’t make you go back and forth on — I’ll give you the next step:

Where are you editing these variables?

On the Actor (Tile_BP) instance? (most likely)
Or on the Actor Component instance?

Either way, do this quick test:

✅ Add Print String("Construction") in the Actor’s Construction Script.
✅ Add Print String("BeginPlay") in BeginPlay.
✅ Add Print String("Tick") in Tick (temporarily).
Now tweak one variable during PIE.

If Construction spams → that’s the cause and the fix is to guard/move logic.
If Tick spams and FPS dies → debounce/throttle.
If BeginPlay is firing repeatedly (shouldn’t) → something is re-spawning/re-registering.

If you tell me which print spams, I’ll tell you the exact fix path in one message.

No problem at all — this is a very common point of confusion for Unity devs 👍
I’ll walk you through it step-by-step and relate it to Unity concepts.

What the Construction Script is (Unity comparison first)

Unity equivalent:
Think of Unreal’s Construction Script as roughly:

OnValidate() + parts of Awake() that run in the editor

It:

Runs in the editor
Runs when you move an actor
Runs when you change exposed variables
Can also run when PIE starts / during PIE depending on what you edit

It is NOT gameplay runtime logic and should never do heavy work.

Where to find the Construction Script (Blueprint UI)

Step 1: Open your Actor Blueprint

This is likely your Tile_BP, not the component.

Double-click Tile_BP
You’ll see the Blueprint editor

Step 2: Look at the left panel

On the left you’ll see a panel called Graphs.

You will see something like:

EventGraph
ConstructionScript ✅ ← THIS

📌 The Construction Script is its own graph, separate from Event Graph.

Step 3: Click ConstructionScript

It opens a graph with a single node:
- Construction Script (purple header)

Anything connected here runs:

when the actor is placed
when you change a variable in Details
when the editor re-evaluates the actor

Important rule (this explains your freeze)

If you do anything expensive here, the editor/game WILL hitch or lock.

Bad things to put in Construction Script:

Loops over many components
Scaling meshes
Finding actors
Math-heavy logic
Anything you expect to run every frame

Construction Script should be:

Lightweight
Editor-only setup
Mostly “set default values / attach things”

How to tell if Construction Script is causing your issue (fast test)

Open Tile_BP
Click ConstructionScript
Add:
- Print String → text: "Construction Script Ran"
Press Play
While playing, tweak one of your exposed variables

If the log spams prints or freezes, you’ve found the culprit.

How to fix it (the correct Unreal pattern)

Rule of thumb

Construction Script: editor setup only
BeginPlay / Timers: runtime logic only

Proper pattern (Blueprint)

Construction Script

IF NOT IsGameWorld
    editor-only setup (very light)

BeginPlay

Initialize tiles
Start timers
Runtime logic

Where `Is Game World` lives

In Construction Script:

Right-click
Search for Is Game World
Use it as a Branch condition

If Is Game World == true → you’re in PIE / runtime → do nothing

Actor vs Actor Component (important for you)

Construction Script exists ONLY on Actor Blueprints
Actor Components DO NOT have Construction Scripts

So:

If your heavy logic is inside the component
But the actor’s Construction Script touches that component → changing variables can still retrigger expensive work

Unity mental model (this will help you a lot)

Unity	Unreal
OnValidate	Construction Script
Awake / Start	BeginPlay
Update	Tick
ScriptableObject settings	Data Assets
SerializedField changes	Details panel edits

One last extremely important Unreal tip

If you want realtime tuning without pain:

Use BeginPlay + timers
Never rely on Construction Script for runtime visuals
Never loop in Construction Script

If you want, next we can:

Identify whether your TileScaler_Main component is being triggered by Construction Script
Restructure your Blueprint to be “Unity-style safe”
Or I can give you a drop-in Unreal pattern for “scale tiles around influencer” that won’t hitch

Just tell me what you want to tackle next.

Perfect — this screenshot actually explains everything, and you’re right to be confused 👍
You’re not missing it.

Why you don’t see a Construction Script

You are editing TileScaler_Rework, which is an Actor Component.

👉 Actor Components do NOT have a Construction Script.
Only Actor Blueprints have one.

That’s why you only see:

Event BeginPlay
Event Tick

and no ConstructionScript graph.

So:
✅ You are correct
❌ You are not doing anything “wrong”

Where the Construction Script actually lives

It lives on the Actor Blueprint that owns this component, likely something like:

Tile_BP
or FbxScene_tiles_8pt_sample_small

To find it:

Open the Actor Blueprint (not the component)
Look in Graphs (left panel)
You’ll see ConstructionScript there

If that Actor’s Construction Script touches:

this component
its variables
its meshes
or calls functions on it

…then changing component variables in PIE can still trigger heavy work indirectly.

Now the key Unreal behavior (this answers your main question)

❓ “Does Unreal recompile the component every time I change a variable?”

No. Absolutely not.

What does happen:

When you change an instanced variable on a component during PIE:

Unreal immediately applies the new value
That value is visible to:
- Tick
- Timers
- Any logic currently running
If your logic reacts immediately (Tick does), it will:
- Re-run all math
- Re-set transforms
- Potentially do this dozens of times per second while you drag

This is not compilation, it’s synchronous runtime execution on the game thread.

That’s why it feels like a recompile.

Why this still happens with 180 tiles / 1 influencer

Your graph is doing this every Tick:

Loop tiles
Compute distance
Evaluate curve
Compute scale
SetRelativeScale3D

Now combine that with:

Tick running
PLUS property changes firing constantly while dragging a slider

You’re essentially forcing:

“Run this logic again right now, many times per frame”

Unity feels smoother here because:

C# property changes often don’t immediately trigger heavy logic unless you explicitly react
Unreal Blueprints are fully synchronous and eager

The REAL fix (component-safe, Unreal-correct, Unity-friendly)

❌ What NOT to do

Don’t expect Tick-based logic to tolerate live inspector edits
Don’t rely on Auto Activate to stop runtime work
Don’t do heavy work directly driven by exposed variables

✅ What to do instead (this will fix the freeze)

Solution 1 (best): Decouple variable edits from execution

Add a dirty flag.

Blueprint pattern:

When a variable changes → set bDirty = true
Tick (or Timer) checks bDirty
If true:
- Run update once
- Set bDirty = false

This means dragging a slider causes:

100 variable changes
BUT only one expensive update

Solution 2 (even cleaner): Stop using Tick entirely

You already have UpdateInterval.

Do this:

Disable Tick
In BeginPlay:
- Set Timer by Event (looping, UpdateInterval)
Timer event runs your scaling logic

This alone usually fixes the “Unity dev rage moment” 😄

Solution 3 (editor-only safety net)

If you want live tuning but no stalls:

Add a boolean: bEnableRuntimeUpdates
Default it OFF
Only run scaling logic if it’s ON

This lets you:

Edit values freely
Then enable updates when you’re ready

Mental model shift (important)

In Unreal:

Editing an exposed variable is equivalent to calling SetX() repeatedly on the game thread.

There is no implicit debounce.
If your logic reacts immediately → you pay immediately.

Summary (clear + direct)

You don’t see Construction Script because this is an Actor Component
Nothing is recompiling
The freeze is caused by synchronous runtime logic reacting to rapid property changes
Fix it by:
- throttling (timers),
- debouncing (dirty flag),
- or removing Tick

If you want, next I can:

Rewrite your component logic into a Unity-style “LateApply” pattern
Or give you a minimal Blueprint snippet you can literally copy-paste to fix this

Just tell me which one you want.

Gotcha — if you typed/pasted a single number and it still “gets stuck”, then it’s definitely not recompiling, and it’s not “slider spam” either.

What’s happening is almost always one of these Unreal-specific issues:

1) You’re scaling StaticMeshComponents with collision, and physics/collision rebuild is choking

SetRelativeScale3D on a StaticMeshComponent can trigger expensive collision/overlap/physics updates (depending on the mesh + collision settings). If your 180 tiles have collision enabled, doing that in Tick can be way heavier than it looks.

Quick test (takes 10 seconds):

Select one of the tile mesh components (or the meshes in the blueprint)
Set Collision Enabled = NoCollision
Also turn off Generate Overlap Events
PIE again and try changing MaxEffectDistance

If the “stuck” behavior disappears or becomes dramatically better, collision updates were the bottleneck.

Unity often feels fine here because you may not be rebuilding collision/overlap data the same way per-frame when scaling, and the engine architecture differs.

2) Your value change causes bad math (NaN/Inf), which can break transforms and stall everything

In your graph you compute distance → normalize/clamp → feed a curve → compute scale.

If MaxEffectDistance becomes 0, negative, or tiny, you can accidentally do:

divide-by-zero
huge values
NaNs

Those can propagate into scale and cause the engine to behave badly.

Fix: clamp the input Right before you use MaxEffectDistance, do:

MaxEffectDistanceSafe = Max(MaxEffectDistance, 0.001)
(or Clamp float Min = 0.001)

And if you normalize:

Clamp your curve input to 0–1.

This prevents “one innocent number change” from turning into a catastrophic value.

3) Tick is still the core problem, even with one edit

Even if you only change the value once, the very next Tick your component will:

loop tiles
compute
set scale on 180 components

If that work is heavy (collision, complex meshes, etc.), it can look like a freeze because the game thread can’t keep up.

The clean fix: don’t do this on Tick. Use your UpdateInterval properly:

BeginPlay → Set Timer by Event (looping, UpdateInterval)
Run your scaling logic there
Disable tick (Set Component Tick Enabled(false))

That turns “every frame expensive” into “controlled frequency”.

The fastest way to identify which one it is

Do these in order:

A) Check if Tick is the thing that’s “stuck”

Temporarily disconnect your Event Tick execution wire.

If changing MaxEffectDistance no longer freezes → the freeze is 100% in your Tick work.

B) If Tick is the culprit, check collision cost

Keep Tick connected but disable collision on tiles.

If it fixes it → collision/overlap updates are the main cost.

C) If it still freezes, clamp MaxEffectDistance

Clamp to >= 0.001 and clamp curve input 0–1.

One more Unreal tip (huge performance win)

If those 180 tiles are separate StaticMeshComponents, consider using an Instanced Static Mesh (ISM/HISM) long-term. Scaling 180 individual components every update is much more expensive than scaling instance transforms.

If you tell me one thing, I can pinpoint it immediately:

Are your tiles individual StaticMeshComponents, or an Instanced Static Mesh / HISM? And do they have collision enabled right now?

ok i am doing a rework and what I can see is that i managed to actually get the scale changing on a simplified version BUT then when i move the influencer the scaling is no longer working. and in the log i keep getting these error for nulls

PIE: Error: Blueprint Runtime Error: “Attempted to access TRASH_StaticMeshComponent_31 via property CallFunc_Array_Get_Item, but TRASH_StaticMeshComponent_31 is not valid (pending kill or garbage)”. Node: Set FinalScale Graph: EventGraph Function: Execute Ubergraph Tile Scaler Rework Blueprint: TileScaler_Rework PIE: Error: Blueprint Runtime Error: “Attempted to access TRASH_StaticMeshComponent_31 via property CallFunc_Array_Get_Item, but TRASH_StaticMeshComponent_31 is not valid (pending kill or garbage)”. Node: Set Relative Scale 3D Graph: EventGraph Function: Execute Ubergraph Tile Scaler Rework Blueprint: TileScaler_Rework

culd that be an issue and how do i fic it?

Yes — that error is absolutely the issue, and it also explains why scaling “works once” and then stops when you move the influencer.

What the error means (in plain English)

TRASH_StaticMeshComponent_31 = a component reference you stored earlier (in your TileMeshes array) is no longer valid.

“pending kill or garbage” means Unreal has decided that object is being destroyed / cleaned up, so any attempt to use it (SetRelativeScale3D) throws that runtime error.

This happens when you cache references to components that later get recreated or replaced.

The most common causes in your situation

Cause A: Your tiles are being regenerated / reconstructed

If your tiles come from:

an imported FBX Scene actor (FbxScene_...)
a Blueprint that rebuilds components
construction-time generation
or anything that changes components when you move something

…then Unreal may delete old mesh components and create new ones. Your array still points at the old ones → they become TRASH.

Moving the influencer might be indirectly causing the owning actor to update / re-register, depending on your setup.

Cause B: You’re filling `TileMeshes` with Get Components by Class once, then the actor changes

You cache the array once, but the underlying components change later.

Cause C: You’re caching components from something that isn’t guaranteed to exist in runtime

For example, caching editor-only components or components owned by an actor that gets respawned/reset in PIE.

How to fix it (reliable patterns)

Fix 1: Validate before using (immediate stability fix)

Before SetRelativeScale3D, add:

Is Valid (Object) on the mesh component you got from the array
If not valid → skip it (or remove it from array)

Blueprint pattern:

Array Get (TileMeshes[i])
Is Valid?
- Valid → SetRelativeScale3D
- Not Valid → (Optional) Remove item / rebuild list

This stops the runtime errors instantly.

✅ Good as a safety net
❌ Doesn’t fix the underlying “array went stale” problem alone

Fix 2: Rebuild the TileMeshes array when it becomes stale (recommended)

Instead of caching TileMeshes “forever”, rebuild it at safe times:

Option A: Rebuild once on BeginPlay, but also rebuild when invalids detected

On update loop:
- If you find any invalid tile → set bNeedRefresh = true
After loop (or next update):
- If bNeedRefresh → repopulate TileMeshes with Get Components by Class again

Option B: Don’t store components at all — store Actors or Tags and query each time

For 180 tiles, querying each update is still fine if throttled (timer).

Fix 3 (best long-term): Use Instanced Static Mesh (ISM/HISM)

If these are “tiles”, they’re perfect for ISM/HISM.

Instead of 180 separate StaticMeshComponents, you have one component with 180 instances. No TRASH references, and transform updates are much cheaper.

But I’ll keep this optional since you’re mid-rework.

Why moving the influencer breaks it

Because when you move the influencer, your code runs again and tries to scale tiles. But your TileMeshes array contains dead references, so:

It errors
That part of the loop fails / becomes unreliable
Scaling appears “stuck” or stops working

The fastest practical fix you can implement right now

Do these 3 steps:

1) Populate TileMeshes on BeginPlay (not in editor / not in construction)

In your component:

On BeginPlay:
- Owner → Get Components By Class (StaticMeshComponent)
- Store into TileMeshes

2) Add `IsValid` before SetRelativeScale3D

This prevents TRASH usage.

3) If any invalid found, refresh TileMeshes

If you detect invalid tiles, rebuild the array.

One important question (but I’ll give you the likely answer)

Are your tiles inside FbxScene_tiles_8pt_sample_small (the FBX Scene actor)? If yes: FBX scene actors and generated component hierarchies can be a bit “special” — components can be rebuilt/replaced in ways that make cached references go stale.

In that case, the most robust solution is either:

convert tiles to a Blueprint with stable components, or
use ISM/HISM, or
rebuild references when needed.

If you can paste a screenshot of where you fill the TileMeshes array (the nodes that create/populate it), I can tell you which exact fix (refresh vs stable ownership vs ISM) is the right one for your setup.

Yep — that’s exactly the scenario that produces TRASH_StaticMeshComponent_*.

When tiles come from an imported FBX scene actor, Unreal often represents them as a generated hierarchy of StaticMeshComponents that can be rebuilt / replaced (especially when the scene actor is reconstructed, re-registered, or the level/PIE resets state). If you cache those component pointers in an array, they can later become pending kill, and then your scaling code starts hitting TRASH references.

So the fix is: don’t hold onto stale component references without validating/refreshing (or move away from FBX-scene components as your runtime representation).

Here are the best options, from quickest to most robust:

Option 1: Quick stable fix (recommended right now)

A) Rebuild your `TileMeshes` list at runtime, and keep it fresh

In your component:

On BeginPlay

Owner → Get Components By Class (StaticMeshComponent)
Filter to only the tile ones (by name contains “Plane_” or by tag)
Store into TileMeshes

Every update loop

ForEach TileMeshes
- IsValid?
  - Valid → scale it
  - Not valid → set bNeedsRefresh = true

After the loop

If bNeedsRefresh:
- Rebuild TileMeshes again with Get Components By Class
- Clear bNeedsRefresh

This stops TRASH errors and keeps working even if the FBX actor rebuilds components.

B) Also: always guard SetRelativeScale3D with `IsValid`

Even if you do the refresh, keep the guard. It’s the “seatbelt”.

Option 2: Don’t cache components at all (180 tiles is fine)

Instead of storing TileMeshes, just do:

On each update:
- Owner → Get Components By Class (StaticMeshComponent)
- Loop them and scale

For only 180 components, this is totally acceptable if you’re not doing it every frame (use a timer like 0.05–0.2s).

This completely avoids the “stale pointer” class of bugs.

Option 3: Convert the FBX tiles to a runtime-friendly setup (best long-term)

FBX scene components are not a great “gameplay system” base.

Better patterns:

A) Use HISM (Hierarchical Instanced Static Mesh)

One component
180 instances
Fast, stable, no TRASH pointers
Moving influencer updates instance transforms

This is the “Unreal way” for tiles.

B) Convert each tile into a placed Actor / Blueprint actor

Heavier than HISM, but stable references and easy gameplay logic.

Why this happens (so it makes sense)

Your cached TileMeshes array is holding direct references to components that later get destroyed and replaced. Unreal marks them “pending kill”, and your blueprint tries to access them anyway:

Attempted to access TRASH_StaticMeshComponent_31 … not valid (pending kill or garbage)

So you’re not dealing with “nulls” randomly — you’re dealing with stale references to destroyed components.

The simplest “do this now” recipe

Stop filling TileMeshes in editor time (don’t populate it in defaults/construction-like logic).
Populate it in BeginPlay (runtime).
Before any use: IsValid check.
If invalid found: rebuild the array.

Tiny extra tip

If you can, tag the tile mesh components:

Select the FBX scene actor in the level
Pick a tile component
Add a Component Tag like Tile
Then when you rebuild, only keep components that have tag Tile

Filtering by name also works, but tags are cleaner.

If you show me the nodes where you currently populate TileMeshes (even a small screenshot), I’ll tell you exactly how to modify that graph (where to add IsValid, how to rebuild, and how to filter only the tile meshes).

Absolutely — here’s the “do-this-click-this” Blueprint way to fix that TRASH error.

You’ll be adding an Is Valid check right before you touch a mesh from your TileMeshes array.

What you’re checking

Each element in TileMeshes is a reference to a StaticMeshComponent.

When Unreal says it’s TRASH_* pending kill, it means:

the reference exists
but the object is no longer valid So you must check validity before calling things like SetRelativeScale3D.

Step-by-step: Add an Is Valid check in your loop

1) Find where you use TileMeshes

In your Event Graph, you probably have:

ForEachLoop over TileMeshes
then you eventually call SetRelativeScale3D using the loop item

You want to validate the loop item.

2) Add the Is Valid node

Inside the loop, do this:

Drag off the Array Element pin from the ForEachLoop
Type “Is Valid”
Choose Is Valid (the one with exec pins)

It looks like a node with:

an input object pin
two white exec outputs:
- Is Valid
- Is Not Valid

3) Wire it up

Connect:

ForEachLoop → Loop Body exec
into
Is Valid → Exec input

Then:

Is Valid exec output → into your existing logic (the stuff that ends in SetRelativeScale3D)
Is Not Valid exec output → just leave it unconnected for now (or use it to trigger a refresh later)

And make sure the Object input of Is Valid is connected to the Array Element.

So the flow becomes:

Loop Body → Is Valid(Array Element) → (Valid) → SetRelativeScale3D

What this accomplishes

✅ Stops the runtime errors
✅ Prevents your code from trying to scale destroyed components
✅ Lets the rest of the tiles still update

But it may mean some tiles stop scaling if the array contains dead references — so usually you also want a refresh (next section).

Optional but recommended: Remove invalid entries (simple cleanup)

If you don’t want to rebuild the whole list yet, you can remove invalid ones.

In the Is Not Valid branch:

Use Remove Item on the TileMeshes array
Item = that invalid Array Element

⚠️ Note: Removing items while iterating can be tricky. A safer version is:

Set a bool bNeedsRefresh = true when you detect invalids
After the loop, if bNeedsRefresh is true → rebuild the array

That’s the “clean” approach.

The clean approach: Refresh TileMeshes when invalids are found

A) Create a boolean variable

In your component:

Add variable: NeedsRefresh (Boolean), default false

B) In the loop

On Is Not Valid:
- Set NeedsRefresh = true

C) After the loop completes

Use the Completed pin of the ForEachLoop:

Branch on NeedsRefresh
- True → call a custom event/function RebuildTileMeshes
- Then set NeedsRefresh = false

D) Make RebuildTileMeshes

Create a Custom Event named RebuildTileMeshes:

TileMeshes → Clear
Get Owner
Get Components By Class (StaticMeshComponent)
Set TileMeshes to that returned array (or loop add them)

If you want to only include certain ones, you can filter by:

Component Tag (best)
Component name contains “Plane_” etc.

Where to find “Get Components by Class”

Right click in graph and search:

Get Components By Class Then set the class to:
StaticMeshComponent

TL;DR wiring cheat sheet

Inside your scaling loop:

ForEachLoop(TileMeshes)
- Loop Body → Is Valid(Array Element)
  - Valid → scale logic → SetRelativeScale3D(Array Element)
  - Not Valid → NeedsRefresh = true
- Completed → if NeedsRefresh → rebuild list

If you want, reply with a close-up screenshot of the part of your graph where TileMeshes feeds into SetRelativeScale3D, and I’ll tell you exactly where to insert the Is Valid node (like “put it between node X and node Y”).

Great question — and this confusion is 100% normal in Unreal.

✅ The exact one you want

You want Is Valid with EXEC pins.

How to identify it:

It has:
- a white exec input
- two white exec outputs:
  - Is Valid
  - Is Not Valid
It has one blue Object input pin

This is the one you use for runtime safety.

❌ Ones you should NOT use (common traps)

`Is Valid (Pure)`

No exec pins
Returns a boolean
Easy to misuse
Can still allow invalid objects to flow into later nodes

👉 Avoid this for now.

`Is Valid Low Level`

C++ / engine-internals check
Not appropriate for Blueprint gameplay logic

👉 Ignore.

`Is Actor Being Destroyed`

Only for Actors
Your tiles are components, not actors

👉 Not applicable.

📌 Why the exec-pin version is the correct one

Because it stops execution.

When an object is TRASH_* / pending kill:

Passing it into SetRelativeScale3D crashes logic
The exec-based Is Valid prevents execution from continuing at all

Think of it like:

if (!IsValid(Component)) return;

Blueprint-wise, this is the only safe version for runtime object references.

How to spawn it quickly (step-by-step)

Drag a wire from the Array Element pin (your StaticMeshComponent)
Release mouse
Type Is Valid
Choose Is Valid (NOT “pure”)

Visual wiring (mental image)

ForEachLoop
   Loop Body
      ↓
   Is Valid (Exec)
      ├─ Is Valid     → SetRelativeScale3D
      └─ Is Not Valid → (do nothing / mark refresh)

Unity mental mapping (for your sanity 😄)

Unity	Unreal Blueprint
`if (obj != null)`	Is Valid (exec)
Destroyed GameObject	TRASH_* pending kill
Serialized reference	Cached component pointer

One last sanity check

After you add this node:

Those TRASH errors should stop immediately
Scaling should resume for valid tiles
Invalid tiles will simply be skipped

If you want, next I can:

show you how to filter only tile meshes
or how to rebuild TileMeshes safely
or help you move this to Instanced Static Mesh (which avoids all of this)

Just tell me what you want next.

You’re super close — the only missing piece is that your RebuildTiles event never gets called from the main execution flow, and even if it did, you’re currently rebuilding the array in a way that will only ever give you one component (because of that Make Array node).

Let me explain how it should “tie back” in Blueprint terms, and what to change in your graph.

What the rebuild is supposed to do

The rebuild exists for one purpose:

If you detect any invalid tile component during your loop, set a flag, and after the loop finishes, rebuild TileMeshes once.

You do not want to rebuild in the middle of iterating.

So the pattern is:

Loop tiles
If tile invalid → NeedsRefresh = true
When loop completes → if NeedsRefresh → call RebuildTiles() and set flag back to false

That’s the “tie back”.

What to fix in your current graph

✅ Fix A: Connect `ForEachLoop (TileMeshes) → Completed` to the rebuild check

Right now you set NeedsRefresh but I don’t see anything that uses it.

Do this:

From your TileMeshes ForEachLoop node:
- take the Completed exec pin
Add a Branch
- Condition = NeedsRefresh
On True:
- Call RebuildTiles
- Set NeedsRefresh = false

So it becomes:

ForEachLoop(TileMeshes).Completed → Branch(NeedsRefresh) → True → RebuildTiles → Set NeedsRefresh false

That’s the missing link.

✅ Fix B: Your RebuildTiles graph should assign the whole returned array

Inside RebuildTiles, you currently have:

Clear TileMeshes
Get Components by Class (good)
then Make Array (bad here)

That Make Array creates an array with a fixed number of items (often 1), so you’re throwing away most of the components.

Instead, do this inside RebuildTiles:

Get Owner
Get Components By Class (StaticMeshComponent)
Set TileMeshes = Return Value (directly)

No Make Array.

So your RebuildTiles should be basically:

RebuildTiles (Custom Event)

GetOwner
GetComponentsByClass(StaticMeshComponent)
Set TileMeshes to the returned array

(Optional: filter by tag/name later)

Extra important: your Tick flow should early-out cleanly

You already have:

Influencers Length > 0 check Good.

You also want to skip scaling work if TileMeshes is empty (sometimes it will be briefly after clearing).

Add another check before the TileMeshes loop:

Length(TileMeshes) > 0 → Branch → True runs loop

One more issue I see: nested loops and exec path

You have:

ForEach(TileMeshes)
- IsValid?
- then inside valid path you also loop Influencers

Since you only have one influencer, you don’t need a loop there — just use Influencers[0].

This won’t “fix” the rebuild problem, but it will make the logic simpler and less error-prone.

How it should read (literal flow)

Here’s the exact intended execution story:

Tick (or timer)
- if Influencers empty → stop
- For each TileMesh:
  - if not valid → NeedsRefresh = true, continue
  - else compute scale and apply
- after tiles loop completes:
  - if NeedsRefresh → RebuildTiles, NeedsRefresh=false

That’s it.

Quick sanity checks (to confirm it’s working)

Add temporary prints:

In Is Not Valid branch: Print "Invalid tile detected"
In RebuildTiles: Print "Rebuilding tiles: " + Length(TileMeshes)

When you move influencer and it breaks, you should see:

invalid detected
rebuild runs
tile count repopulates

Summary of the two concrete edits you should make

Use the Completed pin of your TileMeshes ForEachLoop to trigger the NeedsRefresh branch and call RebuildTiles.
In RebuildTiles, set TileMeshes directly from Get Components By Class return value — remove Make Array.

If you want, I can also tell you how to filter only the tile components (FBX scenes include lots of StaticMeshComponents you may not want), using either:

component tags, or
name contains “Plane_…” (quick and dirty)

Just say which you prefer.

Got you — I’ll be super explicit and “Unity-dev friendly”. You’re one wiring step away.

In Blueprints, “calling” your RebuildTiles custom event is literally just: place the event call node and connect an execution wire into it.

Right now, your red RebuildTiles node is the event definition (where the event lives). To call it from elsewhere, you add a call node.

Part 1 — Add the Branch on the loop “Completed”

You already have:

ForEachLoop(TileMeshes)
- IsValid
- if not valid → Set NeedRefresh = true

Now do this:

Step A) Drag from the `Completed` pin

Click your TileMeshes ForEachLoop node
Grab the Completed white pin (bottom-right)
Drag a wire out into empty space
Release → search for Branch
Pick Branch

Step B) Connect the condition

Drag your boolean variable NeedRefresh into the graph
- choose Get NeedRefresh
Connect it into the Branch’s Condition pin

Now you have:

ForEachLoop.Completed → Branch(NeedRefresh)

Part 2 — “Call RebuildTiles” (this is the part you asked)

There are two ways. Use Way 1.

✅ Way 1 (best): create a Call node from the event name

Right click in empty space in the graph
Type: RebuildTiles
You should see something like:
- Call RebuildTiles (Custom Event)
Click it

You’ll get a node that looks like a red event node but it will be a call, with a white exec input.

Wire it:

Branch True → Call RebuildTiles exec input

That’s calling it.

Then reset the flag:

After the RebuildTiles call:

Add Set NeedRefresh
set it to false
Connect: RebuildTiles → Set NeedRefresh(false)

So the full flow becomes:

Completed → Branch

True → Call RebuildTiles → Set NeedRefresh(false)
False → do nothing

Way 2: convert RebuildTiles into a Function (optional)

If the “call” search confuses you, you can make a Function named RebuildTiles and call it like any other function. But Way 1 is totally fine.

Part 3 — Your RebuildTiles logic is currently wrong (important)

In your screenshot you are using:

Get Component by Class (singular)
then Make Array (so you only store ONE component)

That means TileMeshes becomes an array containing only one mesh, not all tiles.

You need:

✅ Get Components By Class (plural)

Fix it inside RebuildTiles:

Delete Get Component by Class and Make Array
Add Get Components By Class
- Right click → search Get Components by Class
- Target = Owner
- Component Class = StaticMeshComponent
Connect its Return Value (array) directly into your Set TileMeshes

So RebuildTiles should be:

RebuildTiles (event) → Clear TileMeshes → Get Owner → Get Components By Class → Set TileMeshes

No Make Array node at all.

Part 4 — Where to put the RebuildTiles event itself

It can live anywhere in the graph. It doesn’t need to be “wired into” the main flow directly. It’s like a Unity method: it exists, and you call it when needed.

Quick checklist (so you know it’s correct)

After doing this:

✅ When an invalid mesh is found, you set NeedRefresh = true
✅ After the loop ends, Completed fires
✅ Branch sees NeedRefresh == true
✅ It calls RebuildTiles once
✅ RebuildTiles repopulates TileMeshes with a fresh array
✅ NeedRefresh is reset to false

Bonus: you can test it easily

Add a Print String node at the start of RebuildTiles:

“RebuildTiles called” And another after setting TileMeshes:
“TileMeshes count: ” + Length(TileMeshes)

If it prints and count is ~180, you’re golden.

If you want, I can mark up your screenshot logically (“connect this pin to this pin”) but the steps above should get you there. The big must-fix is switching to Get Components By Class (plural) so you’re not rebuilding to a 1-element array.

Great instinct — you’re thinking about it the right way.

No, it won’t create errors as long as you route execution correctly.

The key idea is:

Per-tile validity check decides whether you run scale logic for that tile
The global boolean (NeedRefresh) is only a “hey, we saw at least one dead tile” flag that tells you to rebuild after the loop

So you do both:

Skip invalid tiles so you don’t crash
Rebuild the list once at the end so next update has fresh references

What will cause errors (and what your screenshot currently suggests)

In your screenshot, it looks like you’re doing:

Is Valid → (maybe) setting NeedRefresh

But you must ensure:

Only the “Is Valid” exec pin goes into your scaling logic
Only the “Is Not Valid” exec pin sets NeedRefresh = true
The invalid tile must not continue into SetRelativeScale3D

Correct wiring (per tile)

ForEach Loop Body → Is Valid (exec)

Is Valid → run scale math → SetRelativeScale3D (using Array Element)
Is Not Valid → Set NeedRefresh = true → (then do nothing else for this tile)

That way:

Valid tiles still scale
Invalid ones are simply skipped
No TRASH access happens

Then the global part

After the tile loop finishes:

ForEach.Completed → Branch(NeedRefresh)

True → Call RebuildTiles → Set NeedRefresh = false
False → nothing

This rebuild happens once, not per invalid tile.

Why this is safe even with a mix of valid/invalid

Suppose:

170 tiles are valid
10 tiles are TRASH

During the loop:

170 go through “Is Valid” path → scale fine
10 go through “Is Not Valid” path → set NeedRefresh = true, skip scaling
End of loop → rebuild once → next tick/update, hopefully all are valid again

No errors, because you never run SetRelativeScale3D on invalid ones.

One more important improvement

Your NeedRefresh should only ever be set to true inside the loop (when you find an invalid). Don’t set it back to false inside the loop.

Reset it only here:

after RebuildTiles runs
or right before the loop starts each update

Simple pattern:

At start of update (tick/timer):

Set NeedRefresh = false Then run the loop.

This avoids stale “true” lingering forever if rebuild didn’t happen yet.

Mini-checklist

✅ “Is Valid” path connects to scaling logic
✅ “Is Not Valid” path ONLY sets NeedRefresh (and does NOT scale)
✅ Completed pin triggers rebuild if NeedRefresh is true
✅ NeedRefresh is reset to false after rebuild (or at start of update)

If you post the slightly wider part of the graph showing where your Is Valid outputs go (to scaling / to NeedRefresh), I can tell you if your wiring matches this safe pattern.

Nice — easiest way in Unreal is to drive a material parameter from the same value you’re already using for scale.

There are two common setups:

Best practice: use a Dynamic Material Instance (MID) per tile and set a color parameter.
If all tiles share one material and you want per-tile variation: use Per-Instance Custom Data (only for ISM/HISM). Since you’re using separate mesh components from an FBX, go with MIDs.

Below is the MID approach, step-by-step, Blueprint friendly.

1) Prep the material (one-time)

Open the material used by your tile meshes.

Add a Vector Parameter named TintColor (exact name matters for sanity).
Multiply your Base Color (or Albedo) by TintColor.
- Example: BaseColorTexture * TintColor → Base Color
Save.

Now the material can be tinted from Blueprint.

2) In your component: create Dynamic Material Instances for each tile

You don’t want to call “Create Dynamic Material Instance” every tick. Do it once when you build TileMeshes.

Add a variable:

TileMIDs : Array of Material Instance Dynamic
- Type: MaterialInstanceDynamic (MID)

When you build `TileMeshes` (BeginPlay / RebuildTiles):

For each tile mesh component:

Create Dynamic Material Instance
- Target: the tile StaticMeshComponent
- Element Index: 0 (usually 0)
Add the returned MID to TileMIDs (same order as TileMeshes)

Blueprint nodes you’ll use:

ForEachLoop (TileMeshes)
Create Dynamic Material Instance (on the mesh component)
Add (to TileMIDs array)

📌 Important: if your mesh has multiple material slots, you may need element index 0/1/etc.

3) On update: compute a color from scale and set the parameter

You already compute a Scale (or FinalScale). Use that to make a 0–1 value.

A) Normalize scale to 0–1

Let’s say you scale between MinScale and MaxScale:

Alpha = (Scale - MinScale) / (MaxScale - MinScale)
Clamp 0–1

In Blueprint:

NormalizeToRange node (Value = Scale, RangeMin = MinScale, RangeMax = MaxScale)
Then Clamp (float) 0..1 (optional but safe)

B) Convert Alpha to color

Simplest: use LinearInterpolate (Lerp) between two colors.

Nodes:

LinearColorLerp (or “Lerp (LinearColor)”)
- A = low color (e.g., blue)
- B = high color (e.g., red)
- Alpha = your normalized value

C) Set the material parameter

Get the MID for this tile
Call Set Vector Parameter Value
- Parameter Name: TintColor
- Value: the lerped color

Keeping TileMeshes and TileMIDs aligned

Because you’re looping tiles, you need the matching MID.

Best way:

Use the Array Index output of the TileMeshes ForEachLoop
Use Get on TileMIDs with that same index

Flow inside the loop:

TileMesh = Array Element
Index = Array Index
MID = TileMIDs[Index]
Set tint on MID

Also add IsValid checks:

IsValid(TileMesh) before scale
IsValid(MID) before setting parameter

If you rebuild TileMeshes, rebuild TileMIDs too (clear and recreate).

Quick “minimal” graph logic (what it looks like)

Inside the valid tile path:

compute Scale
apply SetRelativeScale3D
Alpha = NormalizeToRange(Scale, MinScale, MaxScale)
Color = Lerp(ColdColor, HotColor, Alpha)
MID = TileMIDs[Index]
MID → SetVectorParameterValue("TintColor", Color)

Two gotchas (so you don’t get stuck)

Gotcha 1: “Nothing changes color”

You forgot to make the material use the TintColor parameter.
Or you’re setting the wrong parameter name (must match exactly).

Gotcha 2: “Only some tiles change”

Some tiles have a different material slot layout, or element index isn’t 0.
Try element 0 first; if needed, loop material slots.

If you tell me one thing, I can make this exact for your tiles: Do all tiles share the same material, and is it in slot 0?
If you don’t know, it’s fine — I can tell you how to check in the StaticMesh asset and in the component details.

Perfect — this is exactly the right place to slow down and map Unreal concepts to Unity ones 👍
I’ll walk you from zero, assuming no Unreal knowledge, but I’ll keep it technically precise.

Mental model first (Unity → Unreal)

Unity	Unreal
Mesh Renderer	StaticMeshComponent
Material	Material
Material Instance	Material Instance
MaterialPropertyBlock	Dynamic Material Instance (MID)
Prefab	Blueprint
FBX imported mesh	StaticMesh asset

Your tiles come from an imported FBX, so their material is assigned on the StaticMesh asset (or overridden per component).

Step 1 — Find the tile StaticMesh asset

This is the most important step.

Option A (fastest)

In the Level viewport, select one tile
Look at the Details panel (right side)
Find Static Mesh
- You’ll see the mesh name (e.g. Plane_fracturepart800_2)
Click the magnifying glass icon 🔍 next to it

➡️ This jumps you to the StaticMesh asset in the Content Browser.

Option B (Content Browser)

Open Content Drawer (Ctrl + Space)
Search for part of the mesh name you see in the Details panel
Double-click the StaticMesh asset

Step 2 — Open the StaticMesh asset

Double-click the StaticMesh.

You’re now in the Static Mesh Editor.

Step 3 — Find the material slot (this is where the tile material “lives”)

In the Static Mesh Editor:

Look at the Details panel
Find Materials
You’ll see:
- Element 0
- Possibly Element 1, 2, etc.

Each element is a material slot (Unity sub-mesh equivalent).

The material listed there is what the tile uses by default.

📌 99% of the time it’s Element 0

Step 4 — Open the material

Click the material name in Element 0
Double-click it

You are now inside the Material Editor.

This is Unreal’s shader graph (conceptually similar to Shader Graph).

Step 5 — Add a color parameter (do this carefully)

A) Add a Vector Parameter

Right-click in empty space
Search Vector Parameter
Name it exactly:

TintColor

(Default value: white)

B) Plug it into Base Color

Typical setup:

If the material already has a texture:
- Multiply BaseColorTexture × TintColor
- Plug result into Base Color

If it’s flat color:

Plug TintColor directly into Base Color

C) Save the material

Click Save.

At this point:

The tiles will still look the same (TintColor = white)
But they are now controllable from Blueprint

Step 6 — Why Dynamic Material Instances exist (Unity analogy)

In Unity you’d do:

renderer.material.SetColor(...)

In Unreal:

You must create a Dynamic Material Instance (MID) at runtime
You cannot safely modify the base material directly

So:

Material = shared asset
MID = per-tile runtime copy

Step 7 — Where the MID will be created (don’t do it every frame)

You will create the MID when you build TileMeshes, not in Tick.

Typical places:

BeginPlay
RebuildTiles

Later, when scaling:

You only set the color parameter

Sanity check (do this now)

Before touching Blueprint:

Select a tile in the level
In Details → Materials
Temporarily override the material with a bright color
Confirm the tile changes color

This ensures:

You found the correct material
The mesh is using it

What comes next (tell me when ready)

Next steps will be:

Create a Dynamic Material Instance per tile
Store them in an array aligned with TileMeshes
Drive TintColor from your computed scale

But don’t do that yet until you confirm:

“Yes, I found the material and added the TintColor parameter.”

Reply with:

✅ “Found it and added TintColor”
or ❌ “I’m stuck at step X” and I’ll guide you through that exact step.

Yes — and the reason it “locks up” is usually that you’re unintentionally forcing Unreal to update hundreds of components / run construction while you’re trying to assign materials. With FBX scene imports, that can be especially painful.

Here are the efficient ways to do it so it doesn’t hang.

The most efficient approach: change the material on the Static Mesh asset, not on every tile component

Because your tiles come from an FBX, they’re almost certainly many StaticMeshComponents that all reference one (or a few) StaticMesh assets.

If you change the material on the mesh asset, all instances update automatically.

Steps

Pick one tile in the level.
In Details → Static Mesh, click the 🔍 magnifying glass to locate the mesh asset in the Content Browser.
Double-click the StaticMesh asset to open it.
In the Static Mesh Editor, find Details → Materials.
For Element 0, assign your new material.
Save.

✅ This changes the default material for every component using that mesh.
✅ You do it once, not 180+ times.
✅ Much less likely to freeze.

If your FBX created many unique mesh assets (one per tile), you’ll need bulk-edit (see below).

If you have many different StaticMesh assets: bulk-assign using the Content Browser

Don’t do this in the level viewport. Do it in the Content Browser.

Bulk edit via Property Matrix (fast + safe)

In the Content Browser, filter to Static Mesh.
Select all the tile mesh assets you want (Shift-select).
Right-click → Asset Actions → Bulk Edit via Property Matrix.
Find Materials / Static Materials.
Set Element 0 to your new material.
Save all.

✅ One operation, applies to many assets.
✅ Doesn’t require selecting hundreds of actors/components in the level.

If UE freezes when you even select the FBX scene actor

This is common with FBX scene imports because the actor contains a huge component hierarchy.

Avoid editing on the actor/component level

Don’t multi-select 180 components in the Outliner and change materials.
Don’t click the top “FBX scene” actor and try to edit all children.

Instead:

Edit the StaticMesh assets (approach above)
Or replace materials using a bulk tool

Best workflow to create your own material (without freezing)

In Content Browser:
- Right click → Material (create M_TileBase)
(Optional) Right click M_TileBase → Create Material Instance (MI_TileBase)
Assign MI_TileBase to the StaticMesh asset(s), not the placed components.

Why material instance?

You can tweak parameters without recompiling shaders constantly.
It’s lighter to edit.

Two settings that can make things feel “stuck” (easy wins)

1) Shader compilation

If you create a complex new material, UE will compile shaders and can appear frozen. Open Window → Developer Tools → Shader Compile (or check the bottom-right “Compiling Shaders…”).

Tips:

Start with a simple material first (flat color).
Use a Material Instance for tweaks.

2) Real-time thumbnail / viewport updates

Turn off expensive live updates while editing:

Content Browser: disable real-time thumbnails if needed
Viewport: turn off Real Time (Ctrl+R) temporarily

Create a simple base material M_TileBase
Create MI_TileBase
Assign MI_TileBase on the StaticMesh asset (or bulk edit meshes)
Then your Blueprint can create Dynamic MIs from MI_TileBase per tile for tinting.

Quick question that determines the exact best method (no back-and-forth)

When you select a tile, does the Static Mesh name look like the same asset reused, or does every tile have a unique mesh asset name?

If it’s reused → change one StaticMesh asset material and you’re done.
If they’re unique → use Bulk Edit via Property Matrix on all StaticMesh assets.

Yes — you can set materials at import, and for FBX scenes this is actually the cleanest + fastest way to avoid freezes later 👍
Unreal does support this, but it’s a bit hidden and works differently than Unity, so I’ll explain clearly.

Short answer (what is possible)

When importing an FBX into Unreal, you can:

✅ Automatically create materials
✅ Automatically create material instances
✅ Replace / override materials using naming rules
⚠️ You cannot directly say “use THIS existing material for everything” unless you use one of the methods below

Best options (from most to least efficient)

✅ OPTION 1 (BEST): Use a Material Instance via naming convention

This is the most Unreal-native and scalable workflow.

How it works

Unreal matches materials in the FBX by name.

If your FBX references a material called, say:

Tile_Mat

And in Unreal you already have:

MI_Tile_Mat

You can tell Unreal:

“When you see Tile_Mat, use my Unreal material instead of creating a new one.”

Step-by-step

Before importing, create your material:
- M_TileBase
- Create a Material Instance: MI_Tile_Mat
In your DCC (Blender / Maya):
- Assign a material named exactly Tile_Mat to all tiles
- Export FBX
In Unreal:
- Import FBX
- In the import dialog:
  - Material Import Method → Do Not Create Materials
  - Search Location → All Assets
  - Enable Import Materials (but not create new ones)
Unreal finds MI_Tile_Mat and assigns it automatically.

✅ No freezing
✅ One material for all tiles
✅ Clean asset graph

✅ OPTION 2: Use the FBX import option “Create Material Instance”

If you don’t care about naming yet.

Import settings

In the FBX Import Options:

Material Import Method → Create New Instanced Materials
Choose a Base Material (e.g. M_TileBase)

Unreal will:

Create Material Instances for each FBX material
All instances derive from your base material

This is extremely efficient and avoids shader recompilation hell.

📌 This is often the best choice for large FBX scenes.

⚠️ OPTION 3: Replace materials AFTER import (still safe if done right)

If the FBX is already imported:

Do NOT select tiles in the level
Do NOT change materials per component

Instead:

Go to StaticMesh assets
Use Bulk Edit via Property Matrix
Replace Element 0 material there

Still safe, but import-time is better.

Why Unreal “freezes” when you do it manually

When you:

Select the FBX Scene actor
Change materials on many components
Or create new materials on the fly

Unreal:

Rebuilds render state
Recompiles shaders
Re-evaluates component hierarchies

With hundreds of components, this can lock the editor.

Import-time assignment avoids all of that.

Do this exact pipeline:

Create M_TileBase
Create MI_TileBase
Import FBX with:
- Material Import Method = Create New Instanced Materials
- Base Material = M_TileBase
Never touch materials on components again

Later:

Your Blueprint creates Dynamic Material Instances from the MI
You set TintColor per tile

One last important Unreal tip (huge)

If your tiles are purely visual:

Disable Collision
Disable Generate Overlap Events

This massively reduces editor hitching when materials or transforms change.

If you want, tell me:

Which DCC you’re exporting from (Blender? Maya?)
Whether all tiles share the same material in the DCC

I’ll give you exact import settings (checkbox by checkbox) for your setup.

You’re not crazy 🙂 — you’re looking at the FBX Scene Import dialog, and that’s why the options I mentioned aren’t where you expect them.

Unreal has two different FBX import paths, with different UIs:

Why you don’t see “Material Import Method”

You are using FBX Scene Import

This is what you get when you import an FBX that contains many objects
It creates an FBX Scene Actor with lots of components
The dialog you showed is normal for Scene Import
The “Create New Instanced Materials” dropdown does NOT exist here

The options I mentioned earlier are from the regular FBX Static Mesh import, not Scene Import.

So nothing is wrong with your Unreal version — it’s just a different importer.

What you CAN do with FBX Scene Import (your case)

✅ Option A (BEST for you): Assign materials by name (works with Scene Import)

This does work with the Scene importer.

How it works

Unreal matches FBX material names to Unreal materials
If names match, Unreal uses your material instead of creating new ones

Exact steps

Create your material first in Unreal
Example:
- M_TileBase
- (or a Material Instance like MI_TileBase)
In your DCC (Blender / Maya):
- Assign one material to all tiles
- Name it exactly the same as your Unreal material
  (case-sensitive is safest)
Re-import the FBX Scene
- Unreal will auto-assign your material
- No freezing
- No manual reassignment

📌 This is the only clean “set material on import” option for FBX Scene Import.

✅ Option B: Let Unreal create materials, then replace them once (safe)

If renaming in DCC is annoying:

Import FBX Scene normally
Unreal creates many materials
In Content Browser:
- Filter → Material
- Select all FBX-created materials
- Right-click → Asset Actions → Replace References
- Replace with MI_TileBase

This replaces all references in one go, without touching components.

⚠️ What you CANNOT do in FBX Scene Import

You cannot:

Pick a “Base Material”
Choose “Create New Instanced Materials”
Assign materials per-mesh in the import UI

Those options only exist for non-scene FBX imports.

Why Unreal did this (context)

FBX Scene Import is designed for:

Architectural scenes
DCC-authored hierarchies
Round-trip workflows

So Epic assumed materials come from DCC and are matched by name.

Best-practice pipeline

In Unreal:
- Create M_TileBase
- (Optionally) MI_TileBase
In DCC:
- Assign one material to all tiles
- Name it exactly MI_TileBase (or M_TileBase)
Import FBX Scene
Never touch materials on components again
At runtime:
- Create Dynamic MIDs from the assigned material

This avoids:

editor freezes
mass component updates
material chaos

One last important performance tip

Since these are tiles:

Disable Generate Missing Collision
Disable Collision on the StaticMeshes unless needed

This dramatically improves editor responsiveness when materials or transforms change.

If you tell me:

Which DCC you’re using (Blender / Maya)
Whether all tiles already share one material there

I’ll give you exact naming + export settings so the import works perfectly on the first try.

Yeah — it often doesn’t “just work” with FBX Scene Import, even if the names match, because the Scene importer won’t automatically search your project for an existing material unless you tell it to. Also, if the mesh already has a material assigned (from the first import), reimport can keep the old assignment.

Here’s the reliable way to make it work, and two backup workflows that are fast and don’t freeze UE.

1) The reliable “use my existing material on Scene Import” method

A) Confirm the name you must match

Unreal matches against the FBX material name (the one from Blender/Maya), not the mesh name.

In your DCC:

Pick the material assigned to the tiles
Make sure its name is exactly e.g. M_TileBase (or whatever you want)

⚠️ If the FBX actually has multiple materials (even accidentally), Unreal will create multiple slots and it won’t map the way you expect.

B) In Unreal: use the Materials tab in the Scene Import window

In the dialog you screenshotted, click the Materials tab at the top (next to Static Meshes).

In there, look for settings like (names vary slightly by UE version):

Import Materials (toggle)
Material Import Method (or similar)
Search Location / Material Search (or similar)

What you want is:

✅ Material Import Method = “Do Not Create Materials” (or “Use Existing Materials”)
✅ Search Location = “All Assets” (or “Under /Game”)
✅ If there’s an option like “Import Textures” turn it off (optional)

Then import / reimport.

If you don’t set “Search Location / Use Existing”, Unreal will happily create new materials even if yours exists.

C) If this is a reimport: reset what’s already assigned

If you already imported once, your StaticMeshes likely have their material slots already set to the auto-created materials, and reimport may preserve them.

To force the new mapping, do one of these:

Fastest clean reset:

Delete the imported FBX-created materials (or move them out of the way), then reimport with “Do Not Create / Use Existing”.

Per StaticMesh asset (slower, but precise):

Open one of the StaticMesh assets → Materials section → reset/clear overrides (wording varies), then reimport.

2) If Scene Import still won’t map: use “Replace References” (very fast, no freezing)

This is my go-to because it’s deterministic.

In Content Browser, find one of the auto-created materials Unreal made from the FBX (e.g. M_MatFromFBX_01)
Right-click it → Asset Actions → Replace References
Choose your material (M_TileBase or MI_TileBase)
Confirm

This replaces it everywhere it’s used (all meshes, all components) in one shot.

✅ Works even if Scene Import mapping fails
✅ Doesn’t require selecting 180 tiles
✅ Doesn’t freeze the editor like mass component edits

3) If you have many StaticMesh assets: bulk edit materials on the mesh assets

If your FBX scene produced lots of individual StaticMesh assets:

Content Browser → filter Static Mesh
Select all tile meshes
Right click → Asset Actions → Bulk Edit via Property Matrix
Find Materials / Static Materials
Set Element 0 to your material

Also fast, also stable.

The most common reason your “automatic” didn’t happen

One of these:

You didn’t set the Scene importer to search existing materials (Materials tab)
FBX has multiple material names (even if they look “the same” in the DCC)
You already imported once and reimport is preserving existing material assignments
Your Unreal material is a Material Instance, but the FBX name matches a different asset name (or vice versa)

Quick thing to tell me (and I can pinpoint the exact fix)

In your FBX Scene Import Options window, if you click Materials tab, what options do you see there?
(Just a screenshot of that tab is enough.)

In the meantime, if you want the “it will work 100%” path: Replace References is the safest and fastest.

This is a very important Unreal concept, and it’s exactly where FBX Scene Import vs normal FBX Import matters.

Short answer first, then the “why”:

To get ONE actor in the level instead of 500, you must use FBX Scene Import and then place the generated Scene Actor.

If you use normal FBX import + drag assets in, you’ll get many actors.

The correct way (ONE actor in the scene)

Step-by-step (this is the safe, intended workflow)

Import the FBX into the Content Drawer
- Drag the FBX file into the Content Drawer
- When the import dialog appears:
  - Make sure it says FBX Scene Import Options at the top
    (this confirms you’re in scene import mode)
Import
- Don’t worry about all the meshes listed
- Click Import
Find the generated Scene asset After import, Unreal creates:
- A folder with StaticMesh assets
- An FBX Scene asset (looks like a little hierarchy icon)
Drag the FBX Scene asset into the level
- Drag the Scene asset, NOT the individual meshes
- This spawns one Actor in the level

That actor:

Has 500 StaticMeshComponents inside it
Appears as ONE actor in the World Outliner
Can be moved/rotated/scaled as a whole

Why you’re probably seeing 500 actors right now

You’re likely doing one of these:

❌ Dragging StaticMesh assets into the level
❌ Importing as individual Static Meshes (non-scene import)
❌ Using “Import Into Level” incorrectly
❌ Selecting all meshes and placing them

Each StaticMesh dragged in = one Actor.

How to confirm you imported as a Scene

In the Content Drawer, look for:

An asset with:
- A hierarchy icon
- Name similar to your FBX file
- Type: FBX Scene

That’s the one you want to drag into the level.

If you don’t see that:

You did not import as a Scene
You likely used standard Static Mesh import

If you already imported “wrong” (no Scene asset)

You have two options:

Option A (best): Reimport properly

Delete the imported assets
Reimport the FBX
Ensure the dialog is FBX Scene Import Options
Then place the Scene asset

Option B (convert after import)

Select all mesh Actors in the level
Right-click → Attach To → choose one parent actor

⚠️ This still keeps many actors, just attached — not ideal.

Important performance note

Even though it’s “one actor”, it’s still:

500 StaticMeshComponents
Each with its own transform, draw call (unless instanced), collision, etc.

For runtime-heavy logic (scaling, coloring):

HISM / ISM is the real optimal solution
But Scene Import is totally fine for now and good for learning

Unity mental model

Unity	Unreal
One GameObject with many MeshRenderers	One Actor with many StaticMeshComponents
Prefab	Blueprint / FBX Scene Actor

TL;DR

Import using FBX Scene Import
Drag the Scene asset into the level
You get one actor, not 500
Don’t drag individual meshes

If you want, next I can:

Show how to convert an FBX Scene Actor into a Blueprint
Or how to convert it into a HISM-based actor (huge perf win)
Or how to add your TileScaler component safely to the Scene Actor

Just tell me what you want next.

This is a very common Unreal gotcha, and you’re not doing anything wrong.

Short answer

FBX Scene Import options do NOT appear when you just drag-and-drop into the Content Drawer unless Unreal decides the FBX is a “scene”.
To force Scene Import (one actor), you must use Import Into Level or explicitly enable Import as Scene.

The reliable way (this always works)

✅ Method 1 — Import Into Level (recommended)

This is the most reliable way to get one actor.

In the top menu:
```
File → Import Into Level
```
Select your FBX file
Now you WILL get FBX Scene Import Options
Import
Unreal places one FBX Scene Actor directly into the level

✔ One actor
✔ No 500 actors
✔ Correct hierarchy

This is the method Epic expects for large scenes.

Why drag-and-drop doesn’t show it

When you drag into the Content Drawer, Unreal does standard Static Mesh import by default.

Unreal only shows Scene Import if:

The FBX is detected as a scene and
You explicitly tell Unreal to import it as a scene

Otherwise, it assumes:

“User wants mesh assets, not a scene.”

That’s why you’re seeing many meshes instead of one actor.

Method 2 — Drag & drop, but force Scene Import

Try this exactly:

Drag FBX into Content Drawer
In the import dialog:
- Look for Import Type
- Enable Import as Scene (checkbox or dropdown)

⚠️ In some UE5 versions this option is:

Hidden behind an Advanced dropdown
Or missing entirely depending on FBX structure

If you don’t see Import as Scene, Unreal has already decided it’s a mesh import.

Method 3 — Why your FBX may not qualify as a “scene”

Unreal only offers Scene Import if the FBX contains:

Multiple objects
A hierarchy
Transforms per object

If your FBX:

Was exported as one merged mesh
Or had “Apply Transform / Apply Modifiers” in Blender
Or used “Selected Objects Only” incorrectly

→ Unreal treats it as a single mesh asset, not a scene.

Blender export checklist (important)

When exporting FBX from Blender:

❌ Do NOT “Apply Transform”
❌ Do NOT join meshes
✅ Export multiple objects
✅ Apply scale/rotation before export (Ctrl+A)
✅ Forward: -Z Forward
✅ Up: Y Up

How to confirm you succeeded

After import, in the Content Drawer, you should see:

An asset with a hierarchy icon
Type: FBX Scene

Drag that into the level → one actor appears.

Unity comparison (to make this click)

Unity	Unreal
Drag prefab	Drag FBX Scene asset
Import Into Scene	File → Import Into Level
One GameObject, many MeshRenderers	One Actor, many StaticMeshComponents

TL;DR (do this)

👉 Use File → Import Into Level
That is the guaranteed way to get:

FBX Scene Import Options
One actor in the level
No editor freeze

If you want, tell me:

UE version (5.0 / 5.1 / 5.2 / 5.3+)
DCC (Blender/Maya)

I’ll give you exact export + import settings for your version so you never hit this again.

Great screenshot — this is the exact moment where Unreal’s UI is misleading, not you.

You are already in the right place. The reason you “can’t find the material” is simply that the Property Matrix does NOT show material columns by default.

You must enable them manually.

I’ll walk you through it step-by-step, literally click-by-click.

Why you don’t see materials right now

The Property Matrix only shows a small default set of properties (LODGroup, collision, normals, etc.).

👉 Materials / Static Materials are hidden columns until you enable them.

That’s why you’re stuck.

Step-by-step: make materials appear in the Property Matrix

1️⃣ Stay where you are

You already did this correctly:

Selected many StaticMesh assets
Opened Bulk Edit via Property Matrix

Good — do NOT close this window.

2️⃣ Open the column picker

In the top-right corner of the Property Matrix window:

Click Pinned Columns ▾
(you can see it in your screenshot)

This opens the property selector.

3️⃣ Navigate to the material property

In the column picker:

Expand:
```
StaticMesh
└── Static Materials
```
You will see:
- Material Slot 0
- (possibly Slot 1, Slot 2, etc.)

✅ Check the box for Material Slot 0

That’s the one you want.

4️⃣ Close the column picker

Once checked:

Close the Pinned Columns panel

You will now see a new column appear in the matrix called something like:

Static Materials[0]

🎉 That column IS the material.

Step-by-step: assign your material to all meshes

5️⃣ Assign the material

Click the cell under Static Materials[0]
Choose your material:
- M_TileBase or
- MI_TileBase
Press Enter

Unreal applies this to all selected StaticMeshes.

6️⃣ Save everything

Press Ctrl+S
Or click Save All

That’s it. No freezes. No 500 actor edits.

Sanity check (do this once)

Open one StaticMesh asset
Look in Details → Materials
Element 0 should now be your material

If yes → all tiles are now using it.

Important Unreal tip (Unity dev heads-up)

Always prefer editing StaticMesh assets
Avoid changing materials on placed components
Property Matrix is your equivalent of “batch inspector”

TL;DR

You didn’t do anything wrong. You just needed to:

Pinned Columns → StaticMesh → Static Materials → Material Slot 0

Unreal hides it by default 😄

If you want, next I can:

Help you create the Dynamic Material Instance pipeline
Or help you convert this whole setup to HISM (huge perf win)
Or show how to debug materials visually (color per scale)

Just tell me what you want next.

You’re right to be confused — this is one of those Unreal UI moments where the wording is actively misleading.

You are looking in the wrong tree, but not because of anything you did wrong.

Let’s reset and do this slow, exact, click-by-click, because once you see it, it’ll make sense forever.

Why you don’t see “Static Materials”

In the Property Matrix, materials are NOT under StaticMesh like you’d expect.

They live under:

StaticMesh → StaticMaterials (ARRAY)

…but arrays are hidden by default unless you explicitly expand them the right way.

What you’re currently seeing (Light Map Resolution, Body Setup, etc.) is not where materials live.

The exact steps (no guessing)

STEP 1 — Open the correct column picker

You already have the Property Matrix open 👍

At the top-right of the Property Matrix window:

Click Pinned Columns (you already did this)

Good.

STEP 2 — Use the SEARCH (this is the missing trick)

In the Pinned Columns panel, at the very top, there is a Search box.

👉 Type exactly:

Material

Do not scroll manually.
Do not expand trees by hand.

STEP 3 — Expand the correct entry

After typing Material, you should see something like:

StaticMesh
  ▸ StaticMaterials

Now do this carefully:

Expand StaticMaterials
You will see:
- StaticMaterials[0]
- (maybe [1], [2], etc.)

✅ Check the box for StaticMaterials[0]

This is the material slot.

Unreal hides array entries until you expand them explicitly — that’s why you never saw it.

STEP 4 — Close Pinned Columns

Once checked:

Close the Pinned Columns panel

STEP 5 — Assign the material

Back in the Property Matrix grid, you will now see a new column:

StaticMaterials[0]

Click any cell in that column
Choose your material (M_TileBase or MI_TileBase)
Press Enter

💥 All selected meshes now use that material.

STEP 6 — Save

Ctrl + S or Save All

Sanity check (very important)

Pick one StaticMesh asset:

Open it
Go to Details → Materials
Element 0 should now show your material

If yes → you’re done.

Why Unreal made this painful (context)

Property Matrix hides arrays by default
Materials are stored as an array (StaticMaterials)
No visual hint unless you search
This UI trips up experienced Unreal devs too

You did nothing wrong.

Unity comparison (so it clicks)

Unity	Unreal
MeshRenderer.material	StaticMaterials[0]
Multi-object Inspector	Property Matrix
Sub-mesh material	Material Slot

If this STILL doesn’t show up

Two edge cases (rare, but possible):

These meshes truly have no material slots (unlikely)
They are Nanite-only assets with collapsed slots (rare)

If that happens:

Open one StaticMesh asset
Screenshot Details → Materials
I’ll tell you immediately which case it is

Next logical steps (when ready)

Once material assignment is done, next we can:

Create Dynamic Material Instances safely
Drive color from scale
Or convert this whole setup to HISM for performance

But first: confirm you see StaticMaterials[0] after using Search.

Perfect — thanks for sticking with it. This screenshot finally shows what’s actually going on, and the answer is:

You are NOT doing anything wrong.
In your Unreal version + import path, Property Matrix does NOT expose StaticMaterials at all for these assets.

This is a real limitation / UI regression in UE5 with FBX Scene–generated StaticMesh assets.
That’s why you can search forever and never see StaticMaterials[0].

So let’s stop fighting that UI and switch to a method that 100% works, is fast, and won’t freeze Unreal.

✅ The correct solution for your situation: Replace References

This is the method Epic themselves recommend when Scene Import + Property Matrix fails.

It is:

one click
global
safe
does not touch 500 actors
does not require Property Matrix materials

What “Replace References” does (Unity analogy)

Think of it like:

“Every MeshRenderer that currently uses Material A → now use Material B”

Globally. Instantly.

Step-by-step (this WILL work)

1️⃣ Find one FBX-created material

In the Content Drawer:

Filter by Material
Find a material that came from the FBX
- Names often look like:
  - Material_0
  - Mesh_15880_Mat
  - Something auto-generated

Open one to confirm it’s the ugly default tile material.

2️⃣ Right-click that material

Choose:

Asset Actions → Replace References

3️⃣ Choose your material

In the dialog:

Select your material:
- M_TileBase or
- MI_TileBase
Confirm

4️⃣ Done

Unreal will:

Replace that material everywhere
Across all StaticMesh assets
Across all placed actors
Instantly

No freeze. No loops. No selection.

If there are multiple FBX materials

If your FBX created more than one material:

Repeat the same process for each FBX-generated material
It’s still fast (seconds, not minutes)

Why Property Matrix didn’t work (important truth)

In UE5:

StaticMaterials does exist
But Property Matrix does not expose array properties for:
- FBX Scene meshes
- Certain import paths
- Nanite-enabled meshes (sometimes)

This is not documented, and it trips up even senior Unreal devs.

You hit a real engine/tooling limitation — not a user mistake.

✅ Alternative that ALSO works (if you prefer mesh-level control)

If you want to do it mesh-by-mesh but still in bulk:

Method: Reimport with material override

Open one StaticMesh asset
In Details → Materials
Set Element 0 to your material
Save
Select all meshes → Right-click → Reimport

Unreal will propagate the material to all meshes that share the same import data.

Given everything you’re building (scaling, coloring, runtime logic):

✅ Use Replace References once
✅ Make sure all tiles use one base material or MI
✅ From Blueprint, create Dynamic Material Instances per tile
✅ Drive color from scale

This is the cleanest Unreal-native pipeline.

Sanity check

After Replace References:

Open any StaticMesh
Details → Materials → Element 0
You should see your material

If you want, next I can:

Walk you through Dynamic Material Instance creation
Or show how to debug color changes visually
Or help convert this whole thing to HISM for performance

Just tell me 👍

Ah — that detail matters a lot.

If your imported meshes are using WorldGridMaterial, that usually means the FBX didn’t import any material assignments, so Unreal is falling back to the editor’s default grid material.

That’s why you’re having such a hard time “finding the right material to replace” — there may be no FBX-created materials at all.

Good news: this is actually easier to fix.

What to do (fast + safe, no freezing)

✅ Option A: Assign your material on the StaticMesh assets (one-by-one check, then batch)

Even if Property Matrix won’t expose StaticMaterials, you can still do this without touching 500 actors.

Step 1 — Open one mesh asset

In the Content Browser, double-click any of your imported Mesh_#### StaticMesh assets.

Step 2 — Set the material on the mesh asset

In the Static Mesh Editor:

Details → Materials
Element 0 → change from WorldGridMaterial to your new material (M_TileBase or MI_TileBase)
Save

Now that one mesh is correct.

Step 3 — Apply the same material to many meshes without selecting actors

If you have many mesh assets, do it with a tool designed for this:

Use “Replace References” on WorldGridMaterial (yes, you can) This is the fastest global approach if you truly want to replace it everywhere in your project (or at least in that imported set).

✅ Option B: Replace references of WorldGridMaterial (project-wide!)

This is the nuclear option — powerful and instant.

Steps

In Content Browser, enable View Options → Show Engine Content
Search for:
- WorldGridMaterial
Right-click it → Asset Actions → Replace References
Choose your material (M_TileBase / MI_TileBase)
Confirm

⚠️ Warning:

This can replace grid material references beyond your tiles (including other test meshes)
If you only use WorldGridMaterial for these tiles, it’s fine
If not, don’t do this globally

Best “safe” version of Replace References (only for your tiles)

Instead of replacing WorldGridMaterial globally:

Create a copy material (instance) for your tiles:
- MI_TileBase
Assign it to one mesh
Then search for only meshes in your imported folder
Change materials mesh-asset level (not actor level)

Why the “Property Matrix material slot” is missing

Because right now, your StaticMesh assets may not even have imported material metadata in a way the matrix can surface, and they’re using a fallback engine material.

So the best workflow is:

Create your own material
Assign it at the StaticMesh asset level (or via reference replacement)

The real fix for future imports (so it never happens again)

In Blender/Maya:

Ensure your tiles actually have a material assigned (not just viewport color)
Ensure it’s included in export
FBX export: enable material export (usually default)
Don’t use “path mode: copy” weirdly unless you want textures embedded

If the FBX has a real material assignment, Unreal will import a material (or at least a slot name), instead of falling back to WorldGridMaterial.

Quick question (so I can give the best safe instruction)

Do you want to replace WorldGridMaterial everywhere in the project, or only for this imported folder of tiles?

If “only tiles”, I’ll give you the safest approach that won’t accidentally retint other stuff.

Totally fair reaction 😄 — Unreal hides Engine Content by default, so you literally cannot do this unless you know the exact clicks.

I’ll give you exact, literal steps. No assumptions.

HOW to “Replace References” on WorldGridMaterial

This will work 100% if you follow it in order.

STEP 1 — Make Engine Content visible (this is the missing step)

By default, WorldGridMaterial is hidden.

Open the Content Drawer
Bottom-right of the Content Drawer → click View Options
Enable:
- ✅ Show Engine Content
- (Optional but helpful) Show Plugin Content

Now Unreal will show built-in assets.

STEP 2 — Find WorldGridMaterial

In the Content Drawer search bar, type:
```
WorldGridMaterial
```
You should now see:
- WorldGridMaterial
  (Path usually: /Engine/EngineMaterials/WorldGridMaterial)

If you don’t see it yet → double-check Step 1.

STEP 3 — Right-click it (this is the key)

Right-click on WorldGridMaterial
Choose:
```
Asset Actions → Replace References
```

This opens a dialog.

STEP 4 — Choose your material

In the Replace References window:

Click Select Asset
Pick:
- M_TileBase or
- MI_TileBase (recommended)
Confirm

Unreal will warn you — say Yes.

STEP 5 — Done

Unreal will now:

Replace all references to WorldGridMaterial
On all StaticMesh assets
Including your imported tiles
Instantly (no freeze)

⚠️ IMPORTANT WARNING (read this once)

This replaces every use of WorldGridMaterial in your project.

This is usually safe if:

You only used it as a default placeholder
You’re early in the project

If you’re unsure, there’s a safer version below.

SAFE VERSION (only affects your tiles, not the whole project)

Option A — Duplicate first (recommended)

Right-click WorldGridMaterial
Duplicate
Name it:
```
M_TileGrid
```
Edit M_TileGrid however you want
Replace references only on that duplicated material later if needed

Option B — Assign per mesh (slower but surgical)

Open one StaticMesh asset
Set Element 0 → your material
Save
Reimport other meshes (they inherit)

WHY THIS WORKS

Your meshes are currently using WorldGridMaterial as a fallback because:

FBX had no real materials
Unreal assigned the engine default

So replacing that reference is equivalent to:

“Every tile that had no material → now use mine”

QUICK SANITY CHECK

After doing this:

Open any tile StaticMesh
Details → Materials
Element 0 should be your material

If yes → you’re officially past the hardest Unreal hurdle 🎉

✅ Confirm material assignment works
Create Dynamic Material Instances per tile
Drive color from scale
(Optional) Convert tiles to HISM for performance

Reply with:

“Found WorldGridMaterial and replaced it”
or
“I don’t see WorldGridMaterial even after Step 1”

and I’ll take you to the next step immediately.

Perfect — this screenshot shows exactly what’s confusing you, and the fix is simple once you know the rule Unreal is using.

You’re inside the Replace References dialog correctly, but:

❗ You didn’t pre-select the material you want to replace TO.

Unreal’s Replace References tool works backwards from what most people expect.

The key rule (this is the missing mental model)

Replace References does NOT let you pick the replacement inside the dialog.

Instead:

Whatever asset you had selected BEFORE opening “Replace References” is the replacement.

The dialog only shows the assets that will be replaced.

Right now, you only selected WorldGridMaterial, so Unreal has nowhere to replace to.

Do this exactly (no guessing)

STEP 1 — Select YOUR material first

In the Content Drawer:

Find your material:
- M_TileBase or
- MI_TileBase
Left-click it ONCE (this is important)

Do NOT right-click yet.

STEP 2 — Add WorldGridMaterial to the selection

Now:

Hold Ctrl
Click WorldGridMaterial

You should now have:

✅ Your material selected
✅ WorldGridMaterial selected

The last selected asset is the one that gets replaced.

STEP 3 — Right-click and Replace References

With both selected:

Right-click
Choose:
```
Asset Actions → Replace References
```

STEP 4 — What you should see now

The dialog will now show:

WorldGridMaterial (as the asset to be replaced)
Your material is the consolidation target

The Consolidate Assets button will now be enabled.

✔ Check Save dirtied assets
✔ Click Consolidate Assets

STEP 5 — Done

Unreal will:

Replace all uses of WorldGridMaterial
With your material
On all meshes that used it

No freezes. No selecting actors. No bulk editing pain.

Why Unreal does it this way (so it sticks)

Replace References is actually a “Consolidate Assets” tool.

It assumes:

“Keep the selected asset”
“Delete/replace the others”

So selection order matters.

Unity comparison:

This is closer to merge assets than “replace material” UI.

Quick sanity check

After this:

Open any StaticMesh
Details → Materials
Element 0 should be your material, not WorldGridMaterial

If yes → you’re DONE with material assignment 🎉

TL;DR (one sentence)

Select your material first → Ctrl-select WorldGridMaterial → Right-click → Replace References → Consolidate.

If you want, next we can:

Create Dynamic Material Instances
Drive color from scale
Or finally make this performant with HISM

Just say the word.

You’re right to be pissed. I did send you through too many branches.
Let’s stop. Breathe. One solution. It works. No theory. No UI archaeology.

THE SIMPLEST WAY — WORKS 100% — 30 SECONDS

You do NOT need Scene Import tricks, Property Matrix, or replacing engine assets.

Do THIS. Exactly this.

STEP 1 — Open ONE mesh asset

In Content Drawer
Double-click any Mesh_##### StaticMesh asset

You are now in the Static Mesh Editor.

STEP 2 — Assign your material

On the right Details panel:

Find Materials
Element 0
Change WorldGridMaterial → YOUR MATERIAL (M_TileBase or MI_TileBase)
Save

At this moment:

ONE mesh is fixed
Others are not

Good.

STEP 3 — Apply it to ALL meshes (this is the key)

Go back to Content Drawer:

Select ALL your tile meshes
(Shift-click first → last)
Right-click
Choose:
```
Asset Actions → Reimport
```

👉 Unreal will reuse the existing material assignment
👉 All meshes now use your material
👉 No freezes
👉 No 500 actors
👉 No engine material hacks

WHY THIS WORKS (short, final explanation)

Your FBX has no real materials
Unreal assigned WorldGridMaterial as fallback
When you manually set Element 0 on ONE mesh:
- That becomes the new import default
Reimport propagates it to all meshes

This is how Unreal expects you to fix this case.

DO NOT DO THESE (you don’t need them)

❌ Replace References on WorldGridMaterial
❌ Property Matrix
❌ Scene Import material mapping
❌ Selecting actors in the level

Those are all optional paths that complicated things.

TL;DR (burn this into memory)

Open one StaticMesh → set material → save → reimport all meshes

That’s it. Done. Finished. Over.

If you want, next (ONLY if you ask), I’ll help you:

Color tiles by scale
Create Dynamic Material Instances
Or convert this to HISM for performance

But for now — go do the 3 steps above and you’ll finally see your material on every tile.

Alright. Stop. Reset.
You’re angry because you were told there was a “simple global switch” when, in your exact import case, there isn’t. That’s on me. I should have said this earlier and plainly.

I’m going to be very direct and honest now, no Unreal mythology.

The hard truth (this is the root of everything)

You imported an FBX Scene that produced:

500 separate StaticMesh assets
1 FBX Scene Actor that contains 500 StaticMeshComponents
Each StaticMesh asset has no authored material, so Unreal assigns WorldGridMaterial

In this situation:

❗ There is NO way in Unreal to change the material “once” at the asset level
❗ There is NO hidden bulk switch you missed
❗ Any solution that touches StaticMesh assets will act per-mesh

That’s not user error.
That’s how Unreal’s asset system works.

The ONLY way to do this cleanly, instantly, without reimporting 500 meshes

👉 Override the material at the FBX Scene Actor level

This affects all tiles at once, in the level, without touching assets, without reimport, without freezes.

This is what you actually want.

THE CORRECT SOLUTION (FOR YOUR CASE)

Step-by-step — works immediately

1️⃣ In the World Outliner

Select the FBX Scene Actor
(the one that represents the whole import, not an individual mesh)

2️⃣ In the Details panel

Scroll until you find Materials (this is important):

You will see something like:

Materials
▸ Override Materials

Expand it.

3️⃣ Add a material override

Click + to add Element 0
Assign your material (M_TileBase or MI_TileBase)

4️⃣ Done

Every StaticMeshComponent under that FBX Scene Actor now uses your material.

✅ One operation
✅ No asset edits
✅ No reimport
✅ No 500 actors
✅ No engine-material hacks
✅ No freezes

Why this works (and why everything else hurt)

FBX Scene Actor supports material overrides
Overrides apply to all child components
Unreal resolves the override after asset materials
You bypass the entire StaticMesh-asset problem

Unity analogy:

This is like assigning a material override on a parent GameObject with many MeshRenderers.

Why the other paths failed (brief, honest)

Property Matrix → doesn’t expose StaticMaterials for FBX Scene meshes (UE5 limitation)
Replace References → wrong tool for Engine fallback materials in this context
Reimport → inherently per-asset (you saw that pain firsthand)
Import-time assignment → only works if FBX has authored materials

None of those were wrong, but they were the wrong tool for your setup.

If you want to make this bulletproof for the future

Later (not now), the real optimal setups are:

Convert this to HISM
Or re-export FBX with one real material
Or convert Scene Actor → Blueprint and manage materials there

But right now, the override is the correct answer.

Final clarity (no more circles)

You cannot bulk-change materials on 500 StaticMesh assets without touching each asset.
You CAN override materials once on the FBX Scene Actor.
That is the intended workflow for scenes.

If you want, next I can:

Help you drive color by scale using that override material
Or help you convert this Scene Actor into a Blueprint cleanly
Or help you replace this with HISM so none of this ever hurts again

But for now — you’ve hit the actual correct solution.

Yes. 100% yes. And for your situation (FBX scene with tons of components), Blueprint is the sane way to do it.

You have two good Blueprint options:

Option A (recommended): Change materials on all mesh components at runtime

This doesn’t touch the imported assets, doesn’t reimport, and you do it in one place.

Blueprint steps (Actor Blueprint that owns the tiles)

Do this in the Actor that contains the imported meshes (the FBX Scene Actor or a wrapper Blueprint):

1) Make a variable for the material

Create variable: TileMaterial
Type: Material Interface
Check Instance Editable (so you can pick it in the level)
Set it to your material in the Details panel

2) On BeginPlay, apply it to all StaticMeshComponents

Nodes:

Event BeginPlay
Get Components by Class
- Class: StaticMeshComponent
ForEachLoop
For each component:
- Set Material
  - Target: Array Element (StaticMeshComponent)
  - Element Index: 0
  - Material: TileMaterial

That’s it.

✅ One actor, one Blueprint, applies to all tiles
✅ Doesn’t care how the FBX imported
✅ Doesn’t freeze the editor like manual selection
✅ Works even if they used WorldGridMaterial

Important: add an IsValid guard

Before Set Material, use Is Valid (exec) on the Array Element to avoid TRASH issues.

Option B: Set material in the editor too (not just runtime)

If you want it to update when you tweak stuff in editor (Unity OnValidate-ish):

Use a Construction Script — but only if you convert/wrap the FBX scene in an Actor Blueprint.

Construction Script → GetComponentsByClass → ForEach → SetMaterial

⚠️ This can lag the editor if you do it constantly, so runtime BeginPlay is safer.

Where to put this if your tiles are an FBX Scene Actor

FBX Scene Actor is a special actor, but you can still handle it:

Easiest: make a wrapper Blueprint

Create a Blueprint Actor: BP_TileScene
Place your FBX Scene Actor under it (attach or make it a child in the level)
In BP_TileScene, on BeginPlay:
- Get all child actors
- For each child actor:
  - GetComponentsByClass(StaticMeshComponent)
  - SetMaterial

(If you want, I’ll give you the exact nodes for this version.)

Quick question so I give you the exact node chain

Are your tiles:

All StaticMeshComponents on ONE actor (FBX Scene Actor shows as one actor in Outliner), OR
Hundreds of separate actors in the Outliner?

Tell me which one (1 or 2) and I’ll give you the exact Blueprint graph layout with the right nodes.

Yep — this is a clean Unreal pattern:

Your material must expose a color parameter
For each tile mesh, create a Dynamic Material Instance (MID) once
Every update, compute alpha from scale, Lerp two colors, push into the MID

I’ll write it in “Blueprint node” language.

0) Material setup (one-time)

Open your tile material (M_TileBase):

Add a Vector Parameter named TintColor
Multiply your base color by it (or plug directly into Base Color)
- BaseColorTexture * TintColor → Base Color
Save

This gives Blueprint something to drive.

1) In Blueprint: store MIDs for each tile (do this once)

In the Blueprint that controls tiles (your component / actor):

Variables

ColdColor (Linear Color) — e.g. blue
HotColor (Linear Color) — e.g. red
MinScale (float)
MaxScale (float)
TileMIDs (Array of Material Instance Dynamic)

On BeginPlay (or right after you build TileMeshes)

Goal: one MID per mesh, cached

Nodes:

Get Components by Class (StaticMeshComponent)
ForEachLoop
For each Array Element (StaticMeshComponent):
- Is Valid (exec)
- Create Dynamic Material Instance
  - Target = Array Element
  - Element Index = 0
- Add the return value into TileMIDs

✅ Now each tile has its own material instance, so setting color affects only that tile.

Important: Don’t use “Set Material” for tinting per-tile unless you follow with “Create Dynamic Material Instance”. Otherwise they’ll all share the same material and tint together.

2) Each update: Lerp two colors based on current tile scale

Wherever you currently compute/apply scale (Tick/Timer loop):

You need:

the tile mesh component (from your TileMeshes loop or GetComponentsByClass)
the same Index to fetch the right MID from TileMIDs

Compute alpha from scale

Use either:

Option A (easy): NormalizeToRange

AlphaRaw = NormalizeToRange(Scale, MinScale, MaxScale)
Alpha = Clamp(AlphaRaw, 0, 1)

Option B (same thing):

(Scale - MinScale) / (MaxScale - MinScale) → Clamp 0..1

Lerp colors

Node: Lerp (LinearColor)
- A = ColdColor
- B = HotColor
- Alpha = your Alpha

Set parameter on MID

MID = TileMIDs[Index] (Array Get)
Is Valid (exec) on MID
Node: Set Vector Parameter Value
- Target = MID
- Parameter Name = "TintColor" (exact spelling)
- Value = lerped color

That’s it.

Practical wiring inside your tile loop

Inside ForEachLoop(TileMeshes):

Array Index → use it to Get from TileMIDs
Array Element → scale target
After you compute FinalScale:
- apply scale
- compute alpha
- lerp
- set TintColor on TileMIDs[Index]

Two gotchas to avoid

1) “All tiles change color together”

That means you’re not using per-tile MIDs. Fix: Create Dynamic Material Instance per tile and store it.

2) “Nothing changes color”

Usually one of:

Parameter name typo (TintColor must match)
You’re setting the MID but the material isn’t using the parameter in Base Color
Wrong material slot index (try Element 0 first)

If you paste a close-up of the part of your Blueprint where you compute FinalScale and call SetRelativeScale3D, I’ll tell you exactly where to plug in the NormalizeToRange → Lerp → SetVectorParameterValue chain (and whether you should index TileMIDs by loop index or store a map).

Yes. Exactly.
And this is an important Unreal concept, so let’s lock it in cleanly.

Short, clear answer

TileMIDs are created procedurally at runtime inside the Blueprint.
They do not exist as assets in the Content Browser.

Think of them like Unity’s renderer.material:

Created on the fly
Exist only while the game runs
Unique per mesh
Garbage-collected when the actor/component is destroyed

What a MID actually is (Unity mapping)

Unity	Unreal
`Material` asset	`Material` / `Material Instance`
`renderer.material`	Dynamic Material Instance (MID)
`MaterialPropertyBlock`	MID (closest equivalent)

In Unreal:

You cannot safely change parameters on a shared material
You must create a MID if you want per-object variation

How TileMIDs are created (exactly)

In Blueprint:

Node: Create Dynamic Material Instance
Inputs:
- Target = StaticMeshComponent
- Element Index = 0
Output:
- A Material Instance Dynamic

You then:

Store that output in an array (TileMIDs)
Use it later to set parameters like TintColor

When they should be created (important)

Create them ONCE, not every frame.

Good places:

BeginPlay
Right after you build or rebuild TileMeshes

Bad place:

Tick (this will destroy performance and memory)

Lifecycle clarity

Base Material / Material Instance → lives as an asset
MID → lives in memory only
When actor/component is destroyed → MID is released

You do not save MIDs.

Typical Blueprint flow (plain English)

Game starts
Blueprint finds all tile mesh components
For each mesh:
- Create MID
- Store MID in array
Every update:
- Compute scale
- Lerp color
- Set parameter on MID

Common mistake to avoid (very common)

❌ Doing this every update:

Create Dynamic Material Instance
Set Vector Parameter

That leaks and kills performance.

You want:

BeginPlay → Create MID once
Tick/Timer → Set parameter on existing MID

Sanity check

If this is set up correctly:

Changing one tile’s color does not affect others
No materials appear in Content Browser
Performance stays stable

If you want, next I can:

Show how to associate TileMeshes ↔ TileMIDs safely (array vs map)
Or how to debug MID issues visually
Or how to do this with HISM + Per-Instance Custom Data (even faster)

Just tell me.

Perfect, this is a very concrete Blueprint wiring question, so I’ll answer it literally node-by-node, no abstraction.

You are inside a ForEachLoop over your tile meshes. That loop already gives you everything you need.

What you already have (important)

A ForEachLoop node has two outputs:

Array Element → the current StaticMeshComponent
Array Index → the integer index of that element in the array

That Array Index is the key.

Your rule must be:

TileMeshes[index] ↔ TileMIDs[index]

Same index = same tile.

EXACT steps in Blueprint (no guessing)

1️⃣ Inside your ForEachLoop

You should see this node:

ForEachLoop (TileMeshes)
 ├── Array Element
 └── Array Index

Do NOT ignore the Array Index pin.

2️⃣ Drag from Array Index

Click and drag from Array Index
Release mouse in empty space
Type: Get
Choose Get (a copy) (array get)

This creates an Array Get node.

3️⃣ Tell the Get node which array to use

On the Array Get node:

Connect:
- Array → your TileMIDs variable
- Index → the Array Index pin from the loop

Now you have:

TileMIDs[ArrayIndex]

That node outputs one Material Instance Dynamic.

4️⃣ Store that MID in a local wire

The output of the Get node is your MID for this exact tile.

From that output:

Add Is Valid (exec) (recommended)
Then call Set Vector Parameter Value

Wire it like this:

Array Index
   ↓
Get TileMIDs
   ↓
Is Valid (exec)
   ↓
Set Vector Parameter Value

Parameter Name:

TintColor

Value:

the color you got from your Lerp (LinearColor) node

Complete picture (in plain English)

For each tile:

Loop gives you:
- the mesh
- its index
You use the index to grab:
- the matching MID
You set the color on that MID
That tile changes color — only that tile

VERY IMPORTANT RULE (this must be true)

When you created TileMIDs, you must have done it in the same order as TileMeshes.

Example (BeginPlay):

GetComponentsByClass (StaticMeshComponent)
→ ForEachLoop
   → Create Dynamic Material Instance
   → Add to TileMIDs

If you did that, indices match perfectly forever.

Common mistake (watch for this)

❌ Creating TileMIDs in a different loop than TileMeshes
❌ Rebuilding TileMeshes but not rebuilding TileMIDs
❌ Using Get(0) instead of Get(Array Index)

If any of those happen, colors won’t line up.

Mental model (Unity-friendly)

This is exactly like:

for (int i = 0; i < tiles.Count; i++)
{
    var renderer = tiles[i];
    var material = tileMIDs[i];
    material.SetColor("_TintColor", color);
}

Blueprint is just more wires.

If you want, next I can:

Show how to rebuild TileMIDs safely when tiles change
Or switch to a Map<StaticMeshComponent, MID> (even safer, no index dependence)
Or show how to debug which tile is which MID

Just say which one.

Yes — and timing matters a lot.

Rule

Create MIDs once, after you have the tile mesh components, and before you start updating colors.

So you do it in the same place you populate TileMeshes (or immediately after), not inside Tick.

The best place in your setup (FBX tiles + arrays that can go stale)

You already have (or should have) a “refresh/rebuild tiles” step. That’s the perfect hook.

✅ Create MIDs in two moments:

BeginPlay → build TileMeshes → create TileMIDs
Whenever you rebuild TileMeshes (because TRASH happened) → rebuild TileMIDs too

If tiles can change, TileMIDs must stay aligned with TileMeshes.

Concrete Blueprint structure (what to implement)

1) Make a function/event: `RebuildTilesAndMIDs`

Do all setup here so it’s always consistent.

Inside RebuildTilesAndMIDs:

Clear TileMeshes
Clear TileMIDs
Get Owner (or target actor)
Get Components by Class (StaticMeshComponent) → returns array
ForEachLoop over that returned array:
- Is Valid (exec) on component
- Add component to TileMeshes
- Create Dynamic Material Instance
  - Target = that component
  - Element Index = 0
- Add returned MID to TileMIDs

Now indices match: TileMeshes[i] ↔ TileMIDs[i].

2) Call it at BeginPlay

In your main graph:

Event BeginPlay
- Call RebuildTilesAndMIDs
- Then start your update loop (Tick or Timer)

3) Call it again when you detect invalid tiles

You already have NeedRefresh from your validity checks.

After your tile loop completes:

ForEachLoop.Completed → Branch(NeedRefresh)
- True → RebuildTilesAndMIDs → Set NeedRefresh = false

This keeps your arrays from going stale when FBX components get recreated.

Don’t do this (it will break / hitch)

❌ Creating MIDs inside Tick
❌ Creating MIDs inside the same loop where you’re also updating color every frame
❌ Rebuilding TileMeshes without rebuilding TileMIDs

Unity mapping (so it clicks)

This is like doing:

Start():
- cache renderers
- create per-renderer materials
Update():
- just set colors/scales

You never allocate materials in Update.

Practical note: where does this live?

If your scaling logic is in an Actor Component (like your TileScaler component), that’s fine:

Put RebuildTilesAndMIDs inside the component
Use GetOwner() as the actor that contains the FBX mesh components

If you tell me one thing, I can give you the exact node list for your blueprint: Are your tiles’ StaticMeshComponents on the same actor that owns the TileScaler component, or are they on a different actor (like a child FBX Scene Actor)?

Good question — this is one of those Blueprint things that’s not obvious at all.

Short answer

👉 Use Add, not Set and not Get.

You already have the correct node in your screenshot.

What each node actually does (so you don’t guess)

❌ `Get`

Reads an existing element
Does not modify the array
Used later when you want TileMIDs[Index]

❌ `Set Array Elem`

Overwrites an element at a specific index
Requires that index to already exist
Easy to break things if the array is empty

✅ `Add`

Appends a new element to the end of the array
Automatically grows the array
This is exactly what you want when building the array

Correct pattern (what your graph should do)

Inside your ForEachLoop:

Array Element → Create Dynamic Material Instance (Target)
Return Value → Add
Add → Array = TileMIDs

That’s it.

This produces:

TileMIDs[0] = MID for TileMeshes[0]
TileMIDs[1] = MID for TileMeshes[1]
TileMIDs[2] = MID for TileMeshes[2]
...

Indices match automatically because you’re iterating in the same order.

One important thing you must do (very important)

Before this loop runs, clear the array.

Add this before the ForEachLoop:

Clear (TileMIDs)

Otherwise you’ll keep appending and your indices will drift.

Correct full setup flow (plain English)

BeginPlay
- Clear TileMeshes
- Clear TileMIDs
- GetComponentsByClass (StaticMeshComponent)
- ForEachLoop:
  - Add component to TileMeshes
  - Create MID
  - Add MID to TileMIDs

Later (Tick/Timer):

ForEachLoop(TileMeshes):
- Use Array Index → Get TileMIDs[Index]
- Set color parameter

Unity analogy (to lock it in)

tileMIDs.Clear();

foreach (var mesh in tileMeshes)
{
    var mat = Instantiate(mesh.sharedMaterial);
    tileMIDs.Add(mat);
}

Blueprint’s Add is literally List.Add().

Final sanity check

If this is correct:

TileMIDs.Length == TileMeshes.Length
Changing one tile’s color does not affect others

If you want, next I can:

Double-check your rebuild flow
Show how to guard against nulls
Or help you switch to a Map instead of parallel arrays

Just say the word.

Good — this is a real Blueprint mechanics question, not a logic one.
I’ll answer it very literally, because this is one of the most confusing UI moments in Blueprints.

What the `Add` node actually is

The Add node is not generic. It is bound to a specific array type.

So the rule is:

You must create the Add node from the array variable itself, not by searching blindly.

If you don’t, it won’t know what the “Target Array” is.

The correct way to add to `TileMIDs` (step-by-step)

STEP 1 — Drag the array variable into the graph

In My Blueprint panel (left side)
Find your variable: TileMIDs
Drag it into the graph
When prompted, choose Get

You now have a TileMIDs node in the graph.

STEP 2 — Drag off the TileMIDs pin

Click and drag from the blue array pin on TileMIDs
Release mouse
Type Add
Choose Add (TileMIDs)

⚠️ This is important:
You should see Add (Material Instance Dynamic) or similar — not a generic Add.

Now the Add node will already have:

Target Array = TileMIDs

STEP 3 — Connect the MID

Connect Return Value from Create Dynamic Material Instance
Into the Item pin of the Add node

That’s it.

What NOT to do (this causes confusion)

❌ Right-click → search “Add”
→ This creates a generic node with no target array

❌ Use Set Array Elem
→ That requires an index and assumes the element already exists

What your final mini-graph should look like

ForEachLoop
 ├─ Array Element → Create Dynamic Material Instance
 │                  └─ Return Value → Add (TileMIDs)

And before the loop:

Clear (TileMIDs)

Why Unreal does this (mental model)

Blueprint array functions are methods on the array, not global functions.

So instead of:

Add(TileMIDs, value);

It’s more like:

TileMIDs.Add(value);

That’s why you must drag from the array.

Quick sanity check

If done correctly:

The Add node has no “Target Array” pin exposed
It already knows it’s modifying TileMIDs
TileMIDs.Length increases by 1 each loop

If you want, next I can:

Verify your entire MID creation block is correct
Or show a Map-based approach that avoids index sync issues
Or help you debug why some tiles might not get MIDs

Just tell me.

You’ve already done the hard part (computing a clean 0–1 alpha from scale and lerping ColorA→ColorB). What’s missing is just: take that lerped color and push it into the correct MID for the current tile.

Because you’re using arrays, the key is:

Use the same Array Index from your TileMeshes ForEachLoop to fetch TileMIDs[Index].

Here’s exactly how to wire it.

1) Make sure your material has a parameter

Your base material must have a Vector Parameter named (for example) TintColor and actually used in Base Color.

(If you named it something else, use that name exactly.)

2) Inside your TileMeshes loop, get the matching MID

Wherever you are doing SetRelativeScale3D (that orange node), you should be inside the loop that iterates tiles.

Add these nodes right after you compute the lerped color:

Get (a copy) from TileMIDs
- Drag TileMIDs into graph as Get
- Drag from it → choose Get
- Plug Index = Array Index (from the tile loop)
(Optional but recommended) Is Valid (exec) on that MID

Now you have the correct MID for this tile.

3) Set the color parameter on that MID

Add node:

Set Vector Parameter Value

Target: the MID you got from TileMIDs[Index]
Parameter Name: "TintColor" (or your parameter name)
Value: the Return Value from your Lerp (LinearColor)

Wiring summary:

Lerp(LinearColor).ReturnValue → SetVectorParameterValue.Value
TileMIDs[Index] → SetVectorParameterValue.Target

4) Where exactly to connect it in your current graph

From your screenshot, you already have:

NormalizeToRange → Clamp(0..1) → Lerp(LinearColor)

So you do:

Take Lerp(LinearColor) Return Value
Feed it into Set Vector Parameter Value

Place this right after you set the scale, or right before — either is fine.

Minimal “per-tile” execution chain (the one you want)

Inside the tile loop:

Compute FinalScale
SetRelativeScale3D (target = tile mesh)
Alpha = Clamp(NormalizeToRange(FinalScale, MinScale, MaxScale), 0, 1)
Tint = Lerp(ColorA, ColorB, Alpha)
MID = TileMIDs[ArrayIndex]
MID.SetVectorParameterValue("TintColor", Tint)

Common gotcha

Your `ColorA` / `ColorB` variables should be Linear Color, not “Color”

In the left panel I see ColorA and ColorB are type Color (sRGB color).
Your Lerp (LinearColor) wants Linear Color.

Fix:

Change variable type to LinearColor
- Or convert using node “Conv_ColorToLinearColor” (if you keep them as Color)

If you don’t, you can get weird gamma-looking results.

Another gotcha: make sure TileMIDs aligns with TileMeshes

If TileMeshes ever gets rebuilt, TileMIDs must be rebuilt in the same loop/order, or TileMIDs[Index] won’t match the tile.

If you want, send a zoomed-out screenshot that includes the ForEachLoop that’s driving SetRelativeScale3D.

I’ll tell you exactly where to pull the Array Index from and exactly where to drop the Get TileMIDs[Index] → SetVectorParameterValue chain.

ok now i have a different ask. Might be a bit complex. Instead of using distance from influencers to affect the scale of my tiles I want to use a black and white texture. A bit of context, my tiles are actually meant to be a ground projection and there will be cameras tracking people which will be inputed as BW heatmaps (sdf like). I’d like the tile scale to be affected from these. But let’s start by just having a static BW texture and affect scale from there rather than adding the whole dynamic movement. Although, if there is a specific type of texture that I’ll need to use to be able later on to support continuous feedback (for example in Unity I’d use a render texture and not a texture 2D), please advise me so . here is my current blueprint with the distance from influencers (image)

Yes — this is very doable, and you’re thinking about it the right way (Unity “RenderTexture” mental model maps to Unreal “Render Target”).

There are two sane ways to drive tile scale from a BW heatmap in Unreal:

CPU sampling (Blueprint reads the texture and sets each tile’s scale)
GPU-driven (material displaces/animates visuals from the texture; tiles stay static as geometry)

Because you want to actually scale 180 separate tile components, you’re in CPU sampling land (at least for now). For 180 tiles this is fine.

Below is the clean “static BW texture → scale” approach, and I’ll also tell you what texture type you should use later for live camera feedback.

What texture type you should use

For static testing

Use a normal Texture2D (grayscale).

For future live updates (Unity RenderTexture equivalent)

Use a Texture Render Target 2D (TextureRenderTarget2D).
Later you can write into it via:
- SceneCapture2D
- Drawing materials to the render target
- C++/plugin
- Media texture pipeline, etc.

✅ So: design your pipeline around a Render Target 2D, but for now you can plug in a Texture2D.

Core idea: each tile samples the heatmap at its world position

For each tile:

Convert tile world position → UV (0–1) in heatmap space
Sample heatmap value (0–1) at that UV
Use that value to drive scale (lerp between MinScale/MaxScale)

That replaces your “distance to influencer” logic.

Step 1 — Add variables to your component

Create these variables:

HeatmapTexture : Texture (or Texture2D / TextureRenderTarget2D)
ProjectionOrigin : Vector (world-space bottom-left of the projection)
ProjectionSize : Vector2D (world width/height covered by the texture)
bFlipV : bool (optional; textures often come in upside down)

(These replace influencer position/distance)

Step 2 — Map world position to UV

Inside your tile loop (where you currently compute distance):

Get tile position

TileComp → GetWorldLocation → Pos

Convert to local offset

Offset = Pos - ProjectionOrigin

Convert to UV

U = Offset.X / ProjectionSize.X
V = Offset.Y / ProjectionSize.Y
Clamp each 0..1

Depending on your ground plane orientation you might use X/Y or X/Z.
Most ground planes in UE are X/Y, but if your tiles lie on X/Z, swap accordingly.

Add Clamp (float) for U and V.

Optional:

if bFlipV then V = 1 - V

Step 3 — Sample the texture (Blueprint-friendly options)

Here’s the key: Blueprints can’t “just sample a Texture2D” cheaply like a shader. You have a few approaches:

Option A (best for now): use a Render Target and `Read Render Target Pixel`

If you use TextureRenderTarget2D (even for a static image you can copy into it once), you can sample in BP.

Nodes (Blueprint):

Read Render Target Pixel (or “Read Render Target Raw UV” depending on version)
- Target = your RenderTarget
- X,Y pixel coordinates

To do that you convert UV → pixel coords:

X = floor(U * (Width-1))
Y = floor(V * (Height-1))

Then the node returns a LinearColor. Use .R as the grayscale value.

✅ This is the closest match to Unity RenderTexture workflows.

Option B (Texture2D): you basically need to read pixels once and cache

Blueprint can’t efficiently read Texture2D pixels every frame without plugins/C++. So for static Texture2D, the sane approach is:

At BeginPlay: read it once (C++ or editor utility), store array
At runtime: index into the array

If you want to stay Blueprint-only, use a Render Target.

Recommendation: start with a RenderTarget now, even for a static BW image.

Step 4 — Convert sampled value to scale

Let:

Heat = SampledValue (0..1)

Then:

Scale = Lerp(MinScale, MaxScale, Heat) (or invert if white should mean small)

Then apply SetRelativeScale3D.

This replaces all your distance math.

Practical minimal blueprint flow (inside your tile loop)

For each tile component:

Pos = GetWorldLocation(Tile)
UV = (Pos - ProjectionOrigin) / ProjectionSize (component-wise)
Clamp UV 0..1
PixelXY = UV * (RTSize - 1)
Color = ReadRenderTargetPixel(RenderTarget, PixelXY)
Heat = Color.R
FinalScale = Lerp(MinScale, MaxScale, Heat)
SetRelativeScale3D(Tile, (FinalScale, FinalScale, FinalScale))

One super important performance note (so UE doesn’t hitch again)

Don’t sample the texture every Tick if you can avoid it.

For 180 tiles it may be okay at low frequency, but reading render target pixels can still be expensive.

Use your existing UpdateInterval and run this on a timer (e.g. 0.05–0.2s).

Later, if you need 60Hz and it becomes heavy, you move to:

C++ bulk read (ReadPixels once per frame)
Or GPU approach (material displacement instead of component scaling)

How to start “static BW texture” using a Render Target (recommended)

Create a TextureRenderTarget2D asset (e.g. 512×512, R8 or RGBA8).
Create a simple material that outputs your BW texture into Emissive.
At BeginPlay: Draw Material to Render Target once to copy the BW texture into the RT.
Then sample the RT in your tile scaler.

This gives you the same pipeline you’ll later use for live heatmaps.

Quick question that determines your UV mapping (so you don’t fight axes)

Are your tiles laid out on X/Y (typical plane) or X/Z (common “ground” in some workflows)?
If you don’t know: tell me what axis is “up” for your scene (usually Z-up in Unreal).

Even without your answer, you can try:

Use X and Y first
If the mapping looks rotated, swap to X/Z

If you want, I can sketch the exact nodes to replace your “Distance(Vector)” section with “World→UV→ReadRenderTargetPixel”.

Yep — the problem is your min/max update logic is wired backwards, so your bounds never “expand” correctly.

What’s wrong in your graph

Inside the loop you do:

Min X goes into a MIN node with BreakVector.X
then you SET Min X to that result ✅ (this part is fine)

…but for the max side you do:

Max X goes into a MAX node with… Max X again (or you’re not actually feeding BreakVector.X into the MAX node correctly)
then you SET Max X ✅

In your screenshot, the MAX nodes look like they’re effectively doing:

MaxX = max(MaxX, MaxX)
MaxY = max(MaxY, MaxY)

…which will obviously never change.

Even if you intended to plug the tile position in, the MAX nodes’ inputs are not being fed correctly (or they’re fed from the wrong variables).

The correct bounds update (per tile)

For each tile position P:

MinX = min(MinX, P.X)
MinY = min(MinY, P.Y)
MaxX = max(MaxX, P.X)
MaxY = max(MaxY, P.Y)

So each MIN/MAX node must take:

Input A: the current min/max variable
Input B: the current tile coordinate (BreakVector.X or .Y)

What to change in your Blueprint (exact wiring)

1) Make sure initial values are correct

Before the loop starts:

MinX = +1000000000 (big positive)
MinY = +1000000000
MaxX = -1000000000 (big negative)
MaxY = -1000000000

In your screenshot you set MaxX/MaxY to +1,000,000 which is wrong as a “starting max” if you want it to grow.

✅ Max should start very negative
✅ Min should start very positive

That’s probably also breaking your result.

2) Wire the MAX nodes correctly

On the MAX node for X:

One pin = MaxX (Get)
Other pin = BreakVector.X

Then the output goes into Set MaxX

Same for Y.

Right now your MAX node is not comparing against the tile coordinate.

Bonus gotcha: make sure you’re using the right plane axes

If your tiles are on the ground and you want 2D bounds, you probably want:

X and Y (if tiles lie on XY plane), OR
X and Z (if tiles lie on XZ plane)

In Unreal, “ground” is often X/Y with Z up, but many imported meshes end up using X/Z depending on export.

If your bounds look “flat” or wrong, swap Y ↔ Z in the BreakVector inputs.

Quick minimal version (cleaner)

Instead of 4 separate floats, you can compute bounds with a box:

Use GetActorBounds / GetComponentBounds on each tile and accumulate, OR
Keep min/max floats as you are (fine for 180 tiles)

Checklist

Max starts negative, Min starts positive
MAX nodes compare (currentMax, currentCoord)
MIN nodes compare (currentMin, currentCoord)
You’re using the correct axes (XY vs XZ)

If you paste (or zoom) the inputs on one of your MAX nodes, I can point to the exact pin that should be connected to BreakVector.X/Y in your graph.

You’re very close, but it’s not correct yet for one specific Blueprint reason:

The MIN/MAX nodes are updating your floats, but your Set MinX/Set MaxX nodes are not guaranteed to run every iteration.

Right now, your Set MinX / Set MinY / Set MaxX / Set MaxY nodes have execution pins, but I don’t see an execution wire from the loop body flowing through them. In Blueprints:

Math nodes execute “when read,” but Set nodes only happen when their white exec pin is fired.

So unless you explicitly chain exec into those Set nodes inside the loop, the values might never actually update.

What “correct” must look like (exec flow)

Inside the ForEachLoop:

Loop Body → Set MinX → Set MinY → Set MaxX → Set MaxY

And each Set should take the output of the corresponding MIN/MAX node.

Exact order doesn’t matter, but the exec chaining does.

Also: your initial values now look correct ✅

MinX / MinY start very positive
MaxX / MaxY start very negative

That part is good now.

Fix it (exact wiring)

From ForEachLoop Loop Body exec pin:
- connect to Set MinX exec input
Connect Set MinX exec output → Set MinY
Set MinY → Set MaxX
Set MaxX → Set MaxY

For the value inputs:

Set MinX value = MIN(MinX, Pos.X)
Set MinY value = MIN(MinY, Pos.Y) (or Pos.Z depending plane)
Set MaxX value = MAX(MaxX, Pos.X)
Set MaxY value = MAX(MaxY, Pos.Y)

One more quick check

Make sure the GetWorldLocation target is the Array Element of your TileMeshes loop (it looks like it is).

How to confirm instantly

After the loop Completed pin, add a Print String for:

MinX, MaxX, MinY, MaxY

If the exec wiring is correct, these will change from the huge initial values to sensible world coordinates.

TL;DR

✅ Your MIN/MAX math wiring looks right now
❌ You still need to wire the white exec flow into the Set nodes inside the loop, otherwise nothing updates.

If you post a slightly zoomed-out version showing the white execution wires around those Set nodes, I can tell you in one glance if the exec chain is correct.

Short answer: no.
Long answer (with the one exception that matters):

The rule in Unreal Blueprints

Arrays are automatically created for you.
You do not need to “new” them like in C# or C++.

When you declare an array variable in a Blueprint:

Unreal allocates it automatically
It starts empty
You can immediately:
- Add
- Clear
- Length
- Get (if index exists)

So this is valid without any setup:

Clear MyArray
Add MyArray

No initialization node required.

The one thing you do need to do

You must clear it before rebuilding, otherwise you append forever.

Correct pattern

Clear TileMeshes
Clear TileMIDs

ForEachLoop(...)
  → Add TileMeshes
  → Add TileMIDs

That’s all.

What trips Unity devs up

In Unity/C# you’re used to:

List<Foo> list = new List<Foo>();

In Unreal Blueprints:

Declaring the variable is the constructor
There is no equivalent of new List<T>()

When things look like “array isn’t initialized”

This usually comes from one of these mistakes (not initialization):

Using Set Array Elem on an empty array
- This fails unless the index already exists
Using Get with an index that doesn’t exist
- Returns default / invalid
Appending repeatedly without Clear
- Indices drift and things stop lining up
Rebuilding one array but not the parallel array
- TileMeshes and TileMIDs go out of sync

None of these are “initialization” problems.

Quick sanity test

If this works:

Add increases Length
Clear resets Length to 0

Then your array is fine.

TL;DR

❌ No new / no init node needed
✅ Arrays exist as soon as the variable exists
✅ Always Clear before rebuilding
❌ Don’t use Set Array Elem unless you know the index exists

If you’re seeing weird array behavior right now, paste the exact node chain where you Add or Set, and I’ll point to the precise mistake in one glance.

Yep — there are two concrete issues in that graph that explain “array stays 0 elements”.

1) You’re not actually executing the “write to array” nodes

In Blueprints, Set Array Elem and Add only run if their white exec pin is triggered.

In your screenshot:

the Make Vector is being computed
but I don’t see an exec wire from the ForEachLoop → Loop Body going into either:
- Set Array Elem, or
- Add

So the math runs visually, but the array is never written to.

Fix

Do this inside the loop:

ForEachLoop (Loop Body) exec → Add (or Set Array Elem) exec

That’s mandatory.

2) You are using BOTH `Add` and `Set Array Elem` (pick one)

Right now you have:

an Add node (bottom right)
AND a Set Array Elem node

This is overkill and easy to wire wrong.

Use the simple approach: Clear + Add

Since you don’t need random access while building the array, do:

Clear NormalizedTilePositions
ForEachLoop(TileMeshes)
Each iteration:
- compute normalized vector
- Add it to NormalizedTilePositions

That automatically grows the array.

Do NOT use Set Array Elem unless you really need to write at a specific index.

Make your normalized math correct (quick sanity)

Your current math looks like it might be missing a subtraction.

To normalize position into 0–1 you want:

U = (PosX - MinX) / (MaxX - MinX)
V = (PosY - MinY) / (MaxY - MinY)

In your graph you’re doing some subtract/divide, but just confirm:

Numerator uses (Pos - Min)
Denominator uses (Max - Min)

Then clamp 0..1 if needed.

Exact Blueprint wiring you should end up with

Inside the loop:

Loop Body (exec) →
- GetWorldLocation
- math
- MakeVector(U, V, 0)
- Add (Target Array = NormalizedTilePositions, Item = MakeVector return)

After loop:

Completed → (optional) Print String of Length(NormalizedTilePositions)

Why you see 0 elements “in Details”

Two more gotchas to know:

A) You’re looking at the wrong instance

If the array variable is on an Actor Component, there can be:

the class default values (CDO)
the component template
the runtime instance

Only the runtime instance changes during play.

Best way to verify:

Use Print String with Length(NormalizedTilePositions) at the end of the loop.
Or while PIE is running, select the actual actor instance in the Outliner and inspect that component.

B) The event may not be called

Your logic is inside a custom event NormalizeTilePositions. If nothing calls it, array stays empty.

So make sure it’s called from:

BeginPlay or
whatever update flow you’re running

The fastest fix checklist

Ensure NormalizeTilePositions is called at runtime (BeginPlay).
Wire ForEachLoop → Loop Body exec into the Add node exec.
Remove Set Array Elem and just use Add after Clear.
Print Length after loop to confirm.

If you want, reply with a zoomed-out view showing where NormalizeTilePositions is called from — that’s the other common reason this stays at 0.

Short, direct answer first:

👉 Use Add.
Not Set Array Elem.

Why `Add` is the correct choice for your case

You are:

Clearing the array
Iterating once over TileMeshes
Building a fresh list of normalized positions
Appending one value per tile

That is exactly what Add is for.

Correct pattern

Clear NormalizedTilePositions

ForEachLoop (TileMeshes)
  Loop Body →
    Compute NormalizedPosition
    Add (NormalizedTilePositions, NormalizedPosition)

No indices. No resizing. No risk.

When `Set Array Elem` is appropriate (and when it is NOT)

`Set Array Elem` is ONLY correct when:

The array already has elements
You know the index exists
You want to overwrite a specific slot

Example:

Array size = 180
ForEachLoop with Array Index
  SetArrayElem(ArrayIndex, NewValue)

If you do not guarantee the size exists, the write will fail silently unless Size to Fit is enabled.

Why `Set Array Elem` is biting you right now

In your graph:

You clear the array
Then immediately try to Set Array Elem
The array length is 0
Index doesn’t exist
Nothing gets written

Yes, even though the math runs.

This is exactly why your array shows 0 elements.

Could you use `Set Array Elem` with “Size to Fit”?

Technically yes:

Enable Size to Fit
Use Array Index from the loop

But there is no benefit here over Add, and more ways to mess it up.

Unity analogy (so it clicks permanently)

`Add`

list.Clear();
foreach (var tile in tiles)
{
    list.Add(value);
}

`Set Array Elem`

list[i] = value; // list MUST already contain index i

You’re doing the first case.

Final recommendation (do this and forget about it)

Clear
Add
Never mix Add and Set Array Elem in the same build pass
Use Set Array Elem only when updating an already-built array

If you want, next I can:

sanity-check your normalized math,
help you map normalized positions → heatmap UVs cleanly,
or help you convert this to a render-target–driven update loop.

Cool — if the end goal is real-time heatmaps, the “optimized Unreal way” is: don’t read pixels on the CPU per tile unless you absolutely must. You push the heatmap to the GPU and let the GPU do the sampling.

There are two “optimized” architectures, depending on whether you truly need real component scale (CPU/transform) or you just need the visual effect (GPU/material).

Option 1 (fastest, most Unreal): GPU samples the heatmap in a material

No pixel reads. No CPU loops. Real-time at 60–120fps.

How it works

Your cameras/people system writes into a Render Target 2D (your Unity RenderTexture equivalent).
Your tiles are drawn using a material that samples that render target at the tile’s world position → gets a 0–1 value.
The material uses that value to:
- tint color
- “scale” visually (vertex shader / world position offset, or just emissive/intensity)

What you change in your setup to make this great

Convert your 180 separate mesh components into a single HISM (Hierarchical Instanced Static Mesh):

1 component, 180 instances
super cheap
the material can still vary per instance (and it can sample the RT)

Why this is the correct realtime approach

Reading pixels back to CPU forces a GPU→CPU sync (a stall). Doing that 180 times per frame is death. Even doing it once per frame can be costly.

Option 2 (only if you truly need CPU transforms): One GPU readback per frame, then apply

If you must physically scale components/instances on the CPU (for collision/gameplay), then you do exactly one readback per frame (or slower), not per tile.

The optimized CPU pattern

Heatmap lives in a RenderTarget2D
Each update (e.g. 30 Hz), do one bulk read:
- C++: FTextureRenderTargetResource::ReadPixels() (or async variants)
For each tile, compute UV → compute pixel index → sample from the already-read CPU array
Apply scale to instances/components

Blueprint-only pixel reads (Read Render Target Pixel) are too slow for “real time” if you do it per tile.

You’re doing “ground projection heatmap affects tiles.” That screams:

✅ HISM + Material sampling a RenderTarget2D (Option 1)
…and only switch to CPU transforms if you hit a hard gameplay requirement.

Concrete plan for Option 1 (fast realtime path)

1) Use a Render Target 2D (now and forever)

Create RT_Heatmap:

Format: R8 or RGBA8 (R8 is ideal for grayscale, if available)
Size: 512 or 1024 to start

2) Convert tiles to HISM

Make one Actor BP_TileField
Add a HierarchicalInstancedStaticMeshComponent
Add 180 instances at tile positions

(Your current 180 components from FBX are fine for prototyping, but HISM is the “Unreal way” for realtime.)

3) Material samples the render target by world position

In the tile material:

Convert AbsoluteWorldPosition → UV using your bounds (min/max)
Sample RT_Heatmap
Use .r as heat value
Drive:
- Color = lerp(ColorA, ColorB, heat)
- “Scale” visually = apply to vertex positions or WPO

Note: materials can’t truly “scale an instance” like a transform, but they can absolutely look scaled by moving vertices (and it’s extremely fast).

4) Live update

Whatever generates your heatmap (camera tracking) writes into RT_Heatmap every frame:

Draw Material to Render Target
or SceneCapture2D
or compute/material pass

No CPU involvement.

If you insist on actual transform scaling, here’s the optimized CPU version

Keep tiles as HISM
Each update (not every tick if possible):
- C++ bulk read RT to an array once
- Update instance transforms using that array

This still works great at 180 tiles, but it requires C++ or a plugin for a proper bulk read.

Quick question that decides everything

Do you need the tiles’ scale to affect collision / gameplay, or is it purely visual?

Visual only → I’ll give you the exact material node graph for world→UV→RT sample and the HISM setup.
Needs collision/gameplay → I’ll give you the C++ bulk readback approach (minimal code) and the instance update pattern.

Either way, the texture type you want long-term is the same: RenderTarget2D.