Adding IK to jME

So it seems I got things wrong when i started with jME and you don’t yet have IK at this stage.

So this is a FYI that i wish to add it. I am working full time on my game dev so I am expecting to sink a bit of time into it. However after a few prototypes and math i am fairly confident that a fairly useful IK shouldn’t be hard. I expect perhaps a week or so for a first version (alpha) (btw math and stuff in code was my day job).

Now i guess i could add this to my own project and just have a IKControl that i don’t share. However i wish to integrate it with the blender importer. Hence my desire to add this to jME. This also means more users and more testing (I hope others will use it), win win and all that.

The idea is that blender(Read any import that supports the same bells) is still the rigging skining tool etc. and all important information is imported. Add a IKControl and then a control that moves the IK chain targets however you like.

So I would love to here from the Devs with any perls of wisdom. Do and do not’s, warnings etc. I have used git a bit and git hub so no problems there.

I expect to start on this tomorrow or Friday…

EDIT: I will be using the FRABRIK method with limited constraints. Even some blender gold like copy rotation, stuff like that.


With IK rotation constraints like in joints is a pain. I did one a long time ago for a Unity test project and it made me study quaternions more than any other project

1 Like

I do maths. IK constraint maths is pretty straight forward. I don’t expect that to be an issue. Issues will be having things work in a practical way without getting in the way. Devil is always in the details.

The constraints I am putting in, is single plane joint with angle limits, ball socket joint with angle limit. Free joints. And Roll constrained joints (roll travels over joint). Copy rotation etc constraints are not really IK but will have that as well as things like point at (can’t remember the blender name for these things)

Also the FABRIK method is quite a bit more mature now, much easier to implement than Jacobin methods, and generally more stable and natural.

respectful silence
ok you’re hired, you’re now officially the math guy.

Not much to say, there has been some attempts in the past to make this happen, I remember an effort coupled with the KenematicRagdollControl, and you probably can find some references on that forum. But nothing got into the engine.

What I’d see is an IKControl that would have a reference to the skeleton as the AnimControl has, and that would manipulate bones according to the ik chain.
Note that most often in an humanoid body, ik chains are most often not bigger than 2… so you can start low and cover 90% of the needs.


Ahem: IkControl… fixed that for you.

Really don’t know the details about IK, but maybe this is a good start: [WIP] Inverse Kinematics - #11 by wezrule the post includes the code for some IkControl. I tested it month ago but it seems to work fine

yeah sorry… you know at least the “I” is not for Interface :wink:

Yea i saw that thread, thanks however. It would be bad to miss something obvious. Also the blender importer uses IK chains to bake the animations at import. This is why is see some discrepancies between animations. These use jacobian methods IIRC which are slow and “unnatural” and have a few numerical issues even with pseudo inverses. Note that that thread is from 3 years ago. I suspect i will be fixing/using some of the blender classes and constraints.

I still feel this will work better. I have no interest in jacobian methods and well they are a bit out of date for real time animations. They are much harder for constraints as well.

I expect problems to be practical ones. Like what is the best way to expose controls or bone targets for other controllers. How the “hooks” are defined in blender or exposed in jME. There are a lot of little details that won’t resolve themselvs untill i just write the dam thing up.

I have already forked jME. When i start (this weekend) people should feel free to download and compile to check it out. I am a firm believer of commit often. However i will always do a full compile with gradel before a commit (with a fresh pull). We can re base later if we don’t want lots of commits showing up for this feature. I will start a “progress” thread when the first version is available with probably some hacky officially unsupported preview/player thing.


I did that.

This was what I originally had. In hindsight, I don’t know why I wanted to cram it into KinematicRagdollControl instead of having it separate. Probably it was about using the constraints already defined by the control.

I still have the code for KinematicRagdollControl but don’t see the IkControl.

Hello, other full-time game developing person. :chimpanzee_smile: Hello math guy. :chimpanzee_closedlaugh: I always wondered how the could been made without such things as IK - guess it’s just a simple trick faking “the real thing”. And I think I saw a XMLImporter (not XmlImporter) in the com.jme3.export.xml package…

Even Sun used to name classes this way before they wised up. Some older JME classes are already incorrectly named but there is nothing we can do but try better going forward.

It’s better to treat acronyms as words for capitalization in class/method names because it avoids acronym soup when you have to put a few together. HTTPSSOID versus HttpSsoId or whatever. (to make up an example)

1 Like

But then an Importer still doesn’t belong to the export package (if it’s not a typo by Ogli) :stuck_out_tongue:

Well, effectively one class per package is kind of silly so think of ‘export’ as ‘the ability to export and import’. Personally, I might have called it ‘io’ but I wasn’t around back then.

Not a typo. :chimpanzee_smile:
And … Hehe, that’s what I was thinking when implementing my KeyValue{ Importer | Exporter | InputCapsule | OutputCapsule } - at first I wanted to create a package called “io” but then I saw how jME did it and called my package “export” too. :chimpanzee_smile:

No suggestions on how to expose the control targets? i was thinking of just returning a list in the Inverse_K_Control :stuck_out_tongue: . Probably to a bone or something. You then still need to add a controller to move these targets.

I would not use ragdoll, they are quite different problems IMO. Also constraints will tend to follow blender and our use of them. We have now traced many of our blender import problems to the constraints. No idea what side of that is the problem however (our blender models/rigs or blender importer).

I know what you did there…

Targets are just positions, am I wrong? To me a map Bone, Position in the control should do the trick.

1 Like

I have no idea what you are talking about :wink:

Yea targets are just positions. They could be orientation as well. But mostly not with the generally accepted way of rigging.