Part 7 — AAA techniques & tools

This is where you learn the systems behind big-budget visuals and worlds. You won’t master each in an afternoon, but you’ll know what they are, when to reach for them, and how to start.

Up to now WISP works but looks like a programmer art prototype: an orb, some boxes, a flat light. This part is the cosmetic-but-load-bearing pass — the wow moment. Each headline system below gets a short, runnable lab that plugs straight into the Hollow you already built. Do them in order or cherry-pick; the conceptual sections stay so you understand why before the how. Everything assumes the canonical Wisp project with L_Hollow_3D open and content living under Content/_Wisp/.

7.1 Nanite + Lumen + MegaLights (the visual trinity)

Covered in Part 4 — in production you combine them: Nanite for film-grade geometry, Lumen for dynamic GI/reflections (or Lumen Lite on weaker targets), MegaLights (production-ready in 5.8) for many dynamic shadowed lights at 60 fps — ideally paired with Lumen Hardware Ray Tracing. Add Virtual Shadow Maps (high-res shadows designed for Nanite) and Temporal Super Resolution (TSR) upscaling for the modern UE5 look.

For WISP these three are not decoration — they are the game. Every relit beacon should visibly bounce light into the Hollow (Lumen GI), cast crisp ray-traced shadows from its mesh, and stay cheap even when all five beacons are lit at once (MegaLights). The labs in 7.1a–7.1c turn those words into project settings you can toggle and see.

7.1a Lab — turn on the trinity for the Hollow

Project-wide render settings live in one place. Open Edit → Project Settings and search the left-hand filter for each term:

1. Lumen: under Engine → Rendering → Global Illumination set Dynamic Global Illumination Method to Lumen; under Reflections set Reflection Method to Lumen. (The Third Person template already defaults to Lumen on a desktop target — confirm rather than assume.)
2. Virtual Shadow Maps: under Engine → Rendering → Shadows set Shadow Map Method to Virtual Shadow Maps (Beta). VSMs are what make Nanite shadows sharp. Note that VSM is not something MegaLights and Lumen build on — for a MegaLights light it is just one optional per-light shadow method (the alternative, and default, being ray-traced shadows), and Lumen is a separate indirect-lighting system.
3. TSR: under Engine → Rendering → Default Settings set Anti-Aliasing Method to Temporal Super Resolution. This is the UE5 default and gives the soft, stable, upscaled image.
4. MegaLights: under Engine → Rendering → Direct Lighting tick Enable MegaLights (production-ready in 5.8) — it will prompt to also enable Support Hardware Ray Tracing; accept. Then select each beacon’s light component and confirm its Allow MegaLights property is ticked so the light routes through the many-lights path. Each light also exposes a MegaLights Shadow Method property — Ray Tracing (Default) or Virtual Shadow Maps; ray-traced shadows are the default. To disable MegaLights per scalability level or device, use the console variable r.MegaLights.Allow 0 (not r.MegaLights.Enabled).

Most settings prompt for an editor restart — allow it. To make Nanite obvious, select any Starter Content static mesh you use for a beacon plinth, and in its Static Mesh Editor tick Nanite → Enable Nanite Support, then Apply. Use the viewport View Mode dropdown (top-left of the viewport, default “Lit”) → Nanite Visualization and Lumen overlays to confirm each is actually running.

7.2 World Partition (open worlds)

• World Partition auto-divides a large level into a grid of cells that stream in/out based on distance, so you can build huge open worlds that don’t load all at once.
• Data Layers toggle sets of actors (day/night, story states).
• HLODs (Hierarchical Level of Detail) render distant cells as cheap merged proxies.
• One File Per Actor (OFPA) stores each actor as its own file so a whole team can edit the same giant level without merge conflicts — directly relevant to source control (Part 10).
• New in 5.8: experimental Mesh Terrain, a true-3D-mesh terrain system (caves, overhangs, floating islands) beyond the classic heightmap Landscape; and enhanced PCG (Procedural Content Generation) that lets artists hand-edit on top of procedural results.

7.2a Lab — a World Partition copy of the Hollow

Do this on a copy so your working level is untouched.

1. In the Content Browser, right-click Content/_Wisp/Maps/L_Hollow_3D → Duplicate, name it L_Hollow_WP. Open it.
2. Run the converter: Tools → Convert Level (the World Partition convert commandlet is also exposed here). Accept the defaults; it rebuilds the level as a World Partition map and moves actors to OFPA. For a fresh open world you’d instead use File → New Level → Open World, which is World-Partition-enabled out of the box.
3. Open the minimap: Window → World Partition → World Partition Editor (sometimes shown as the World Partition tab). You’ll see the cell grid over a top-down minimap; click Build Minimap if it’s blank.
4. Add a Data Layer: open Window → World Partition → Data Layers Outliner. Click + to create a Data Layer Asset — name it DL_Beacons, save it to Content/_Wisp/Data/. Select your beacon actors in the Outliner, right-click → Data Layers → Add Selected Actors to Selected Data Layer. Now toggle the eye icon on DL_Beacons to show/hide the whole set — that is the day/night, story-state switch.
5. Build HLODs (optional on a zone this small): Build → Build HLODs. On a tiny map you’ll see almost no proxies generated — that’s the point of the scope note above.

One File Per Actor (OFPA): after conversion, look in Content/_Wisp/Maps/L_Hollow_WP/ — the engine now creates an __ExternalActors__ folder where each actor is its own file. That is what lets two people edit the same level without a merge conflict; it also means your git status (Part 10) shows many small files instead of one giant .umap. Git LFS (set up in Part 0) handles these binary actor files.

7.3 Niagara (VFX)

• Niagara is the particle/VFX system: fire, smoke, magic, weather, fluids. It’s node/stack-based and can read from and write to the scene, run on the GPU for millions of particles, and react to gameplay.
• Start from the template emitters, then customize. VFX is a deep specialty — learn enough to use existing systems and make simple ones.

WISP needs exactly three small effects and no more: a trail behind the wisp, a sparkle on each mote, and a flame on each lit beacon. None require authoring particles from scratch — you start from a template emitter and trim it down. Niagara terms: a Niagara System (NS_ asset) contains one or more Emitters; each emitter is a stack of modules (Spawn, Initialize, Update, Render). You attach a system to an actor via a Niagara Component.

7.3a Lab — NS_WispTrail (a small glowing ribbon)

1. In Content/_Wisp/VFX/ right-click → FX → Niagara System. In the wizard choose New system from selected emitter(s) and pick a template close to a stream — the Fountain sprite emitter is a fine starting point (a continuous emitter you’ll shrink). Name the asset NS_WispTrail.
2. Open it. In the System Overview select the emitter, then trim it to a tiny glow:
   • Emitter Update → Spawn Rate: lower to roughly 40.
   • Particle Spawn → Initialize Particle: set Lifetime to ~0.4 s, Sprite Size small (e.g. 6–10), and Color to a bright cyan with a high value (e.g. RGB 0,4,5) so it reads as emissive/glowing.
   • Particle Update: add a Scale Color or Color → Curve module that fades alpha to 0 over life so the trail dissolves.
   • Remove or zero any Gravity Force and Add Velocity so particles linger where the wisp was rather than spraying.
   • Render: keep the Sprite Renderer; optionally swap to a Ribbon Renderer for a continuous streak (add a Ribbon renderer, then add the Initialize Ribbon module the editor prompts for).
3. Attach it to the wisp: open BP_Wisp, in the Components panel + Add → Niagara Particle System Component, name it WispTrailFX, parent it under the root/mesh, and set its Niagara System Asset to NS_WispTrail. Tick Auto Activate.

7.3b Lab — NS_MoteSparkle and NS_BeaconFlame

Same pattern, different feel:

• NS_MoteSparkle: new Niagara System from the Fountain/Sprite template. Lower spawn rate (~10), short lifetime, tiny bright white-gold sprites, and add a small upward/outward velocity so it twinkles. Open BP_Mote, add a Niagara Particle System Component set to NS_MoteSparkle, Auto Activate on. (On collect, your existing pickup logic destroys the mote, which stops the effect automatically.)
• NS_BeaconFlame: start from the Niagara Embers or a smoke/fire template if Starter Content’s Niagara content is enabled; otherwise build from Sprite with an upward velocity, warm orange color, and a turbulence/curl-noise force for flicker. Open BP_Beacon and add a Niagara Particle System Component named FlameFX set to NS_BeaconFlame, but untick Auto Activate.

Gate the flame on relight. In BP_Beacon’s relight logic (the same event that turns the light on, from Part 5), add a node sequence:

Event Relight (Custom Event / your existing relight trigger)
  -> (existing) PointLight: Set Visibility (New Visibility = true)
  -> Get FlameFX (Niagara Component)
  -> FlameFX -> Activate (Reset = true)

7.4 MetaHuman (realistic characters)

• MetaHuman creates fully rigged, photoreal digital humans. As of recent releases the creator is integrated inside the editor (no separate cloud app), and you can convert an existing mesh into a MetaHuman.
• 5.8 adds experimental MetaHuman Crowd — populate scenes with hundreds (mobile) to thousands (high-end) of crowd MetaHumans, orchestrated via Mass and rendered with Nanite, smoothly swapping between full Actors up close and cheap instanced meshes at distance.
• This is how you get AAA characters without a full character-art team — though rigging custom animation, faces, and clothing to a high bar is still real work.

7.4a Lab — BP_Keeper by the first beacon

The Keeper is the optional NPC guide from the capstone entity plan. Goal: a recognizable human standing by the first beacon with an idle animation — not a cutscene.

1. Enable the plugin if needed: Edit → Plugins, search “MetaHuman”, tick the MetaHuman Creator plugin (and MetaHuman Animator if present), restart. This also requires that MetaHuman Creator Core Data was selected when you installed the engine; if it wasn’t, modify the engine install to add it.
2. Create a character: right-click in the Content Browser → MetaHuman → MetaHuman Character, name it (save it under Content/_Wisp/Characters/), then double-click it to open MetaHuman Creator inside Unreal — the whole workflow is in-editor now, with no “Send to Unreal” cloud step. Customize a preset face/body, then click Assemble to produce the game-ready assets — a Blueprint, a skeletal mesh, grooms, and materials.
3. Make it WISP-canonical: use the assembled Blueprint as your Keeper, or duplicate it within Content/_Wisp/Characters/ and rename it BP_Keeper (keep the referenced MetaHuman mesh/groom assets where they were generated; just re-point if the editor asks).
4. Give it an idle: open BP_Keeper, select the Body (or the MetaHuman’s skeletal mesh component), set its Animation Mode to Use Animation Asset, and pick an idle from the MetaHuman/UE mannequin idle set (or any compatible idle anim sequence). For a one-shot guide that’s enough — no Anim Blueprint required.
5. Place it: drag BP_Keeper into L_Hollow_3D next to the first beacon, facing the player’s likely approach.

7.5 Animation at scale

• Control Rig — build rigs and do procedural animation (IK, foot placement) in-engine.
• Motion Matching — data-driven locomotion that picks animation poses from a large database matching the character’s motion; far more natural than hand-built state machines. Epic ships a free Game Animation Sample project to learn from.
• Sequencer — Unreal’s cinematic/timeline editor for cutscenes, scripted moments, and (with the Movie Render Queue / Movie Render Graph, production-ready and graph-based in 5.8) film-quality rendered output. This is the same pipeline Hollywood uses for virtual production on LED volume stages.

7.5a Lab (optional) — a rigged Wisp via the Game Animation Sample

WISP ships fine as an orb. But if you want to see production locomotion, the cheapest path is to borrow Epic’s free Game Animation Sample, which is built entirely around Motion Matching.

1. Get it: in the Epic Games Launcher → Unreal Engine → Samples, find Game Animation Sample and add it to a (separate) project on UE 5.8.
2. Study, then migrate: open the sample, locate its Motion-Matching character Blueprint, the Pose Search Database, the Pose Search Schema, and the locomotion Anim Blueprint. These four assets are the heart of Motion Matching.
3. Bring them across: right-click the sample’s character Blueprint → Asset Actions → Migrate, and migrate it (it pulls the database, schema, animations, and skeleton as dependencies) into your Wisp project’s Content/_Wisp/Characters/.
4. Swap WISP’s pawn: in BP_HollowGameMode set Default Pawn Class to the migrated rigged character (or re-parent BP_Wisp and replace its mesh + Anim Blueprint). Keep your Glow/interaction logic; you’re only changing the body and locomotion.

7.6 Production rendering & virtual production (context)

Unreal isn’t only a game engine — it’s the dominant real-time renderer for film/TV LED-volume stages (the Mandalorian technique). The cinematic tools (Sequencer, Movie Render Graph, nDisplay, Live Link mocap) overlap heavily with game cinematics. Worth knowing the path exists even if you only make games. For WISP you might one day record a 10-second “all beacons lit” flythrough in Sequencer and export it through the Movie Render Graph as a trailer clip — the same pipeline, scaled to a hobby slice.

7.7 New in 5.8 worth a look

• Toon Shader (experimental) — a Substrate-based shading model for 2D/anime/cartoon/hand-drawn looks across all platforms. Relevant if your “2D” ambitions are really stylized 3D.
• Unreal MCP plugin (experimental) — an open-standard gateway connecting LLM agents (Claude Code, etc.) to your Unreal project so they can drive the editor — covered in full in Part 8.
• Chaos destruction/cloth improvements and the node-based Dataflow system going production-ready.

7.8 Which lab should you actually do?

Use this to pick the one that buys WISP the most for the least effort: