I’ve done this before, more than once. Each time I had a working process — a set of steps I knew got me a moving MetaHuman by the end — but I’d never actually verified why any individual step mattered. This time I wanted to slow down: rerun my own process, but stop at every point where I’d normally just do the thing without questioning it, and actually test what happens if I don’t.
This post is that investigation. It’s not a step-by-step guide — Epic’s own docs and plenty of videos already cover the happy path. Instead, this is a record of six specific points in the process where I stopped, poked at an assumption I’d been carrying, and either confirmed it or found something more interesting underneath.
For context, here’s the process I use to get a MetaHuman moving inside a Third Person template project:
BP_MC_Character blueprint, copy its components, and paste them into BP_FirstPerson (or your ThirdPersonCharacter blueprint).Num LODs = 2, Forced LOD = 1 on the LODSync component.
That’s the whole process in ten lines. Below are the six places where I stopped and asked “wait, why.”
My usual process was to copy everything from BP_MC_Character except its Root component before pasting into the ThirdPerson character. I’d always assumed Root was a special, load-bearing component and that copying it over would conflict with the target blueprint’s own Root — presumably breaking collision or movement.
I tested it anyway. I copied the Root component along with everything else and pasted it into BP_ThirdPersonCharacter.
Nothing broke. The character moved exactly the same, collision was intact, and honestly the hierarchy felt marginally cleaner to read.
The reason turned out to be simpler than “it breaks something”: ACharacter (the C++ base class behind any Character blueprint) hard-codes its RootComponent to be the CapsuleComponent. Unlike a plain Actor blueprint, you can’t drag a different component into the Root slot in a Character blueprint — the engine won’t let you. So when I pasted in BP_MC_Character‘s Root, it didn’t replace anything; it just landed as an extra child node under the Capsule.
I also checked whether this Root had a non-zero Transform that might explain the “exclude it” advice — if it were offset from origin, pasting it in unmodified could shift the whole hierarchy. Filtering the Details panel search for “Location” and “Rotation” returned nothing, which was unexpected enough that I don’t want to overclaim what it means — possibly a display quirk of this component type in this engine version. What I can say concretely: Scale was left at (1,1,1), and nothing in the Construction Script touches this Root’s transform. Whatever is going on with the hidden properties, it isn’t producing any visible or measurable effect.
Verdict: excluding Root appears to be a tidiness habit, not a functional requirement. Including it adds one redundant node to the hierarchy and nothing else — confirmed by testing, not just by finding “identity transform” values.
My process has me add a single Set Leader Pose Component node, target it at each copied MetaHuman mesh (Body, Face, extra SkeletalMeshes), and set the New Leader Bone Component to Mesh — the original Third Person template’s Manny skeletal mesh.
Rather than take this step on faith, I opened BP_MC_Character‘s own Construction Script to see how MetaHuman handles this internally when it isn’t being ported into someone else’s character.
It does something structurally similar but automated: it calls Get Children Components on Body, loops over every child, casts each to a SkeletalMeshComponent, and calls Enable Master Pose on every one of them except Face — which is explicitly excluded by a branch check.
That explains the mechanism precisely: Leader Pose is a bone-driven puppeteering system. One SkeletalMeshComponent (the Leader) runs the actual skeletal animation — in our case, Manny, driven by the ThirdPerson template’s AnimBP and CharacterMovementComponent. Every other SkeletalMeshComponent (the Followers) doesn’t animate independently; it just copies the Leader’s bone transforms by matching bone names. Visually you see a MetaHuman walking and jumping, but the actual pose math never touches MetaHuman’s own animation system — it’s all coming from Manny underneath, invisible.
This also means the manual wiring in my process is a simplified re-implementation of what MetaHuman already does for itself, just repointed at a foreign skeleton (Manny) instead of its own Body mesh. Whether Face should be included as a Follower here is arguably inconsistent with MetaHuman’s own internal logic (which explicitly excludes it) — but in my test, connecting Face to Manny’s leader pose caused no visible problem, most likely because there’s no bone-name overlap between Manny’s skeleton and MetaHuman’s facial rig for anything to accidentally copy.
Verdict: Leader Pose Component is a bone-copying relationship, not a blend or sync — one mesh computes the pose, everyone else just mirrors bone transforms by name.
This one is straightforward, but worth showing rather than telling. The Third Person template’s original Mesh component (Manny, hidden inside the capsule) still exists after you paste in the MetaHuman parts — it’s just not usually visible because the template already keeps it out of view in first-person mode, or because people assume Leader Pose alone handles display.
If the original arm/body mesh’s visibility isn’t explicitly turned off at the Root, you get exactly what you’d predict: two skeletal meshes occupying the same space, rendered on top of each other.
Turning off Visible on that original mesh component resolves it immediately. Nothing subtle here — just confirming that the instruction is load-bearing, not a “just in case” step.
The first time I opened a MetaHuman Face asset, Unreal popped a Missing Project Settings dialog:
r.GPUSkin.Support16BitBoneIndex = True
r.GPUSkin.UnlimitedBoneInfluences = True
SkeletalMesh.UseExperimentalChunking = 1
Interestingly, when I repeated this on a fresh 5.8 project, the same dialog only listed the first two settings — no SkeletalMesh.UseExperimentalChunking. I haven’t tracked down whether that’s an engine-version change between 5.7 and 5.8 or something specific to how each project was set up. Flagging it here as an open question rather than pretending I’ve resolved it.
The reasoning behind the two consistent settings is straightforward once you know what they gate:
r.GPUSkin.Support16BitBoneIndex — by default, skinned meshes reference bones per-section using an 8-bit index, capping a section at 256 bones. MetaHuman’s Face mesh has far more bones than that once you count the fine control bones used for micro-expressions, so it needs the 16-bit path enabled just to address them all.r.GPUSkin.UnlimitedBoneInfluences — vertices are normally limited to 4 or 8 bone influences each. Facial deformation around areas like the mouth corners and eyelids often needs to blend more bones per vertex than that default allows.I deliberately did not re-enable these and then test facial animation to see the failure mode directly — that would mean setting up LiveLink or ARKit capture, and driving expressions is a separate topic from “make MetaHuman playable,” which is the actual scope of this post. What I can say honestly: with the settings left disabled, a static Face mesh in a neutral pose showed no visible breakage. The failure modes these settings prevent (bone misassignment, faceting at high-influence vertices) would be expected to show up under active facial animation specifically — testing that is a good candidate for a dedicated follow-up post on MetaHuman face rigs and LiveLink.
Verdict: these settings exist because the Face rig’s bone count and per-vertex influence count exceed Unreal’s conservative defaults. Confirmed the why; did not chase the visual failure mode, by scope, not by accident.
Num LODs = 2, Forced LOD = 1 specifically?My process has me set these two numbers, but I’d never checked what happens if I don’t — i.e., leave LODSync at its defaults (Num LODs = 8, Forced LOD = -1, meaning fully automatic LOD selection).
With the defaults, in-game the character’s skin and hair rendered unstable and glitchy — visibly worse than expected, with texture and geometry detail flickering as if streaming couldn’t keep up. Part of this coincided with a POOL OVER ... MiB BUDGET warning, which points to Virtual Texture streaming pressure rather than LOD selection alone — MetaHuman’s textures stream in at variable resolution, and under memory pressure you get low-resolution fallbacks that can look flat or discolored. That’s a separate, adjacent issue from LOD switching itself, and I’m not conflating the two.
I then applied my usual values, Num LODs = 2, Forced LOD = 1:
The result was visibly more stable — no flickering, consistent detail level, no jaggy popping during movement. Switching back to the defaults reproduced the jaggy behavior again.
So the practical answer to “why these numbers”: forcing a fixed LOD removes automatic LOD switching as a variable entirely. Rather than letting the engine recompute which LOD to show every frame based on screen size and distance — which becomes unstable under texture streaming pressure — you pin it to one known-good LOD level and the instability disappears. Forced LOD = 1 specifically balances quality against performance; going to 0 uses the highest-quality LOD across all components, which Epic’s own documentation notes can hurt performance at scale (e.g., in crowds), even though for a single playable character it’s likely fine.
I also noticed the character’s overall look — skin tone, hair color — shifted noticeably under different in-level lighting compared to the neutral studio lighting in the MetaHuman Creator preview. That’s a lighting/shading observation, not a LOD one, and worth keeping separate; MetaHuman’s skin shader is tuned around specific lighting assumptions, and it’s a topic on its own.
Verdict: the fixed LOD values aren’t arbitrary — they trade the instability of automatic LOD/texture streaming decisions for a fixed, predictable result. Confirmed by directly reproducing both the broken and stable states.
After Assembling a MetaHuman, opening its asset back up in the MetaHuman Creator’s Head & Body tab shows this warning:
“The Asset you’re editing is rigged. Preset selection and Modelling operations require that the rig is deleted to unlock editing.”
Rather than take the warning’s word for what “Modelling operations” means, I checked what was actually locked and what wasn’t.
Locked while rigged: Blend, Body Params, Head Transform, Head Sculpt, Teeth & Eyelashes — anything that changes facial or body geometry.
Still editable while rigged: Materials, Hair & Clothing, and the rigging operations themselves (Create Full Rig / Create Joints Only Rig / Remove Rig).
That split makes sense once you think about what rigging actually is: binding a skeleton’s bones to a mesh’s vertices with specific weights. Changing sculpt or body proportions would alter the mesh’s topology and vertex layout — which would invalidate the existing bone weight bindings. Materials and hair/clothing, by contrast, are separate assets layered on top and don’t touch the base mesh’s geometry or its bone weights, so they stay editable regardless.
I confirmed the causal direction directly: pressing Remove Rig immediately unlocked Blend, Body Params, Head Transform, and Head Sculpt again.
Verdict: the lock isn’t arbitrary UI friction — it protects the geometry/rig binding from being invalidated silently. Confirmed both directions: locked while rigged, unlocked the moment the rig is removed.
Six small investigations, six confirmed (or honestly scoped) answers:
ACharacter‘s RootComponent is fixed to the Capsule regardless.Num LODs = 2, Forced LOD = 1 isn’t an arbitrary number — it removes automatic LOD/streaming instability that’s visibly reproducible at engine defaults.None of this changes the process itself. What changes is that I now know why each step exists, which ones are actually load-bearing, and which are just habit. That’s the difference between having a process that works and actually understanding the kitchen it runs in.
Reference: Controlling MetaHuman Levels of Detail (LODs) in Unreal Engine — Epic Games documentation