Retargeting abd IK bones

Hi There,

I got the retargeting process for my characters to work pretty well except for one last bit.

The IK bone’s don’t want to end up in the right positions.
None of the bone retargeting methods (anim, anim scaled etc) seem to work.

Should this actually work?

You can see here what happens to my model (big legs)
EDIT: My target character is about 3-4 times as large as the source character.

When I’m checking out the Unreal tutorial it sort of looks like they might not get the IK bones either?

Any ideas?


Well the IK bones as part of the mannequin are not part of the actual hierarchy but are constrained to the host joint with in the edit app, except for being parented at the end to the root, so there may not be any animation applied depending on how the animation was exported, considering that UE4 does not support constraints.

In general the ik bones for feet are no longer required and left in for possible legacy issues and is not unusual to come across animation packages that do not included them as part of the animation data and as long as the ik for the weapon and hands still conform to the character animation they can still be useful for a given purpose.

To match up the ik though, and assuming as I do not retarget in UE4, you could try retargeting the animation from the host joint to the ik target rather than the ik from the host that may or may not contain animation.

Hmm…in this case the source mannequin does have the ik bones as part of the skeleton joint hierarchy. But Iv’e been thinking that maybe it just does not know how to scale the end/leaf joint locations/translations to fit my larger character target skeleton?

When you say that foot ik bones are no longer needed, how so, what’s the alternative?
I am definitely needing them in my vr ik rig to replant the feet on the ground after player body/hmd input has pushed them below the ground and sideways.
Maybe there’s a easier way to do that without the foot ik’s?

Cheers, Fred

Wait what? Why are foot ik bones no longer required? And hand bones? Are they still required? How so? How do you make ground interaction with feet these days?

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.

So why?

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.

Wow thats a lot of text m8, thanks for the detailed explanation.
Ok, so you are saying Ik bones are required in the skeleton hierarchy per-se. I knew that, my old skeleton didnt have them, and I never missed them. But if you want to do procedural foot alignment to the floor you still need them. I knew that too. My new skeleton now has those included and the retargeting tools i wrote take them into account.

Tho I still dont quite understand this:

For Paragon they attached sockets to those bones and did all sorts of cool things with them, like speed warping where they scaled motion in xyz by a certain amount to control the step length based on movement speed (so that the playrate of the anim can stay in a natural range). They way I understand this is you add a socket to each Ik bone (which is only there to be the handle driver for the Ik). Then the handle gets connected to the socket? How would you do foot ground contact with sockets but no foot ik bones?

How does IK bones help at ground contact? They are just part of the anim sequence and have no clue if the ground is far away, if there is a step below or if the hole character is flying in the air. The only way I know how to get proper ground contact is via linetracing the ground below your feet to get an IK target location. But you don’t pull the IK bones to that location. They don’t deform and don’t have weight. They are just targets and you have the target location already from the linetrace. You don’t have to trace from IK bones to find the bottom. But probably we speak about different things. I mean groundcontact like it’s done here:

I’m even not sure how IK bones helps at weapons. Rifles have variable lenghts. So it’s usually more accurate to get your target location from some weapon socket or by dragging a target point based on the other hand ( ) then to hope that the animation would carry your weapon (that might differ from the weapon that was used to capture the anim) the right way. If I get my IK target location from the weapon itself then it’s usually more accurate (short rifle, longe rifle does not matter as well blending in the aim-offset) then guessing a grabbing point via the animation.

Uhm, yes you do. How else is the line trace gonna get its X and Y coordinates per foot? Thats what the IK bone does. It has - as you already said no weight on any mesh and only follows the animSequence for its respective target bone. Thats then the source of the Trace so that the actual leg bone can then be offset via IK. And potentially move the hip too if required.

Edit: Or can you trace directly from the respective foot bones without creating a dependency cycle for the IK?

No I’m saying they are “not” necessary as demanded by the Unreal 4 engine as part of any procedural requirement as what you want to do as far as maintaining proper contact points can be done using sockets. The flip side is if you are cloning the same process that Epic has done as far as their character requirements for a game called Paragon then you could take advantage of some of the few features they added to the engine that can take advantage of these “auxiliary” bones.

At the moment they are more of an annoyance than anything else and are unique as to requirements for games produced by Epic but if forced to use them then all sorts of problems would be crated and our character design does not use them in any way and if force to included them would only create more problems to deal with.

Humm well the confusion once again is calling the bones IK to begin with which suggests by translating the “IK” bone the rest of the chain would follow the IK effector as it would in any other animation rig using IK. As imported UE4 does not support IK chains or constraints necessary to make an IK chain work and as an auxiliary bone can only reference joints local to the character as imported.

Speed matching there is a few ways of doing it depending if one is using in-place or root motion. I won’t get into root motion as it’s a totally different toy but if in place then you can change the speed of the character model by referencing the speed of the capsule it’s bound to and in this case the “aux” bones would be helpful in referencing the different gates required between different size characters.

In a past twitch cast though it was said that Epic no longer uses the feet IK and left in as to any legacy requirements so unless that has changed I would need to see the info.

First there is no way that the rig as imported will be able to reference the ground and no way to know if the left or the right foot is actually planted and needs to be constrained so they have to be added after the fact and the most common way of acquiring the reference is by line tracing as suggest above some place. Once you have the ground reference, like flat ground surface, ladders, stairs, ramps, you can then add an IK solution available in Unreal 4 that does not even require the use of the IK bones or even the use of sockets.

Your choices are

Hand IK Retargeting
LegIK (added in 4.14 that does more than two bones)
Two Bone IK.

Once applied then and only then will your character rig contain any kind of usable solution applied to any kind of end effector that will drive the included bones in a manner as expected from a true IK rig.

Sorry that this is all still confusing but from a “game animator” perspective if it looks like a duck, walks like a duck, quakes like a duck then it’s a duck and in no way as imported will this duck, I mean IK handle, behave in any way as to a duck called IK. :wink:

P.S. I think I’m going to rename all of my (cough cough) IK handles to Duck_<name>" :smiley:

D!amn*, now im even more confused -.-. Alright whatever, since you seem to know your trade: whats your preferred method for foot-to-ground [somethingsomething] make the feet align to ground and stairs. With hip pull when needed.

PS: *(this forum really censors that word -.- “no blasphemy”. you guys are broderline ridiculous about this stuff, srsly)

OK I’ll give it a go, from at least from an animator perspective, but keep in mind that character development can go from simple to complex faster than a Ferrari can go from 0 to 60.

OK from a usability stand point IK is nice in solving simple requirements but are overburdened when attempting to preform actions as a procedural rather than done as part of the animation asset. Running up a set of stairs for example is asking for a lot of things to go wrong by forcing the character into position that an animator can do at the source level as in the character running up some stairs over a cup of coffee and a donuts.

The problem is not the stairs but the lack of the character, so to speak, to be aware that the ground that is being referenced is in fact a set of stairs. It’s called object awareness and if this awareness is available to the animation BP as part of the animation migration the path can be change to the player running up some stairs.

To finesse the action IK is then used to target the IK solution with in a fraction of units as compared what would be required to pull the character down at the hips to the level necessary to make the steps.

Same thing for keeping the players foot grounded as for achieving the perfect run cycle the inplace animations has to be back keyed to counter the constant forward velocity of the capsule that it is bound to. There is a solution to this effect, I’ll get to in a moment, but the root problem is constant velocities that has to be countered at the source and if done right complex design additions like IK is not required.

Keep in mind when IK should be turned on and when to be turned off is still a problem to deal with.

So first part of the solution is to give your character enough of a brain that it’s aware of it’s surroundings as to object awareness and if you know what the object is the solution can in most cases be built into the animation source to get you 99% of the way to where it needs to be.

So long way of saying get your environment to help out as to what is needed when and where and the easy way to do this is by adding a simple physics material, once again confusing name as it does nothing as far as physics goes, to your material assigned to a set of stairs.

We use physics materials for our ladders and anything we apply it to the player will climb, including a wall.

OK to back track a bit. As an animator for video games having to deal with procedural solutions and constant velocities suck as you generally forced into animating something that looks bad to make it look good but the solution to it all is the introduction of Root Motion in UE4.


RM does not play well or even all that compatible as to network requirements so best used in games that does not require multi-player connections…at the moment.

Since movement is built into the animation data set the feet will never skate across the ground reference and the velocity fidelity will be maintained as authored.

For the most part problems can be solved at the source level and in the case authored animations, or even single frame posing, which is not that helpful if you don’t have the tools but is a requirement if you want a slick result and avoid using procedural solutions as a twenty pound sludge hammer.

For me down trace is not an option as I need to know where the feet should be sideways in the ‘ground plane’, ie x and y. To be able to send the feet back to their original positions after the player arbitrarily moves the hip around using their VR HMD.
Early on I bumped into that problem but I couln’t find out a way to do that in the animation graph. So IK feet bones it had to be.

It’s a shame that these cannot be retargeted as now I have to take each animation back to Maya to re-do the ik foot positions.
They could have done it if they wanted, just needs to copy position and location of the joint the ik’s are supposed to be linked to.