I have an issue where I have a set of locomotion animations, and within each of them, we have ik_foot_l and ik_foot_r animations that follow the feet within each animations. The issue is that within a blend space, these joints are blending out of wack significantly, to where they are way off from where the blended location of the foot bones are. Here is a video to show what I’m talking about.
Anyone know what is up with this? The same thing happens if I set up virtual bones for this as well.
The IK bones are free floating as in the set up in the application being used to animate they are there to assist the animator as an auxiliary effector and as part of the set up needs to be constrained to the desired joint but linked through the hierarchy to the root bone. To match them up to the feet you will need to bake the keyframes as an absolute so that their location is the same.
If not then the key type assigned in the authoring application will be different as to the key type imported into Unreal 4. Depending on the application setting the FBX exporter to Bake all key frames, as long as it’s correct in said app, then it’s transform should be equal to the joint that it’s constrained to.
Motionbuilder solves this problem by plotitng the joint to the time line.
Why it’s doing this in this case I don’t know or why you need the IK in the first place?
If you blend at 50% something at
0,0,0 and something at 0,0,60
You get 0,0,30.
That may not be where you expect it to be compared to the foot, since it has no frame of reference like you mentioned (also it’s happening as a calculation for every bone at every frame, so the example is ■■■■ poor…)
Put it this way. If you blend walk slow and walk faster at %50 - assuming it’s the same cycle and they start on the Opposite leg - what do you get?
Hopping.
Or not even that, just both legs floating ahead…
Either way, like you said the solution to the pure animation would be proper parenting.
and - the bone visualization you see doesn’t necessarily matter.
You have to snap the foot to the Ik bone and see what the actual result of that would be.
Another fix - the lazy one - is to just use ABP to copy the IK bone location to the foot bone.
This works too.
I just don’t like it because it’s extra xomputation.
The ik foot bones follow the feet exactly in their respective animations. This seems to be a common approach recommended in quite a few UE tutorials for IK setup. The ik foot bones are not under the parent but rather an ik root bone, but because they have been keyed to the animations in Maya or whatever, or inherit the motion of their target bones via a virtual bone, they can be treated as if they were children.
The puzzling thing is that given the prevalence of this setup, it seems like there must be something that our setup isn’t doing that presumably works fine in other situations, or this type of setup wouldn’t be viable at all. That’s what I’m trying to understand.
I mean clearly the blending is not playing nice here, but surely there are circumstances it would or this would not be such a popular way to set up ik
Depends.
Its probably just as simple to force a copy bone while a blendspace is active.
The reason that the positions do not match is likely to be several.
the retarget skeleton settings are probably bad.
You only get the same exact position if everything is set to animation scaled. - or one of those animation driven options.
Otherwise the animation you import is already not 100% the same when applied to the mesh.
the root of the IK could be moving between the 2 animations causing things to go bad.
(I don’t reall if IK has a root bone for overall, but you can totally dump that bone. Just parent the bone to the foot directly. The root ik bone is nice for other stuff - but, but you can live without it [if you don’t need marketplace compatibility or what not with the epic skeleton]
the engine could be wrong - the root motion was working on a wrong axis just a little while ago, so it could totally be part of that issue or something completely different but still related to a bug.
engine version. Because see #3
bad positions of the IK bone in one or more of the frames of One animation.
Can only tell you how may dannn times it turned out to be 5, where you go scratching your head for a day and then you realize something stupid like… the engine is importing a file that’s 3 days old and not the one you were exporting out…
The video above shows the ik bones accurately follow their target bones when the animation is played by itself. Error is only introduced during the blends as you drag the blend space away from one of the animations. Just to rule out bad animation data, I tried the same setup with a virtual bone, whose entire purpose is to follow a target bone without being a child of it and the same problem occurs.
This is in 4.26 BTW if that matters to anyone.
I will confirm again, but I don’t believe the epic skeleton exhibits this issue even though it has a similar setup of an ik root and ik foot bones under that.
Ok so the AnimStarterPack and Starter content doesn’t animate the bones with the feet at all, even though it has them in the rig this way, nor does it even have IK set up.
There is a marketplace katana set that uses the epic skeleton that does animate them with the feet and it exhibits the same issue where the IK bones are off. It’s a bit more subtle in that case though, because it has 45 degree locomotion increments, so there is less room for the blends errors to accumulate as in my 4 way example.
I guess this is just sort of an imperfect approach for setting up IK. Thinking maybe a control rig is the more appropriate place to do IK in a more reliable way.
The bones being animated saves you a very small amount of computation.
I have it running fine in .25 with animated stuff.
You can actually pass the animations though my plugin and the IK bones will be automatically animated for you in the final export. http://mosthostla.com/gamedev/bonebreaker
The IK itself is another story.
Control rig is easier.
Oldschool is more math but requires less computation.
Pre or Post physics may be a concern when paired to physical animation.
I think control rig is all post everything. Computations too.
Acrually, I’d use control rig for full body IK (slide on the floor alla Snake Eater)
What about the other options, particularly number 1?
What’s the IK bones retargeting option set to on the skeleton?
True but using a blend space is an index as to the home position to blend into. By default the bs does not blend across the space but rather eases into and out of the take at the point with in the index. Scrolling across the bs of course the IK would float.
The exception is aim off set where the blend occurs across the bs from point to point that usually requires the left hand constrained to the IK joint to prevent the weapon from floating. There are tricks “now” where floating of the hand IK could be prevented in 4.26 but more or less feet IK is no longer used in UE4.
Basically they are still there as a legacy to UE3 but with things like sockets and auto rigging there is no need for them unless your authoring your own animations and are still useful as part of source asset development.
As you state though there are many reasons as to why and more important than finding out the fix it’s perhaps better to know the different reasons so it can be fixed when spotted?
Doesn’t matter if you use retargeting or not.
The engine does whatever the f*** it wants.
Look up the skeleton retarget settings. See what they are set to. See what changing them does for the blendspace.
Most of them are the engine doing what it thinks you want it to do. Poorly.
I guess that’s why being a “character animator” is a profession though, right?
As far as the AO - they use a different (but similar) process under the hood.
As far as the IK bones.
Tbh, I mostly use then to place Items and animate them.
Foot ik bones are actually perfect to bounce a ball around the animation. Just socket it to the bone and animate it however you want without needing to add additional bones, change the skeleton, etc.
It’s also super useful for reloads that require a foot (crossbow) but are dynamic in nature (length of cross bow is variable).
I usually also add an explicit Hat and an explicit Item bone just to have - the hat one particularly as you can then use it with creative weight paint to move the cap (or part of it, like the helm visor) up and down.
We digress from the OP’s issue though.
It’s kind of impossible to know the exact reason without looking at the setup and trying things.
And just because it works for me out of the box in .25 with custom animation and proper skeleton settings does not mean it would work in .26.
You’d be hard pressed to see the difference when it’s running anyway.
The point of the IK is that it toggles on/off gradually with the steps.
Because it’s gradual, you won’t notice it being “off” when it’s active.
