This problem has been around since iClone 8 was released....it still isn't fixed even now.....this is beyond ridiculous and you'll agree as soon as you realize what is causing it. The source is in fact beyond a shadow of a doubt Reallusion Software, I say that because this issue infects both iClone 8 and CC4.
62% of original size (was 819x19) - Click to enlarge

When you export for Unreal Engine if it were done correctly by iClone 8 / CC4 you would be able to import the animations back onto the skeleton that you imported into iClone 8 / CC4 and applied the animation to. However, this isn't the case as you can clearly see below

62% of original size (was 819x19) - Click to enlarge

Is Unreal Engine Doing This??? NOO! It's Reallusion doing this and I can prove it....Notice the '_0' at the end of each bone name....when you realize why you're going to come to understand just how ridiculously stupid this really is and you'll ponder why a programmer would ever think this was a great idea or how it would ever make it into Commercial software.

62% of original size (was 819x19) - Click to enlarge

As you can clearly see some programmer decided that if a bone name already exists.....duplicate and re-name it.....why they thought this was a great idea is beyond me. It's very likely the dumbest thing I have ever witnessed in my entire life.

The animation data gets baked onto the duplicated bones and the original ones are completely ignored...you can delete the IK Bones before you import it into CC4 but it's kind of hard to delete the root bone....meaning I'm kind of stuck here....I supposed a work around would be to open this up in blender and fix the animations after using iClone 8....but that kind of completely and utterly defeats the purpose of iClone 8 rendering it completely useless to me. I would rather not use iClone 8 if I have to deal with BS like this. I bought iClone 8 when it was first released and haven't actually used it but a few times because of the issues it has with Exporting for Unreal. The only times I have used it since I discovered that issue was to see if they would ever fix it and every single damn time I am greeted with the same dumb bug.

62% of original size (was 819x19) - Click to enlarge

Well....this may have something to do with the problem....I renamed the armature 'armature' it was named root, and it seems that CC4 is treating this as the root bone rather than the actual root bone which I underlined red.

Update: I was wrong, the one I renamed Armature is what Unreal Assumes to be the Root Bone. CC4 isn't messing this up, they are just adding an actual bone under the Root Bone and calling it Root_0 since the Root is already called Root

This is the bone heirarchy after re-naming the armature (from root to armature), applying the animation and then exporting it for Unreal Engine

And this is the original heirarchy that I imported into CC4:


Notice even after finding a fix for it the original heirarchy has been altered....making it incompatible with the original skeleton.

62% of original size (was 819x19) - Click to enlarge
A = Root of the Skeleton
B = The Skeleton

For some reason Reallusion Software thinks that when you export the animation for Unreal the Root should be an actual bone.

But Unreal Assumes ('A') is the root bone...so when they add an actual bone and call it Root, Unreal ignores that and sees it as a Duplicate bone. This isn't Unreal Engine at fault though....they have always done it this way. Reallusion should know that.

This is what it does when I export it for Blender....it adds a root bone....still ignores the actual root bone....all motion gets baked to the Fake Root bone and the Actual root bone seems to get Constrained to the Pelvis on the X, Y plane. It then adds an unnecessary bone and calls it armature for some dumb reason that makes Zero sense. Is there a reason they can't bake the Root data to the Actual Root Bone? There must be some serious issue their algorithm has with animation data being baked to the actual root bone if they are constraining the actual root bone to the pelvis and baking the actual root bone data to some fake root bone they shove between the Actual root bone and the Pelvis.

I get it...I see what is happening.....Reallusion software seems to be getting confused, someone writing this code must not understand how Software actually handles .FBX files. It seems that whoever wrote this code that exports these animations didn't actually know how any of this worked. That is the only explanation for the way these are being treated as bones

62% of original size (was 819x19) - Click to enlarge

Even when I export the animations with their own characters it does this....this is the exact same bug that I reported within 2 weeks of iClone 8 and CC4 Launching. They haven't even bothered to fix it, this just makes me so sick and angry to know I wasted all that money on useless software.

You seem to have misunderstood Blender's data structures and it's misleading you: (It gets confusing when they all have the same name)
e.g. for a Camila export.
62% of original size (was 819x19) - Click to enlarge

In this case the root bone here is CC_Base_BoneRoot.

So going back to your original heirarchy you brought into CC4:

62% of original size (was 819x19) - Click to enlarge

It seems to me that your real problem is that empty transform parent "SK_Zombie_Ai", CC4 interprets this as the root, which is why you're getting two root bones on export (because CC4 adds a "root" bone if there isn't one first) which causes the duplication renaming to root_0 which in turn causes all the animations to target the wrong bones.

Yeah I'm seeing that now. I'm not very adept at blender so I was getting confused. Thanks for the diagram. I did find a way around the issue though but it's more of a hack not an actual fix. This may be related to how they retarget animations though.

The rotation on the root I removed following these steps

1. Right click the Motion and Reset Pivot.
2. Go to Base Motion Layer and remove rotation from Root (This is always between 1 and 30 degrees)
3. Create reach targets on both feet and check Position and Rotation

This only really works for Non-movement animations where there is no motion on the feet but you may be able to use it on motion animations by carefully turning the Reach targets on and off at specific frames.

or it may just be related to how you pointed out that confusion with the root bone, but the problem is it's still doing it with their base character too.