euler order mismatches between Blender, Unity, and Unreal have cost me more hours than I want to admit

the silent axis mirror is genuinely the worst part of this whole mess. FBX exporters often handle the handedness conversion by negating a scale component — so the mesh looks completely correct in the viewport, but the actual bone transforms in code are mirrored. if you're doing anything procedural on top of the animation data — IK solvers, reading bone world positions for VFX attachment, ragdoll anchor points — you're getting subtly wrong results and you won't notice for a long time.

had this happen on a project where foot IK was placing the left foot very slightly to the right of where it should land on uneven terrain. looked almost right. someone pointed it out three months in.

knowing all of this and still getting burned every few months is apparently just part of the job. the thing that actually helped me was making a habit of exporting a simple arrow mesh pointing in world +X from whatever DCC i'm in, importing it into the target engine before touching any animation data, and verifying it lands where i expect. 30 seconds, saves multi-hour debugging sessions, should be step one every time.

also blender's fbx exporter has an "apply unit scale" checkbox that interacts with axis conversion in ways that feel completely undocumented. unchecked it once by accident and spent two hours convinced my euler order was wrong when it was actually just a scale mismatch warping the rotation display.

Not the original poster but I've got something similar. Fires as an AssetPostprocessor on every FBX import and flags bones with near-180 rest rotations:

using UnityEditor;
using UnityEngine;

public class BoneRotationValidator : AssetPostprocessor
{
    void OnPostprocessModel(GameObject root)
    {
        foreach (var t in root.GetComponentsInChildren<Transform>())
        {
            var euler = t.localEulerAngles;
            bool suspect =
                Mathf.Abs(Mathf.DeltaAngle(euler.x, 180f)) < 2f ||
                Mathf.Abs(Mathf.DeltaAngle(euler.y, 180f)) < 2f ||
                Mathf.Abs(Mathf.DeltaAngle(euler.z, 180f)) < 2f;
            if (suspect)
                Debug.LogWarning($"[BoneCheck] {t.name}: suspicious rest rotation {euler}", root);
        }
    }
}

It won't tell you why a bone is wrong, just surfaces the ones worth double-checking. But it's caught a few bad FBX imports before they made it into the project and caused problems we didn't notice until later.

I'd also make the test mesh show both forward and up, not just forward. A box with a bright green top face and a red front face tells you both axes at a glance. I've been burned by an arrow that looked correct in the target engine but was actually rolled 180°. I'd fixed the forward axis and introduced an up-flip in the process. The two-color box catches those combinations instantly where a plain arrow won't.

the handedness flip on top of all of this is what broke me the first time. blender is right-handed, unity is left-handed, and even when you nail the euler order you can still get a silent axis mirror. spent an entire afternoon convinced my FBX export settings were broken. turned out it was just a Z-handedness flip the whole time, exporter was doing exactly what it was supposed to.

the fact that axis mapping, handedness, and euler order are three completely separate things that all compound on each other is just cruel.

would you mind sharing that script? catching cases where a bone ends up with 180/0/0 vs 0/180/0 at import time sounds really useful. those two are visually identical at rest but the keyframe math downstream is completely different, and that's exactly what bites me on more complex rigs.