Hello,
I am investigating inverse kinematics for the purpose of modifying existing animations of an attack with a melee weapon to change the place of the target that is being hit with the weapon. In short, I am stuck at a specific problem with Full Body IK (FBIK): it seems to assume that bone lengths are not changed by the animation (as has been discussed in [Content removed] Can this be somehow circumvented to instruct the FBIK to use the “bone length” as it is in the playing animation (at least for one specific bone); or provide the bone length as an outside parameter or something like that? Below is a detailed explanation why would that be useful for me. I am fairly new to UE so I would also welcome any suggestions for alternative tools I could use to solve my problem.
Simple prototype: I have added an ‘AnimatedHit’ bone to the skeleton. The attack animation has it placed at the point where the collision with the victim is supposed to happen, so it acts as a reference. When attacking, the game provides the world coordinates that are actually supposed to be hit. Let AH be position of ‘AnimatedHit’, DH the desired hit target. We could use the hand as the IK end effector and set its translation as dHand = (rHand - AH) + DH, where rHand is the reference hand position and dHand the desired position of the hand. That is “let’s maintain the same relative position between the hand and the target as in the original animation”. The problem is, this leaves the hand rotation the same as in the original animation. But as the target deviates further from the original place, the wrist will bend at increasingly unnatural angles. Ideally, I would like the angle of the wrist to be determined by the IK using preferred/limit angles, but that becomes kind of a chicken-and-egg problem as rotating the wrist rotates the weapon and therefore hits a different target…
So it would be better to have an additional ‘weapon’ bone, parented to the hand, that would be the end of the IK chain so the IK could animate the entire hand including the wrist. In the animation, we animate ‘weapon’ bone to be at the tip of the sword, i.e. the place where the contact with the target should happen. The formula remains basically the same, just using a different bone as the effector, dWeapon = (rWeapon - AH) + DH. But using FBIK in Control Rig led to an unexpected problem due to the way it handles bone lengths as mentioned in the first paragraph. The default length of my ‘weapon’ bone was small, but in the animation I have prolonged it to match the sword length. That makes the IK not achieve the target. By increasing “Mass Multiplier” it can achieve it, but only when increased to hundreds of thousands, so I feel that is not the right way to handle it. When I modified the ‘weapon’ bone on the default skeleton to have the same length as in my animation, it worked well. The problem is, we want to use different animations for different weapons and those weapons could have different lengths. So I would need to somehow support those changes of lengths. Is it in some way possible in FBIK? Could there maybe be some per-bone setting of Mass Modifier (if that would help)? Or the bone length, like it is in the Basic IK node? I have tried various animation retargeting modes (https://dev.epicgames.com/documentation/en\-us/unreal\-engine/using\-retargeted\-animations\-in\-unreal\-engine?application\_version\=5\.5\) but that does not seem to do anything for my case, which I think make sense, I am not retargeting to a different skeleton.
I have tried CCDIK for comparison and it does not have this issue, I suppose it is not using the bone lengths from the default skeleton. But using FBIK produces nicer animations as it allows us to also affect the legs (for example let the skeleton “sway” in the knees), which I presume is not easily possible with CCDIK as it works with a single linear chain of bones and the skeleton forks at the pelvis for each leg. Or am I wrong?
Thanks in advance,
Tomas
Hello Tomas,
Thanks for reaching out about your issue with Fullbody IK.
First off, Unreal’s Fullbody IK node does support animated bone lengths, but full translations may not work as expected. You can stretch the bone alone the vector to it’s parent but it may have difficulty if the bone translation is freely animated. Usually bone are oriented with X down the axis, so stretching in X is fine, but animating in Y or Z (skewing the bone) is not a behavior we have tested.
The use case you mentioned is a common use for full-body IK. But I would recommend that you do a little bit of extra rigging to help the IK solver. To help make this work, I would recommend the following approach:
- Create IK to the wrist only (not to the end of the weapon)
- Create a wrist effector control (with it’s transform plugged into FBIK)
- Parent the wrist control under a “hit target” control
Then at runtime, procedurally move the hit target control to the hit location you get from your game code. With the wrist control parented underneath the hit target control, the offset will automatically be maintained. The IK will solve the arm chain to align it with the hilt of the sword, but the sword may need to be aimed at the hit location. A combination of “look at” and parent constraints should be enough to get the sword positioned and oriented as needed.
This way, you leave IK out of the sword completely. You essentially need to position the sword where you want it and figure out where to IK the wrist by positioning the wrist effector at the hilt of the sword AFTER the sword is positioned and oriented as needed. This should be a more manageable solution.
Also you may find this article helpful to learn what the Mass Multiplier (and all other FBIK parameters) are for:
https://dev.epicgames.com/community/learning/tutorials/RByR/unreal-engine-how-to-tune-the-full-body-ik-solver
Kind regards,
Kiaran
Hi Tomas,
If you’re set on using IK to solve the full sword, then you would need another bone parented under the wrist which represents the tip of the sword. Then you could solve IK all the way to end of the blade.
But you will need different tip bones to represent the various end effectors for the various weapons you need to support. And each weapon would require it’s own FBIK node with a different effector bone. You could branch inside the Control Rig to select which solver to use based on a gameplay input variable that tells the control rig which weapon is being used.
At some point in the future we may update FBIK to support fully dynamic translations to make this easier. But for now it requires fairly static local translations to solve correctly.
I still think it may be easier to create a mini-rig for the sword that drives the wrist effector as a child with the pivot located at the tip of the sword. The “Aim” node in control rig could rotate this tip control to point the sword, backwards, at the hand then the IK could solve the hand back onto the hilt. Breaking up the problem into little sub-problems like this can often give you more control than trying to accomplish everything with a single FBIK solve.
Kind regards,
Kiaran
Hi Tomas,
I recently was able to run a test with FullBody IK on a skeleton with animated skew translations and it worked!
The solver should be able to handle translations just fine, as-is. I wasn’t sure because it’s not something we have tested much internally but with my recent experience I did confirm that it works. You shouldn’t have to make any modifications to the solver.
If you have issues with animated translations in FBIK, please bundle up a skeletal mesh FBX with an animation so I can take a look.
Thanks!
-Kiaran
Hello Kiaran,
we have just updated to 5.6. so I tried it again, but I still have the same result. So I am attaching an fbx with the skeleton (with weapon_r not matching the weapon) and the animation (which modifies position of weapon_r). I am also sending two videos showing the difference I get based on whether the weapon bone is defined at “correct” position in the skeleton and when it is modified by the animation; and also to show how I do it - maybe there is just something wrong in my workflow. Lastly, I have attached the control rig blueprint, though I am not sure if it will be possible to import. But it’s fairly simple and visible on the video I think (both feet with pos/rot alpha 0, weapon_r with the target, the bone settings are irrelevant for the problem).
Thank you,
Tomas
Hi Tomas,
Thank you for providing those sample assets. That helped a lot!
As it happens, this was in fact a bug in the Full Body IK solver. I have fixed it in UE5/Main, but unfortunately it would break ABI compatibility so I cannot push it into the next 5.6 hotfix. It will officially have to wait for 5.7.
But you are free to get the fix yourself from our github. It is completely self contained to the PBIK module inside the FullBodyIK plugin. There are two changes.
Change #1 (the main one):
https://github.com/EpicGames/UnrealEngine/commit/0057c35861223373af7c63dbb8e57edd4ab26975
Change #2 (a follow up fix):
https://github.com/EpicGames/UnrealEngine/commit/6b22e1541a88bf1e106282aa701c14f578ee30d3
To test this, I did the following steps:
- imported your skeletal mesh and animation
- created a control rig and imported the skeletal mesh
- setup a FBIK node with an effector on weapon_r
- connected a control to the effector and adjusted it with the mouse
- at this point, the solve is converging correctly
- in the control rig preview scene, I selected the included animation
- observe that the solve no longer converges (there is an offset betwen the effector bone and the effector control)
Then I applied the code fix, recompiled and reopened the control rig. Now it will converge correctly while playing back the animation!
Just a minor tip on FBIK setup. You can stop the pelvis from moving side-to-side so much by setting the Position Alpha X and Y weight of the FBIK’s Pre Pull Root Settings to 0. I also found it helpful to add feet effectors with zero position/rotation alpha. And tuning the mass multiplier to 0.5 loosened it up a bit.
But then it looked quite nice. The character would bend their knees slightly as needed to reach the target. Very cool!
Please let me know how this works for you.
Kind regards,
Kiaran
Tomas,
Thank you for confirming that the fix has resolved your issue. And thank for your patience as I familiarized myself with the underlying problem.
Wishing you the best on your project. It’s a pretty cool use of FBIK!
Cheers,
Kiaran
Hello Kiaran,
thank you for the reply, I’ll take note that skewing the bones is not going to work with FBIK.
As for your alternative solution with not including the wrist in the IK chain, unless I misunderstood, that is an approach I tried earlier but with only mediocre results. You say “A combination of “look at” and parent constraints should be enough to get the sword positioned and oriented as needed.”, do you maybe know of some articles/videos/examples where somebody used such approach with success? To me, this part - determining the position of the wrist (or the sword, it’s the same thing as the sword is rigidly attached to the hand) - seems like the hard part. I have full freedom in both position and orientation of the hand (and therefore the sword, as long as the tip of it hits the target), so there is an infinite amount of plausible solutions for the wrist transformation and of course I would like the one that looks the best, i.e. maintains reasonable angle limits for all the joints, while minimising angle and position deviations when compared with the original animation. And that seems exactly like a job for IK, so I would be solving one IK problem to be able to use the result as input for another IK…I suppose that might be a way - use a non-full body IK to solve a chain that uses the tip of the sword as effector and then use the resulting transform for wrist as input for FBIK. But from my experiments with CCDIK the position of the wrist will not be as good as with FBIK, so I would prefer to just solve one FBIK with the wrist included in the chain rather than being an effector.
Hello,
I think we will investigate both options. So one last question for the full body IK way: Let’s say we would like to implement support for dynamic translations ourselves. Briefly looking at the code, I suppose I would have to resize the bones stored in FPBIKSolver::Bones based on the length of bones in the animation when the animation starts (assumes the bone lengths don’t change thorough the animation) and re-run FPBIKSolver::Initialize, but then it should work? One issue I can see is that it will not be possible to blend two animations that use the same FBIK node without some extra work, but let’s assume the blend will never be needed. Apart from the implementation challenges, do you see some fundamental problem that would prevent this from working?
Thank you for your help,
Tomas
Hello Kiaran,
I finally got around to merging the fixes and indeed it looks like it fixes the problem, thanks a lot.
Also thanks for the advices, I’m not sure I like the pre-pull at full 0, but it does look better when I lower it; we will experiment and tune it.
Anyway, thanks a lot for your help,
Tomas