# Inverse Kinematics

#62

I just wonder how to do correction to prevent too much of foot sliding…

#63

Well, i was trying to achieve this differently by timing lowest leg position and change animation speed to
minimize sliding.

You can find the support duration (window in distance of circumferential travel where you can IK pin the foot) as stroke/velocity beginning with the contact frame. Stroke is the distance between the two extremes where the foot is intended to be planted. The actual transfer duration isn’t realistic to find in real-time (have to build a Riemannian manifold or QEF it - either way means diagonalization [though QEF can be done in pre-diagonalized matrix form]), and probably best just left as “it’s everything but the support duration.”

If your legs are in perfect sequence, then you can use offset sine waves to weight the foot anchor (sin(x*PI) and sin((x+1)*PI)). It’s incredibly wrong but no one is probably going to notice beyond an uncanny feeling where they know something is off but they think everything is right (as speed increases support duration reduces to near zero with at 18mph a human runs as just slapping their foot to the ground).

Procedural walk loop looks so promising but I was not able to
get 60fps as it was too many calculations per frame…

Did you do that with the current IK stuff? FABRIK isn’t cut out for walking (neither is CCD), walking is Jacobian-transpose or spring-systems only (the squash-stretch of spring systems is glorious + trivial constraints). Walking also has to be solved from the bind-pose or knees will buckle reliably.

#64

Well, my idea was - I have linear walk (just classic dull walk cycle of 9 frames) and I selected appropriate frame
depending on walk speed, so I just changed speed of animation at real time. Frame drops to about 10fps
and correction is absolutely not perfect (visual sliding still present). It looks like I need to make some parts
of animation faster and some slower to improve effect and control speed at appropriate points, I can’t
just set some speed and hope for best
I remember old 3D studio (not max yet) had walk designer, probably that is what I miss most. Blender
is so much manual labor… On other hand i could use CMU mocap data and animate walk with
actual motion, and then compensate that, but I think there will be too many side effects
and animation will be locked to single speed. Also I wonder how this will work with RigidBodies…

About procedural loop - I thought not about actuall simulation, I thought about creating procedural animation
using some formulae and then play that animation. The actual animation might be done offline, like on game start or
even at production stage…

#65

I think the biggest problem with these walk loops is that we want walk as linear motion but the actual walk is not linear,
as it is sequence of almost-falls. So some trickery is needed to combine linear motion and walk, which I still
can’t grasp…

#66

If you know the length of the walk animation cycle and you know the player’s velocity, you can eliminate foot sliding by adjusting the animation speed. It really is that simple.

[quote=“JSandusky, post:63, topic:1819”]Did you do that with the current IK stuff? FABRIK isn’t cut out for walking (neither is CCD), walking is Jacobian-transpose or spring-systems only (the squash-stretch of spring systems is glorious + trivial constraints). Walking also has to be solved from the bind-pose or knees will buckle reliably.
[/quote]

Constrained FABRIK with stiffness factors can get you very close to what a Jacobian solver has to offer.

If it’s a 2 bone problem, then the algorithm is irrelevant, because the only axis of freedom is roll. All solvers (Jacobian, CCD, FABRIK, or even a direct approach using trigonometry) will deliver nearly identical results.

Overgrowth deals exclusively with 2 bone IK problems.

#67

@TheComet could you explain the idea for noobs/stupid people? I read everywhere about this can be done,
but I can’t find a way how it can be done.
The problem is that adjusting speed doesn’t really work for me for some strange reason

#68

I suggest you open a new thread about this so we can discuss it more in detail there. I also suggest you show some of your code so we can see what you’ve tried and where you’re having trouble.

#69

Constrained FABRIK with stiffness factors can get you very close to what a Jacobian solver has to offer.

No, it can’t. FABRIK also can’t cope with squash-stretch to sell a motion. I started with porting Caliko to C++ and abandoned it very quickly as spring-systems gave superior results for my needs of remapping animation that was designed for one morphology onto another entirely different morphology.

Your implementation might have some capability for that, but that would be unique to it.

Jacobi has the best fitment and greatest constraint support. Springs have the best behaviour and though constraints are slow to solve they’re trivial in implementation (just plot a quadratic or form a plane sequence upstream). When OpenCL’d they can be solved independently without consequence since they’re springs.

FABRIK is just a bad variation of spring-constraints, unfortunately it loses the desirable qualities of springs. I’m running IK for all animation in SprueKit, which is a Spore-Creature-Creator clone, I’ve been through all IK methods, springs are the only thing you can trust. Even Cholesky methods will fall on their face, despite the fact that they conventionally slaughter Jacobi. Cholesky is so close to right and stable that it’s disgusting that it could be wrong.

Springs really win when you have to solve 30k constraints per frame. That’s nothing. 240k constraints are still nothing. (OpenCL of course … CPU that’d be death)

Calling it a bad variation sounds worse than I mean, it’s good enough for most cases. It is not good enough for “I’m going to IK everything” like I do or “I want solid stability.” FABRIK is basically a tweaker.

#70

When you mention springs for IK problems, do you mean classical spring and damper system? For a more complex rig how would you choose k and d coefficients? As they would vary with the number of springs in the system.

#71

Yes, I solve for the coeffs from the mass (targeting a 80-120% for the extremes) since I’m able to calculate the volume and assume evenly distributed mass from there (some heavy cheating for arbitrary meshes since I require neither manifold nor closed geometry to merge into the dual-grid).

An Efficient Energy Transfer Inverse Kinematics Solution was the baseline where I started.

Before it pops up, when I mention Cholesky, I mean solving it all as one big linear system of equations constraints and all in some large matrices. It was really ideal, except that when it failed it turned into a twisted knot instead of something minor like knee buckling. (same deal as Laplacian handle deformation, just with more elements)

#72

Small update, I added specialised solvers that are optimised for 2 bone and 1 bone problems. This was requested by @slapin. They currently don’t take target angles or constraints into consideration, but I’ll add that shortly.

That is a neat approach. They don’t go into any details on the physical constants they used (mass, spring constant, or damping factor) so I’m left wondering how you’d go about finding optimal values for those and whether it depends on the system you’re solving or not. Obviously you want the system to reach equilibrium as fast as possible, which means minimising overshoot and minimising oscillation.

I see a lot of opportunity to apply control theory to solving this. Since it is an LTI system, instead of simulating the system in the time domain it might be faster to transform it into the frequency domain, where it would be a simple system of linear equations, and transform the results back.

Have you considered contributing your implementation?

#73

@TheComet
do you have plan to PR these changes yet?

#74

@TheComet

Hi! What is new about IK?

Especially I’m interested in sparse chains, where I could switch bones off participation
in IK chain. For example my leg consists of 4 bones, 2 for upper leg and 2 for lower leg,
which are used in animation in specific way. However for IK I want to just use upper bones
for both parts, so to save on solving (and have more realistic result). Do you have plans for this?

Thanks!

#75

You’ll have to make an example of what you expect to happen because I don’t understand what you mean.

It’s a bad idea to use IK for driving animation. You really should only use it for small corrections.

#76

We have cool image board here!

This is what I struggle with:

#77

I think some bone filtering won’t hurt.

#78

Oh OK, I see what you mean now. You want to combine multiple bones into a single bone and solve for that.

I can add that to the TODO list, it shouldn’t be a difficult modification to make. I’m just wondering whether this should be part of the IK lib or whether Urho3D should already take care of this.

#79

Well, I don’t think “other Urho” should be doing this. These bones are not useless - they are just not used for IK setups.
For some detailed animations (where IK is not used, at least not in all cases) these bones are very useful.
I don’t think skeleton changes for every animation are too practical.

#80

I think some method like IgnoreBone(int/String)/UnIgnoreBone(int/String) could be used
and just keeping array ignored bones. When travelling chain we just skip it and go for its parent.
Should not be too resource consuming…

#81

I’ve decided to tie it into the constraint system. There’s a “stiff” constraint you can attach to a node that effectively causes it to get ignored when building the chain tree.

The performance gain for this optimisation is pretty much negligible, at least in the case of constraintless FABRIK.