Automatically compute the Two Bone IK Pole Vector Joint Target

Development Character & Animation
1

I’ve been running into tons of issues with Janky elbows in my character animations when using the Unreal Mannequin.

I used to have my own skeleton and animations that came with elbow pole vectors but I migrated over the the mannequin so we can use all the market place animations. With that, I lost the ability to export out nice elbow targets and had to compute them automatically with Virtual Bones and other such things. I got the idea from how Advanced Locomotion System was doing knee targets.

It had problems where the elbow target was computed in one location based on how the arm was positioned earlier. And then when I actually ran IK on the arm the new position was not coplanar at all and the elbow would aim itself in some very janky directions.

I made this pull request to the Two Bone IK node that seems to work much better by automatically computing the direction from the current direction. I’m hoping people are really interested in this change and I can get this pushed in. It’s been hard these last few years to get Pull Requests looked at compared to when the engine first came out.

https://github.com/EpicGames/UnrealE…ull/7190/files

2

I think that the concern with doing this is performance cost.
maybe it costs nothing more then it already does. Maybe it costs way more.

I think that If you can provide the ue4 team with proof there is no added cost, you are much more likely to get this change into the engine.

It sounds like a cool method of adjusting common IK issues.

3

It’s just a little bit of extra vector math that doesn’t affect anything if using the normal method. The amount of work this actually does is negligible. All that’s really going on here is computing an orthonormal basis, which under the hood is a few cross and dot products.

There are ways to refactor this more but that would add to the lines of code which might scare them away initially.

4

Yea but if you have 2 dots and a cross extra the cost isn’t really “negligible”.

The solver relies on iteration count to return accurate positioning. As such even a single cross calculation adds to the load of the overall depending on how many times it is solved. The more you solve the bigger the load of a single operation becomes…

if you can escape those operations entirely by adding in a checkbox to either use or not use this way of solving it, I’m fairly sure you’ll pass any validation, since it becomes user choice…

6

The way I coded it should happen once before the solver even runs. Also TwoBoneIK doesn’t actually even use iterations, it’s just a simple triangle line side problem. I haven’t really made this work for the other IK nodes but it would work exactly the same. The pole vector can be autocalculated from the start and end positions once and be completely independent of the rest of the algorithm or how many iterations it takes.