Page MenuHome

Importing an fbx skeletal mesh from Blender into Unreal Engine 4 results in bones being too small to create Unreal physics asset. Requires scaling workaround.
Confirmed, NormalPublicKNOWN ISSUE

Assigned To
Authored By
Adam (darkpivot)
Dec 22 2015, 8:13 PM
"Heartbreak" token, awarded by Ghostroots."Love" token, awarded by StrictlyIncreasing."Heartbreak" token, awarded by wahooney."Heartbreak" token, awarded by madminstrel."Heartbreak" token, awarded by marcomaryred."The World Burns" token, awarded by semaj."Like" token, awarded by Positivity."Like" token, awarded by Xazen.


System Information
Windows 10
Nvidia GTX 970
Intel i5 4690k

Blender Version
Broken: 2.76 48f7dd6

Short description of error
When importing a skeletal mesh into Unreal Engine 4 that was exported as an fbx from Blender 2.76 with default settings (or modified, it doesn't matter), Unreal will return an error stating that the bone size is too small to create a physics asset for the skeletal mesh. My work around was to scale the mesh and the rig in Blender to 100x, apply the scale, then scale both down by 0.01x, and apply the scale to only the mesh. Unfortunately, this would break the mesh visually in Blender, although it would import into Unreal Engine 4 perfectly. I would have to undo the scaling after the fxb export in order to work with it again.

Exact steps for others to reproduce the error

  1. Export with default fbx settings.
  2. Import into Unreal Engine 4 (I used v4.10.1). Make sure to select "create physics asset" in the import settings.
  3. UE4 should return with error saying bones are too small.
  4. In blender, scale mesh and rig x100.
  5. Apply scale to both.
  6. Scale mesh and rig to x0.01.
  7. Apply scale to just mesh.
  8. Delete previous fbx import from UE4.
  9. Export fbx with same settings as before.
  10. Import into UE4 with same settings as before.
  11. Physics asset should now be created.

Event Timeline

Adam (darkpivot) raised the priority of this task from to 90.
Adam (darkpivot) updated the task description. (Show Details)
Adam (darkpivot) added a project: BF Blender.
Adam (darkpivot) edited a custom field.
Adam (darkpivot) added a subscriber: Adam (darkpivot).

Hrmfff… Honestly, I’m beyond tired of those scaling issues, and of having to guess FBX crapyness out of a blackbox in general. FBX seems to use a global scaling model at least as complicated as its transform model - that, and/or nobody actually knows how to use it. So I’m horribly tempted to answer "go convince Autodesk to publish clear FBX specs", since this is the real bug from the beginning… :/

I might have an idea about what happens here… Issue is, in Blender, a mesh object deformed by an armature is a children of that armature (i.e. it inherits its scaling), while in FBX mesh and “armature” (chains of bones in fact) remain independent, which means (wild guess) both get scaled by global scaling before being bound. Or something like that…

Anyway, will try to have a look at that, when time and will allows…

Bastien Montagne (mont29) lowered the priority of this task from 90 to Normal.Dec 22 2015, 10:54 PM
Brendon Murphy (meta-androcto) changed the task status from Unknown Status to Unknown Status.Mar 5 2016, 5:01 AM

No activity here. Archived.

Bastien Montagne (mont29) changed the task status from Unknown Status to Unknown Status.Mar 5 2016, 6:48 AM

Please do not archive those, they are known valid issues, though it is unclear where the problem is… I may not be keen on spending time on this PoS of FBX currently, but better keep reports open still!

Dennis Lieu (Xazen) added a comment.EditedMar 28 2016, 11:22 PM

I have the exact same issue with 2.77. Thanks Adam for pointing out the workaround.

Just adding a few more information:

The skeleton looks correct in UE4 after importing even when the fbx was exported without the workaround. The asset can then be exported as in fbx using ue4 an reimported to get the Physics Asset.

I have the exact same issue with 2.77. Thanks Adam for pointing out the workaround.

Just adding a few more information:

The skeleton looks correct in UE4 after importing even when the fbx was exported without the workaround. The asset can then be exported as in fbx using ue4 an reimported to get the Physics Asset.

This workaround doesn't work for me. When I reimport after exporting from UE4, the skeleton comes back completely collapsed into the origin. Any ideas??

Hi Bastien
I have the same issue with Blender 2.78a and UnrealEngine 4.13.2. I debugged Blender fbx export code and UE4 fbx import code, print out all matrixes and some variables' value, the problem seems to be clear now:
Reproducing Steps:

  1. In Blender, Set UnitSettings.system to "None", or Set UnitSettings.system to "Metric" and set UnitSettings.scale_length to 1.
  2. Install ManuelBastioniLab add-on, Init a character.
  3. Export to fbx, choose 7.4 binary format, -Y forward, Smoothing by edge, uncheck "Add Leaf Bones".
  4. Import the fbx in UE. UE will show popup "bone size too small" warning.

What happened in Blender:

scene_data.settings.apply_unit_scale is True
scene_data.settings.global_scale is 100.0
units_blender_to_fbx_factor(scene) returns 100.0
scale_factor = scene_data.settings.global_scale / units_blender_to_fbx_factor(scene) = 1.0
The scale vector of global_matrix becomes (100.0, 100.0, 100.0)

So all the transform link matrixes in the bind pose will be scaled by 100, and the UnitScaleFactor writed to fbx file is 1.0.
What happened in UE:
UE uses the bind pose in fbx to construct the bone info and calculate the bone size, transform link matrix in bind pose will be converted to local space matrix( the bone position in parent space), this matrix is used to decide the bone size . Due to the 100.0 scale applied to transform link matrix, bone size will be scaled to 0.01 of original size.
For example:
The transform link matrix of the root bone, M1:

T:    0.0000   -0.0328    4.8141    0.0000
S:  100.0000  100.0000   99.9996    0.0000
R: -171.2535    0.0001 -180.0000    0.0000

The transform link matrix of the pelvis bone, M2:

T:    0.0000    2.0537   80.5642    0.0000
S:  100.0000   99.9996   99.9999    0.0000
R:   73.1802   -0.0000  180.0000    0.0000

The Local space matrix of pelvis bone, M3 = M1.inverse * M2:

T:   -0.0000   -0.0946   -0.7519    0.0000
S:    1.0000    1.0000    1.0000    0.0000
R: -115.5664    0.0001    0.0000    0.0000

The Z-axis size of pelvis bone should be 75cm, but it is shrinked to 0.7519cm.
I can upload the code and full log if necessary.

@Bastien Montagne,
My issue is when exporting armature assets as .fbx from Unreal Engine to Blender, the bones sizes, orientation and look comes wrong.

Exporting from Blender to Unreal Engine works fine with me 90% of the time unless morph targets are involved

The issue is with all releases of blender 2.8 and 2.7X

@Bater Janjatah (Bater) ack sorry, read that one the other way around… Guess your issue is closer to T53620 then.

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Known Issue".Feb 17 2020, 5:07 PM
Bastien Montagne (mont29) edited projects, added Python API; removed Tracker Curfew.

Hello, I've spent two days trying to fix my physics asset, before I've discovered this culprit. I've spent today trying to fix it from Blender. No matter the configuration (scaling in UE, in Blender, apply, don't apply... ), the error will always be there.

The possible workaround doesn't work for me, since the "apply scaling" breaks my whole rig (that might be something on my part). Even if it would be possible to do so, it's not a comfortable workaround in any way, shape or form.

What can I do for this to have a higher priority? Is there a chance of someone fixing it?

I am having this problem as well and it is driving me crazy for several days. I have narrowed down some of the issues but not the solution. The re-scaling solution does not seem to work for me.

Am I supposed to scale up the parent rig + the mesh inside? When I scale up the parent rig it's ok. When I then scale up the mesh, it appears waaaay too big because rig is getting 100x scale and then the child within is getting another 100x scale. But supposedly if I import that into UE4 it should be ok? But it's not. Do I need to apply the transforms first? Am I supposed to scale the armature and mesh from edit mode or object mode? Doesn't seem to make a difference. The physics asset is always generated incorrectly and it comes down to this issue of asset scale.

Really should be easier to enable ragdoll effects on a rigged character. Part of the trouble is, I suppose, "is this a ue4 issue or blender issue?"

Really frustrated because I've been over the checklist and over it and nothing seems to work properly, I end up with a ragdoll that just sort of explodes into a mess of polygons. Every tutorial about setting up ragdoll physics uses the UE4 mannequin and not a custom character + rig.

While this may seem to be an edge case, it does seem that "No one on the internet can demonstrate setting up a rigify rigged character and exporting that to UE4 for successful use with ragdoll physics". Would sure be nice if that video existed somewhere on youtube. Maybe it is a UE issue really.

I made a video demonstrating the issue and then outlining things I've tried, including recommendations from this thread:

I apologize for the length but the issue is explained in the first 5 minutes and the rest is me troubleshooting in vain. Hoping I can make a follow up video on how to actually do it because I'm really scratching my head on this one.

This task is 6.5 years old. Maybe fixing the fbx exporter isn't possible with the licensing issues as they are. What about a hack export to Unreal option that very specifically modifies the animation data for Unreal exports so that the armature isn't shrunk?

Not sure if this is related, but way back around 2012 when exporting from Maya to Unity, we had to export in centimeters because meters was bugged. If we exported in meters, the skin would come in at the correct scale, but the joints were 1/100 the size. It didn't express exactly the same way as this, because the skeleton no longer lined up, but similar enough that maybe it hints at some underlying foible of the Fbx format.