Morph target normal/tangent deformation works on imported LODs but not on LOD0

We’re seeing a consistent issue with skeletal meshes where morph target normal/tangent deformation only works when a mesh is imported as a LOD of an existing skeletal mesh, but not when imported as LOD0.

Behavior:

  • Import mesh with morphs as LOD0 - morph positions work, but normal/tangent deformation does not affect shading.
  • Import the exact same mesh as LOD1/LOD2 of the same asset - morph normals/tangents work correctly.
  • Import the same mesh as a separate skeletal mesh - morph normals also do not work.

Build settings and section flags are identical across LODs. We tested all combinations of “Recompute Normals/Tangents”, “Use Imported Tangents”, “MikkTSpace”, etc. No change. Morph targets do contain tangent-space deltas.

So far the only scenario where morph normal/tangent deformation works is when the mesh is imported as a LOD into an existing skeletal mesh.

Question:

Is this expected behavior? If not, what is the correct import/build setup so that morph normal/tangent deformation works on LOD0 as well?

The first image shows LOD0 where morph target normal/tangent deformation is not applied (normals stays unchanged).

The second image shows the same morph on LOD1, imported as a LOD, where normal/tangent deformation is applied correctly.

[Image Removed]

[Image Removed]

Steps to Reproduce

Hi,

Thanks for reaching out. This might be a known issue for which there are some workarounds. Can you please try the following:

+ Add the Deformer Graph plugin to your project

+ Enable Show Plugin Content in the Settings

+ Open the skeletal mesh asset, and search for Mesh Deformer

+ Check Allow Mesh Deformer, set the Default Mesh Deformer to DG_LinearBlendSkin_Morph and check how it looks in the viewport (should be the similar to the default skin cache implementation without recomputing tangents)

+ Now try DG_LinearBlendSkin_Morph_Cloth_RecomputeNormals and see how that looks (should recompute the tangents in a similar way to the skin cache implementation)

+ Finally try DG_LinearBlendSkin_Morph_Cloth_RecomputeNormals_Scatter (this implementation deals with the half-edge problem around mesh chunks that the previous deformer and the skin cache implementation doesn’t, so should give better results)

If that doesn’t work, you can try the following steps:

+ Go into Project Settings > Engine > Rendering > Optimizations and enable “Support Compute Skin Cache”, then restart the editor

+ After the editor re-opens, open the skeletal mesh, go to its Asset Details -> LOD 0 -> Sections

+ Find the section used for the shirt mesh and set its Recompute Tangents option (the option next to the Material and not the one in the Build Settings) to “All”

Please let me know if that works.

Thanks,

Sam

Hi Sam,

Thanks for the detailed reply.

I haven’t been able to test the Deformer Graph setup yet, but it will probably be difficult for us to use in production. Our final characters are built at runtime from multiple skeletal mesh parts (body, shirt, etc.) into a single combined skeletal mesh, so per-mesh deformer setup is tricky and might not scale well.

We did try the Recompute Tangents option on simple skeletal mesh components, and that does fix the normals there. However, for our generated combined characters this approach likely won’t work for us (both technically and in terms of performance), according to our dev. Our goal is to keep using precomputed/imported tangents, not to recompute them at runtime.

What we’ve observed is that on the LODs where tangents are generated by the engine, morphs and normals behave correctly in our setup. The only issue is that we haven’t found a way to get the same behavior for LOD0. It feels more like a pipeline/import issue than a runtime one: the mechanism clearly works on some LODs, but doesn’t seem to apply consistently to LOD0.

So the question is:

Is there a known way to make LOD0 use the same tangent/morph pipeline as the imported LODs, or could this be an inconsistency on your side that might be worth looking into? From our perspective it looks like the functionality is there, but some path or options for LOD0 might be broken or incomplete.

Thanks,

Andrey

Hi,

This can happen when multiple baked normals are blended or it may be a bug in the import pipeline as you suggested. Would it be possible to emulate the logic which recomputes the normals on mesh import?

Would you be able to provide a simple mesh that reproduces the issue you are seeing or repro steps?

Thanks,

Sam

Quick update – I’ve narrowed this down and it looks like a regression between 5.5 and 5.6/5.7.

I’ve attached a minimal FBX to reproduce the issue: a tessellated cube with a single morph target (LaplacianSmooth).

Repro:

  1. In UE 5.5
  • Import the attached FBX as a Skeletal Mesh with default settings.
  • Set the morph target value to 1.
  • Result: the cube shape is smoothed and the normals follow the morph as expected (shading changes correctly).
  1. In UE 5.6 or 5.7
  • Import the same FBX as a Skeletal Mesh with the same default settings (no changes from 5.5).
  • Set the morph target value to 1.
  • Result: the cube shape is smoothed, but the normals stay unchanged (shading does not react to the morph).
  1. Still in UE 5.6/5.7
  • Open the imported mesh, go to LOD Settings and set the number of LODs to 2.
  • Reimport the same FBX as LOD1.
  • Result: on LOD1, the morph affects the normals correctly (shading changes), while on LOD0 it still does not.

There is no custom code or custom normal blending involved, just default import settings in all cases.

So LOD0 morph normals are handled differently (and incorrectly) in 5.6/5.7.

Let me know if you need any additional info from my side. [Image Removed]

Thank you for the great repro steps and asset, I could easily reproduce the issue on my end in 5.6, 5.7 and ue5-main (5.8). I did notice a warning that smoothing group information was missing when importing the FBX file.

I searched the public issue tracker and UDN for any known issues related to this regression but could not find anything.

I have filed a bug report with Epic and will post the link to the public tracker here when it becomes available so you can track its progress.

Thanks,

Sam

Great, thank you for confirming and for filing the report.

Just checked on my side: re-exporting the mesh with smoothing groups doesn’t change the result.

Thanks for confirming that. I will post back here when I receive more info regarding the bug.

Regards,

Sam

Hi,

the issue is now public at this link. You can upvote the issue to raise its priority (although regressions are already treated as high priority).

Thanks,

Sam