MetaHuman Creator
Importing a Non Y-up DNA File Results in a Broken Mesh/Rig When Using Import From DNA
MetaHuman Creator only supports DNA files that are in the Left, Up, Front coordinate system. For any DNA file exported in a different system or rotated, for example, exported in Z up from Maya via Pose Editor, the Import From DNA tool will not convert the system and the resulting mesh/skeleton will be incorrect with wrong joint or mesh rotations.
Workaround
If the DNA file has come from Pose Editor, load the DNA in Y up and re-export. Otherwise import the DNA file into the content browser, open the created DNA asset and change the coordinate system to Left, Up, Front and export the DNA file via the context menu.
Exporting a DNA Asset Generated by MHC Doesn't Export in the Coordinate System Specified in the DNA Asset
DNA Assets created by MetaHuman Creator, either through assembling a character or saving a pose during Import From Custom Mesh have their coordinate system set to Left, Down, Front. If no user edits are made to change the coordinate system, when exporting a DNA file from the DNA asset via the right click context menu, the resulting DNA file will be in Left, Up, Front.
Workaround
To export the DNA Asset in the same system after a fresh assembly/save pose, open the DNA Asset and change the coordinate space to Left, Up, Front, press apply and then change it back to Left, Down, Front and press apply. Now exporting via the right click context menu will export the DNA file in the coordinate system as the asset displays.
Dragging and dropping a DNA file into Unreal doesn't convert the DNA to the correct coordinate space to work with skeletal meshes generated by MetaHuman Creator
Dragging and dropping a DNA file into the Content Browser converts the DNA file into Left, Up, Front coordinate system. To work with skeletal meshes generated from MetaHuman Creator, the DNA asset needs to be set to use Left, Down, Front.
Workaround
Open up the DNA Asset that was created via drag and drop, change the coordinate space to Left, Down, Front and press apply.
Editor Crashes on Mac When Loading MetaHuman Presets With Hardware Ray Tracing Enabled
On macOS, enabling Hardware Ray Tracing in Project Settings causes the Unreal Engine to crash when loading a MetaHuman preset in MetaHuman Creator. The crash occurs while the groom asset is loading and is specific to macOS — other platforms are not affected.
Workaround
Add the console variable r.HairStrands.Raytracing 0 to your project's DefaultEngine.ini or enter it in the console before opening MetaHuman Creator. This disables Hair Strands ray tracing and prevents the crash while Hardware Ray Tracing remains enabled for other rendering features.
Editor Crash on Linux When Assembling MetaHuman Characters Exhausts System Memory
On Linux, repeatedly assembling MetaHuman Characters in MetaHuman Creator can exhaust available system RAM. On machines with no swap space configured, the Linux kernel OOM killer forcibly terminates the editor process, which may cause the display to go blank and return to the login screen. On machines with sufficient RAM, the editor may stall indefinitely without crashing.
Workaround
Configure swap space on the Linux machine. This allows the kernel to recover more gracefully under memory pressure and reduces the likelihood of a hard system crash. Refer to your Linux distribution's documentation for instructions on enabling swap.
Unable to Control Texture Resolution in DCC Export Assembly Pipeline
Textures created by the DCC Export assembly pipeline do not respect texture resolution settings made in MetaHuman Creator.
Workaround
The underlying texture graph assets for all skin textures (/MetaHumanCharacter/TextureGraphs/TGI_SkinDCC) and eyes (/MetaHumanCharacter/TextureGraphs/TGI_Eye_Sclera_sRGB) can be modified manually to achieve a similar result. As these assets ship with Unreal Engine, care must be taken to avoid conflicts when updating engine versions.
Head Pose Driven by Body When Importing Head as a Whole Rig
Importing a head DNA as a whole rig causes the Animation Blueprint to copy the pose from the body and moves the head from its DNA-defined position. This causes the head to appear mispositioned in the editor.
Workaround
If a body DNA was authored specifically for the face DNA being imported, both should match and display correctly in MetaHuman Creator once both are imported. If no corresponding body DNA exists, there is no full workaround available at this time.
MetaHuman Animator
Face Board Controls Not Visible in Performance Editor
By default the face board controls are not visible in the MetaHuman Animator Performance editor.
Workaround
Panning the editor window containing the face board controls downward by dragging with the right mouse button brings the controls into view.
"Could Not Find a CPU Kernel" Log Spam During Body Solving
During body solving, the following message can be seen in the output log: [W:onnxruntime:, constant_folding.cc:278 onnxruntime::ConstantFolding::ApplyImpl] Could not find a CPU kernel and hence can't constant fold Sqrt node '/backbone/blocks.19/attn/Sqrt'.
Workaround
Ignore these messages, they do not affect the body solve output.
Live Link Hub UI Hangs for Approximately 10 Seconds When Selecting MetaHuman Video Source
Selecting the MetaHuman video source in Live Link Hub triggers a Windows Media Foundation (WMF) validation failure that blocks the Live Link Hub UI for approximately 10 seconds. This occurs on every select and deselect cycle. The log will show: LogWmfMedia: Error: Failed to create capture device media source: The data specified for the media type is invalid, inconsistent, or not supported by this object.
Workaround
A workaround is not available at this time.
Control Rig Misplaced in MetaHuman Performance
The Control Rig is misplaced in the MetaHuman Performance editor. When View A is active, the Control Rig is completely absent from the viewport. In View B, the Control Rig appears significantly above the skeletal mesh rather than in its expected position. This affects all Input Types.
Workaround
A workaround is not available at this time.
Handled Ensures When Opening a Previously Saved MetaHuman Performance Asset
Previously processed and saved MetaHuman Performance assets trigger handled Ensures when reopened in the editor. This can occur when opening an asset created in a previous editor version, or one saved in the same work session.
Workaround
No functional impact on workflows has been identified.
Incorrect Lighting in Performance Asset View A
The skeletal mesh in the Performance Asset appears darker than expected in the default View A (for example, with an image plane present).
Workaround
A workaround is not available at this time.
Current Pose Does Not Follow Track Markers in Promoted Frame (Free Roaming Camera Mode)
In Free Roaming Camera Mode within the Identity Asset editor, the Current Pose does not update when navigating between Promoted Frames using Track Markers. Jumping to each promoted frame directly works correctly; the issue is only triggered when selecting Promoted Frames via track markers.
Workaround
A workaround is not available at this time.
Audio Animation Output is Restricted to a Fixed Frame Rate
Animation generated from audio processing is output at a fixed frame rate of 30fps and cannot be configured to match your project's target frame rate.
Workaround
A workaround is not available at this time.
Crash When Processing Long Takes With Per Vertex Solve Enabled
When processing long Performance takes with Per Vertex Solve enabled, the editor may crash or the GPU may crash due to a Vulkan/RHI incompatibility. This is more likely to occur with takes that are several hundred frames or more in length.
Workaround
A workaround is not available at this time.
Rendering Artifacts on the MetaHuman Shown in the Performance Editor.
Certain rendering artifacts, such as glossy skin or a shimmering outline, may be present on a MetaHuman displayed in the Performance asset editor.
Workaround
None. The Performance asset editor is designed and optimized for reviewing animation over render quality. Animation review benefits from certain advanced engine rendering options being disabled. The consequence of this is that a MetaHuman may not have the same visual fidelity in the Performance asset editor as seen in other viewports.
Realtime Live Link Face Source Won’t Connect to the Live Link Face iOS App if ARKit Mode is Active
When using the Live Link Face iOS app, the Live Link Face Source within UE/Live Link Hub will be unable to successfully connect if the iOS app is configured to use the ‘ARKit’ mode as opposed to the MetaHuman Animator mode.
Workaround
Configure the Live Link Face iOS app to use the MetaHuman Animator mode. To do this:
Open the settings screen within the app.
Select Mode under the Capture section.
Select MetaHuman Animator and tap Continue.
This mode requires a device with a TrueDepth camera (for example, a device which supports Face ID).
Incorrect Inner Lip IDs in MetaHuman Identity
The curve configurations for the inner lips in the MetaHuman Identity asset contain incorrect IDs. This may cause minor visualization errors in the editor, and in cases where a user edits any curves, it can affect the quality of the conform fit — particularly for teeth pose.
Workaround
A workaround is not available at this time.
Face_Archetype_Skeleton Stops Playing Animation After Deleting a MetaHuman
Animation Assets targeting /Game/MetaHumans/Common/Face/Face_Archetype_Skeleton cease to display animation in their Viewports after a MetaHuman is deleted from the project. Once the first assembled MetaHuman is deleted (with the Common directory preserved), a Force Delete warning is displayed. From that point, any new or previously created Animation Assets targeting Face_Archetype_Skeleton will not show movement. Assembling a new MetaHuman does not restore normal behaviour.
Workaround
Do not delete the MetaHuman from the project, go back to viewing the animation within the MetaHuman Performance asset.
Package References Disallowed Object Errors When Saving MetaHuman Performance and Identity in UEFN
Saving MetaHuman Performance and MetaHuman Identity assets in UEFN results in Package References Disallowed Object errors. Saving the Face Skeletal Mesh produced from MetaHuman Identity also generates a separate set of these errors. The asset viewport may appear greyed out with no HDRI visible in the background. The Control Rig remains functional despite the errors.
Workaround
A workaround is not available at this time.
Crash When Processing Long HMC Footage in MetaHuman Performance Asset in UEFN
When processing lengthy Head-Mounted Camera (HMC) footage (approximately 15 minutes or more) in a MetaHuman Performance Asset in UEFN, a crash occurs after a variable amount of processing time. iPhone footage of equivalent length processes without issue. The hardware configuration and footage resolution may influence the maximum processable duration before a crash occurs.
Workaround
Use footage length of 15 minutes or less.
MetaHuman Identity Assets Created in Older Versions Open Empty
MetaHuman Identity assets created in a previous version of the MetaHuman plugin appear empty when opened in Unreal Engine 5.8. Both types of Identity are affected: those created from mesh (Mesh2MetaHuman) and those created from footage. No data is displayed in the Identity editor and the asset cannot be used for processing.
Workaround
Identity assets affected by this issue will need to be recreated in the current version of the plugin.
MetaHuman Capture
Error Processing Certain Mono Footage in MetaHuman Performance (UEFN)
iPhone footage may fail to import when the footage is imported via Mono Video Ingest source in Live Link Hub and the resulting Capture Data is added to a Performance Asset configured for Monocular Mode. Users are fully blocked from processing affected footage.
If footage fails to import you will receive the following error:
LogMetaHumanPipeline: Error: Process error in node "AnimationMerge" on frame 0 - Code 0, Message "Unknown control value: CTRL_expressions_tongueBendDown".
Workaround
A workaround is not available at this time.
Changing the Take Directory While Ingesting Causes In-Progress Jobs to Disappear
If the Take Directory in Capture Manager is changed while ingest jobs are actively running, all in-progress jobs are silently cancelled without any warning or confirmation. There is no way to recover the cancelled jobs.
Workaround
Do not change the Take Directory whilst ingest jobs are in progress. Wait for all active jobs to complete before changing the target directory.
Live Link Hub Process Remains Running on Mac After Closing the Window
On macOS, the Live Link Hub process does not terminate after the user confirms the quit dialog. The user interface is dismissed, but the process remains visible in the Dock and must be manually terminated via Activity Monitor. This issue is specific to macOS and does not affect Windows or Linux.
Workaround
Manually end the Live Link Hub process using Activity Monitor after closing the application window.
Live Link Hub Always Defaults to First Ingest Target When Multiple Clients Are Running on the Same Machine
When multiple Unreal Engine clients are running on the same machine, the host name and upload target in Live Link Hub always defaults to the first entry in the list, regardless of which client the user intends to target.
Workaround
A workaround is not available at this time.
Stereo Video Ingest Derives Camera Component Names From Full Filename Including Extension
When footage is ingested via the Stereo Video Ingest device, the camera component name is derived from the full filename including its file extension. For example, a file named bot.mov produces the component name bot_mov after sanitisation, rather than the expected bot. This causes a silent mismatch when camera names need to correspond between a .cptake file and a Stereo Video device — the .cptake uses the filename stem (bot) while the Stereo Video device produces bot_mov, breaking downstream correspondence between the two sources.
Workaround
Ensure source footage filenames do not include a file extension that would be incorporated into the component name, or manually rename the component in the .cptake file to match the name produced by the Stereo Video device (appending _mov, _mp4, and so on, as appropriate).
Top Camera Selected as Default for HMC Footage in MetaHuman Performance and Identity on Mac
On macOS, when HMC (Head-Mounted Camera) footage is added to a MetaHuman Performance or MetaHuman Identity asset, the Top camera is incorrectly set as the default camera. On Windows the Bottom camera is correctly selected as the default. Selecting the Bottom camera manually after opening the asset triggers a "Non-Default Camera" warning. This affects both Monocular and Depth footage workflows.
Workaround
After adding HMC footage to a MetaHuman Performance or Identity asset on Mac, manually switch the camera selection to the Bottom camera. The "Non-Default Camera" warning that appears can be safely dismissed — processing will complete correctly with the Bottom camera selected.
Capture Manager Crashes When Third-Party FFmpeg Executable Has a Non-Standard Name
When the third-party encoder is enabled in Capture Manager Settings and the FFmpeg executable path points to a binary with a non-standard name (for example, ffmpeg-6.1.exe or ffmpeg-6.1), the editor crashes during timecode extraction. Capture Manager derives the FFprobe path by performing a string replacement on the FFmpeg filename — if the filename does not exactly match ffmpeg, the internal assertion fails. This affects any workflow that uses a versioned or otherwise non-standard FFmpeg binary name.
Workaround
Ensure the FFmpeg executable is named exactly ffmpeg (or ffmpeg.exe on Windows) and that the corresponding ffprobe binary is present in the same directory with the name ffprobe (or ffprobe.exe). Renaming or symlinking versioned binaries to the standard names resolves the crash.
Landmark Points and Curves Missing After Switching Capture Data for Teeth Pose in Identity Asset
In a MetaHuman Identity asset, if the Capture Data source for a teeth pose frame is changed to a different Capture Data after the teeth have already been fitted and the asset saved, reopening the Identity asset causes the landmark points and curves to no longer be visible for that teeth pose. The promoted frame also cannot be demoted. The Identity asset otherwise functions correctly and downstream processing is not affected.
Workaround
Avoid switching the Capture Data source for a teeth pose after fitting has been completed. If a different Capture Data is required for the teeth pose, remove the existing teeth pose frame, switch to the intended Capture Data, and re-promote and re-fit the teeth pose from scratch.
Stereo Video Ingest Produces Image Sequences With Invalid Timecode
When footage is ingested via a Stereo Ingest device in Live Link Hub, the resulting image sequences have their timecode set to 00:00:00:00 regardless of the timecode embedded in the source file. The frame rate is correctly extracted, but the timecode is not. This affects downstream workflows that rely on timecode for synchronisation or correspondence between multiple capture sources.
Workaround
A workaround is not available at this time.
No Warning Displayed When Archive Path Is Pointed at a Very Large Directory in Live Link Hub
When a take ingest archive source in Live Link Hub is pointed at a very large directory (such as a drive root), the application silently scans the path without displaying the previous confirmation warning that indicated how many paths had been analysed. The UI no longer hangs during the scan, but there is no feedback to indicate that an unusually large number of paths are being processed, which can cause the ingest pipeline to appear unresponsive without explanation.
Workaround
Avoid pointing the archive source at very large or root-level directories. Set the archive path to the specific folder containing your capture data to minimise the number of paths scanned and prevent unexpected delays.
Invalid Depth Generated When Mixing Take Archive Device and Stereo Video Device During Ingest
When ingesting stereo calibration and performance takes using a mix of Take Archive Devices and Stereo Ingest Device, depth generation can fail due to mismatched camera names.
Workaround
Ingest both performance and calibration takes using the same device type (Take Archive Device or Stereo Video Device).
If using the Take Archive Device, ensure the Name for each Video is consistent for both performance and calibration takes.
Calibration Processing
Incorrect Video Track Duration After Capturing High Frame Rate Takes in Live Link Face 1.6.0
Version 1.6.0 of the Live Link face for iOS now includes more flexible capture options including the ability to capture footage at much higher frame rates than previously offered. On certain iOS devices this may result in dropped video frames being absent from the recorded .mov files due to system performance constraints. Whilst these takes will be ingested into UE without error, the video tracks will appear to have a shorter duration than expected when viewed within the MetaHuman Animator identity or performance editors. This will result in accelerated playback, unexpected animation results and audio misalignment.
Workaround
The simplest workaround is to re-record the take using a less demanding target frame rate, however if that is not possible then the take can be repaired outside of UE using ffmpeg. Note that the take will need to be re-ingested once the following modifications are made:
Ensure ffmpeg is installed on your system and available as part of the PATH environment variable.
Ensure you have a copy of the problematic Live Link Face take data on your PC.
Navigate to the location of the take and open the directory with PowerShell.
In PowerShell, prepare the following ffmpeg command:
ffmpeg -noautorotate -i input.mov -q:v 3 -filter:v fps=90 -c:v mjpeg output.movBe sure to specify the correct
input.movname for the given take, there should be a single.movfile within the take directory.Specify the relevant target frame rate for the
fps=portion of the command.
Execute the command.
On completion make a note of the final
frame=(number)value output by ffmpeg, we’ll use this to update the take metadata which is required for successful ingest into UE.Open the
take.jsonfile within the take directory and update the value for the "frames" JSON property to match the final frame count produced by ffmpeg.Rename the new
output.movfile to match the name of the original.movfile within the take.You will need to either delete or rename the original mov file. This file will no longer be used for ingest.
Ingest the take with the updated
.movfile using the target archive ingest approach.
Live Link Face Android
Live Link Face Android Dev Builds Produce Broken Face Tracking on Samsung Galaxy S25
Face tracking output from Live Link Face Android is broken on Samsung Galaxy S25 devices. All raw control values are pinned to either 1.0 or approximately 5.96e-11, producing extreme or incorrect animation on the MetaHuman in Unreal Engine.
Workaround
Use a device such as a Galaxy S24, Galaxy S24 Ultra, or Google Pixel 9.
Interrupted Recordings Produce Corrupt Takes
If a recording session is interrupted, the resulting take may be corrupt and unusable for further processing.
Workaround
A workaround is not available at this time.
MetaHumans in Unreal Engine
Face Deformation When Dropping a UAF MetaHuman Blueprint Into the Scene
When a MetaHuman Blueprint assembled with Unified Animation Framework (UAF) support is dragged into the scene, the face may appear deformed.
Workaround
Playing the animation resolves the deformation.
Texture Seam Lines Visible on Assembled MetaHumans
Texture seam lines are visible on MetaHumans both in the MetaHuman Editor and after assembly in the viewport. In the editor, a seam line appears between the Body Mesh and Head Mesh. After assembly, additional seam lines may appear at the back of the shoulders, the Head/Body Mesh boundary, and the waist. The issue is more noticeable with non-direct lighting or in shadow, and affects all quality levels and skin tones.
Workaround
A workaround is not available at this time.
Long Messy Hair Groom Does Not Follow Head During Animation on Medium Quality MetaHumans
The Long Messy Hair groom asset does not remain attached to the head during animations on Medium quality MetaHumans. The groom clips through the head and bald spots appear at the top of the head. This issue affects only Card Grooms on Medium UE Optimized Quality MetaHumans and is visible in both the editor viewport and packaged builds.
Workaround
Use an alternate quality level or groom.
Breast Geometry Level Differs Across LODs During Animation
After applying animation to a MetaHuman Blueprint, the breast geometry level differs between LODs. LOD 0 shows the highest breast level and LOD 7 shows the lowest. The difference is more noticeable on larger chest sizes.
Workaround
A workaround is not available at this time.
MetaHumans in UEFN
Illegal Property Override Validation Fix-Up Causes Outfit Corruption in UEFN
Launching a UEFN session containing MetaHumans causes Illegal property override warnings in the validation message log. Running the suggested Fix-up corrupts clothing on all MetaHumans in the level, stretching it downwards. The Outfit is not required for the validation warnings to appear; however, the corruption only affects MetaHumans that have clothing.
Workaround
Ignore the Run Validation Fix-up? notification. The session launches successfully without visual corruptions if the fix-up is not applied.
MetaHuman Blueprint Causes Texture-Override Validation Errors Blocking Local Session in UEFN
Opening a UEFN project that contains a MetaHuman Blueprint generates Illegal property override validation errors related to MaterialSlotsOverlayMaterial. These errors are logged in the Output Log and may prevent running a local session.
Workaround
A workaround is not available at this time.
UEFN MetaHumans Use Only 8 Bone Influences and Recompute Normals via Skin Cache
MetaHumans exported for UEFN use only 8 bone influences instead of the 12 used in standard UE projects. Additionally, normals are recomputed using the skin cache rather than the preferred mesh deformer method. This may result in subtle visual quality differences compared to standard UE MetaHumans.
Workaround
A workaround is not available at this time.
Low LOD MetaHuman Head Skin Texture Appears Too Dark in UEFN
On Xbox One, low quality MetaHuman characters assembled from UE 5.7 have head skin textures that appear visibly darker than expected when compared to Medium and High quality versions. The issue has also been observed on other platforms to a lesser degree.
Workaround
A workaround is not available at this time.
Flickering Pixelated Hair Shadows on Certain MetaHumans in UEFN (Xbox Series, PS5)
Hair shadows cast by certain MetaHumans flicker and appear pixelated on Xbox Series S, Xbox Series X, and PS5. Affected characters include Chandra (all LODs on XSX|S; high LOD on PS5), Taro (high/medium LODs on XSX|S and PS5), and Hana (high/medium LODs on XSX|S; high LOD on PS5). The issue does not reproduce on PC, Xbox One, or Android.
Workaround
A workaround is not available at this time.
Eyebrow Grooms Do Not Follow Facial Animations on Switch and Android in UEFN
In UEFN, eyebrow grooms on Medium and High quality MetaHumans do not animate with the rest of the face on Switch and Android. The groom remains static during facial animation, causing visible clipping through the head mesh. Low quality MetaHumans are not affected as they use baked eyebrows only.
Workaround
A workaround is not available at this time.
MetaHumans on Fab
MetaHuman Package Export Omits Parent Materials for Non-Default Clothing and Grooms
When a MetaHuman Character (Assembly) with clothing or grooms sourced outside the MetaHuman plugin's bundled content is packaged via MetaHuman Manager, the resulting .mhpkg file is missing parent materials. Clothing renders with the engine's default world-grid texture on import, and grooms revert to their original shipped state. MetaHuman preset content bundled within the plugin packages and imports correctly. This issue specifically affects content sourced from outside the plugin (for example, Wardrobe content acquired from Fab).
Workaround
A workaround is not available at this time.
Editor Crash When Importing an mhpkg Containing Multiple Character Assemblies
Importing an .mhpkg file that contains more than one Character (Assembly) triggers a hard assertion inside UMetaHumanPackageFactory::ImportObject(). The first Character (Assembly) in the package imports successfully, but the editor crashes when the factory begins processing the second Character. Importing two separate single-character .mhpkg files back-to-back does not reproduce this issue.
Workaround
Package each MetaHuman Character Assembly into its own separate .mhpkg file (one character per package) and import them individually.
Include in Package List Not Scrollable in MetaHuman Manager
When a MetaHuman Character referencing a large number of WardrobeItem assets is selected in MetaHuman Manager, the Include in Package list only shows items that fit within the visible vertical space and cannot be scrolled. Items beyond the visible cutoff cannot be viewed or individually toggled, preventing users from confirming or adjusting the full set of assets before packaging.
Workaround
A workaround is not available at this time.
WardrobeItem Verification Incorrectly Flags Unrelated Assets
When verifying a single WardrobeItem in MetaHuman Manager, the verification engine incorrectly flags unrelated WardrobeItems using rules that only apply to the type of asset being verified. For example, selecting a groom WardrobeItem and clicking Verify reports errors against clothing WardrobeItems, incorrectly stating that those items should use a groom-derived pipeline.
Workaround
A workaround is not available at this time.