lol ok I’ll try and give this another go as the last time I attempted some kind of explanation based on what “I” see as to why the ik bones were added in the first place “may not” be the same reason why Epic added them in the first place so from an animator perspective.
Technically speaking UE4 does not require that all characters “must” contain IK bones, better labeled as auxiliary end effectors, and are added, most cases by the animator during the authoring, to allow for two handed animations as well to fine tune contact points between different size character with out having to build a unique set of animations for a given player model.
If you check the hierarchy they are linked to each other with in their own parent child relationship that ends at the “root” nod of the main character rig and a constraint is used to fix their translation location to the same space as occupied by the corresponding joint. That’s to say where ever the joint moves so goes the effector but as part of the authoring process the ik joint doe not generate a key frame relative to it’s current position and to be useful, since UE4 does not support constraints, the animation data “has” to be baked as part of the exporting process.
To do this in say 3ds Max, and I’m sure other apps that support FBX, Bake animations in the exporter has to be checked which in turn forces all objects moved by a constraint to be assigned a key frame as to it’s absolute position. In MotionBuilder, which I’m sure a lot of the animations provided by Epic, the ik joints has to be added as a character extension so when the animation data is plotted the ik also receives absolute animation data.
Unreal 4 loves to interpolate “everything” so if you are attempting to do an aim off set for example the contact points of the hands will tend to float as it is now being drive as a procedural where the ik targets will remain relative to it’s position as authored as it is not part of the main hierarchy of the character. As an animator “Aux” effectors are nice in that we can key frame the “absolute” transform as to where the joint has to be for correct posing of the character relative to it’s contact points as “authored”. In other words our stuff is correct no matter what is done as a procedural in Unreal 4.
So no the short answer is ik joints are not a requirement of Unreal 4 but a requirement of the character rig design that can be used or not as part of the requirements of a procedural process done in UE4 to keep the players feet on the ground.
The actual how to has been rather confusing in it’s self as there are a few ways of say achieving things like floor constraints that has improved over time by using the 2-bone ik that can make use of the ik helpers as targets to realign contact points as a procedural but for the most part the addition of sockets has made the “requirement” for feet ik bones obsolete.
Hand ik’s are nice, but I wish Epic changed the name as it is confusing, and very useful for doing 2-handed stuff but once again is a character design requirement and not a demand of a must have being made by Unreal 4.
OK so how to fix the problem?
OK in general the ik, aux joints’ animations are broken between exporting from the source to Unreal 4 as they contains zero animation data so any attempts to fix it in UE4 is going to be difficult if it can be done at all. You can try retargeting the animation data from it’s corresponding joint that may or may not fix the problem as to purpose of use. To fix fix the problem the best practice would be to fix it at the source if you have it or export to FBX the animation data, patch in the require constraints, and reexport with bake animations checked.
Just some notes:
Epic has added a few nodes that can be added that does make use of their standard rig configuration.
In UE4.13 I believe frame to frame animation was added so you can now do the aimoffst cheat with out the need for a 2-bone ik.
If you are using the free animations from Epic’s market place they have a know problem as a perfect example of ik bones not being baked during export and I’m not sure if they have been fixed or not at this time. You can tell if this is the cas by viewing the animations in UE4 and if they do not move at all relative to the primary animations then they were exported unbaked.