Inverse Kinematics in Game Armature

Using Inverse Kinematics is essential to me for replicating realistic and consistent movement with arms and legs, and maintaining hand and foot positions as the main torso moves around. And works fine in animation and the game engine, but does start to drop performance when you have more than one armature.

When I have one armature with Inverse kinematics playing an animation, the animation is about at 4%, not much.


Add another and it increases to about 7%, But I plan to have more than just two of what I’m making, so I then make about 7 of them.


And I get 37%


Note that when I remove the inverse kinematics the problem is solved, but I would rather have the inverse kinematics.

Is there a reason the percent goes up like that? does inverse kinematics just take up that much? Or is there something I’m missing?

When adding more and more objects (or characters) you have to keep an eye on how much processing time you can spend on each single one of them.

Everything that needs calculation will eat processing time (that is why I recommend to avoid always + true level triggering).

On an armature there are a few factors that needs calculation:

  • each bone with an animation channel - while playing the animation
  • each constraint while playing an animation, or running the armature actuator
  • each vertex influenced by a deformation

Each single one might be really small, but they can will add up as you see.

I can’t tell how much processing time each single operation costs. I can’t even compare them without running a benchmark. But you need to care about.

When you plan seven characters, you most-likely will get leg problems. I did a demo in the past with lots of ManCandy characters walking around. You can find the demo in the thread BGE Guide to Character Setup (post#19).

There should be just one or two high detail characters. Typically you do not need more in a scene (e.g. for a dialog scene).

Medium level characters have much less animation details (e.g. they do not bow single fingers, no facial expressions) due to less bones.

Low level characters have only basic bones, no deformable skins and should appear pretty far away from the camera.

This way you should be able to have quite a lot of characters at the screen at the same time. You can introduce more LOD-Levels.

How about that?

  • High detail (with facial expressions)
  • Medium detail (average appearance)
  • Low detail (no deformation)
  • Static detail (static mesh)
  • Dot detail (plane with texture)
  • Occluded (no mesh)

Inverse kinematics is a complicated problem and it takes time for a computer to solve it. How many bones are you having the kinematics chain?

Four inverse kinematic chains, each with a chain length of two, for both arms and legs.

There’s LOD with armatures? Do you have to create different animations for each LOD level? Because it’s not the mesh complexity I’m having trouble with.

There is no build in LOD for armatures.

This is a demo that shows just one way to implement that feature. It basically replaces the complete object, while transferring the model status from one game object to the other (e.g. what frame is currently played).

This is no perfect implementation. You might notice that sometimes the initial pose is visible for a frame. You would need to solve such issues.

Due to the fact, that multiple game objects are replaced, you have a lot of freedom on the details. The goal has to be to have more processing time efficient objects on lower levels. This allows to have more of them at the same time.

You can have different actions. This makes sense when you have less bones. The appearance should be the same to allow a seamless transition (e.g. the walk-cycle should not continue with the other foot, or play with a different speed). In my demo I was able to reuse the actions on different levels. This is more an exception then a typical situation (but it reduces development effort).

This might sound like a lot of overhead, and it is. But it is worth as you can have much more characters in your scene at the same time. Make sure there are not many with high detail at the same time.

Btw. you can combine this with the build-in mesh LOD. Imagine you want to do a camera path from far away to the eye of your main character (or the other way around).

The good thing is … you can use this method right away. No need to wait that some imaginary developer adds a “crowd feature” (I really do not think that will ever happen).

monster, add duplicate actor invisible and show next frame and remove old level object next frame, this way there is no ‘pop’

also what about using FK on distant actors and Ik up close?

ps you can articulate a spine using an x and y value and get away with most of the other actions to be FK using copy rotation constraints and euler offsets…

This is a way, but not an efficient one as you will get two detail levels at the same time. I leave this open for whoever want to use such a system.

It might be worth to benchmark this.

This still sounds processing intensive. Again, running a benchmark can compare it vs. IK.

ik is an iterative solver where as copy rot is not and the spineoffset uses a tiny bit of logic

https://wiki.blender.org/index.php/Dev:Source/GameEngine/RobotIKSolver

TL;DR
select armature and go>Properties>Data(stick man icon)>Deform(set to bge)>Inverse Kinematics(iTaSC>animation… or simulation?)

and also remember as well to uncheck the “deform” to bones, the ik targets for instance, that are not used to deform the model directly

READ
Besides the aforementioned, the link above also covers how to switch the IK off with the armature sensor and actuator but I find it cumbersome and just use a property sensor callback to drive the armature instead, so the armature shuts off when I stop moving

iTaSC simulation are the fastest ik solver in blender and were developed for solving real life robotics problem, but they are really REALLY hard to get right(if ever), as the simulation can deform your armature in real time, often leading to really REALLY funny outcome

I think* I can even make a physics based gameplay like besiege in bge with iTaSC… if I ever had the time… and money… and will… and a girlf… nvm

my humanoid characters uses 4 “iks” and 4 “copy transform”.the difference wit hor without constraints is:0.1 / 0.8 msif you use IK to create animations baked in blender you can use visualLocRot, and then remove all constraints in the first frame(for i in arm.constraints: i.active=False)