Lighting
One collection is the whole interface. No light actor is ever read.
| Parameter | xyz / rgb | w / a |
|---|---|---|
SunDirection | direction toward the light | unused, deliberately |
SunColor | colour | intensity |
Indirect | diffuse scale, specular scale, clamp min | clamp max |
Depth | brighten start, brighten end, brighten max | rim scale max |
Packed into vectors rather than spread over scalars, because each one is a node in every graph that reads it and four components cost the same one node as one does.
The sun
Fort → Sync Sun From Directional Light writes your level's directional light in and saves.
SunColor's intensity is left where it was, because a light actor's intensity is in lux and an unlit master has no exposure to relate that to - copying it across would blow every character out the moment someone brightened the level. The specular darkening exponent in SunDirection.w is preserved for the same reason.
One shot. For a sun that keeps moving, see below.
Live, with ForwardRender
ForwardRender ticks the level's directional light into an MPC every editor frame, so the sun stops being something you remember to sync. It also puts the editor into mobile forward preview at load, which is the only mode where the numbers on the cost page mean anything.
Project Settings → Editor → Forward Render Settings:
| Light Vector MPC Path | /MobFort/MPC_FortLighting |
| Light Vector Parameter Name | SunDirection |
| Invert Light Vector | on - it writes the forward vector, and this wants the direction toward the light |
Then click Set as Default, or the settings revert.
SunDirection.w carries nothing. ForwardRender writes the vector as a whole colour, so its alpha lands on the fourth component whatever you put there - which is exactly why the specular darkening exponent is its own scalar rather than packed alongside. Nothing MobFort needs can live in w.
It ticks in the editor only, and not during PIE. Drive the same parameter from your game code or level Blueprint if the sun moves at runtime.
Indirect
There is no light actor in this path and no indirect lighting cache to sample, so these two scales are the hook a lighting volume writes.
| Diffuse scale | how lit this area's characters are |
| Specular scale | the same for reflections, then raised to the darkening exponent |
| Clamp min / max | the window both are held inside |
Two scales rather than one because specular has to darken faster than diffuse as an area gets darker. A shadowed character lit only by a reflection reads as a chrome cutout otherwise.
The clamps are the point. A bright volume cannot blow a character out and a dark one cannot swallow them - which is the whole reason this is a pair of scalars and not a light.
Distance
A character far from camera covers a few dozen pixels, and every cue that identifies them - silhouette, palette, rim - is fighting the background at that size. So both the brightness and the rim widen with range.
Set it to zero if your game never puts characters at distance. It is a compensation, not a look.
| Brighten start / end | the range the response ramps over, in world units |
| Brighten max | how much brighter, at the far end |
| Rim scale max | how much wider the rim gets, at the far end |
Both clamped at the far end, or a distant target turns into a lamp.
Brighten scales the lit term rather than adding to it. A flat add lifts the core shadow along with everything else, and the character goes milky at exactly the distance the cue was for.