Inverse Kinematics

Everything about the development of Urho3D.

Inverse Kinematics

PostPosted by TheComet » 26 Feb 2016, 20:50

There seems to be some general interest in the addition of an IK solver to Urho3D (such as this feature request and of course the need for IK in my own project). I think it would be very cool for Urho3D to have this capability, so I have taken it upon myself to implement this feature request.

I'd like to clarify a few things before I make any major changes to Urho3D and would be happy if one of the core developers (I'm looking at you cadavar :D) could give me the "good to go" as well as some advice on some of these points.


Concept

My current concept for approaching this are 3 new components:

Image

IKSolver is attached to the root scene node and - as the name implies - is responsible for solving all IK constraints. I plan on implementing the Jacobian Inverse method and the Jacobian Moore–Penrose method for starters, but will probably also look at implementing a more robust algorithm in the future.

IKEffector can be attached to any node in the scene and marks that node as the beginning of an IK chain. The effector has the methods SetTarget() for controlling the target location of the node and SetChainLength() to control how many parent nodes are affected.

IKConstraint is attached to nodes part of the IK chain and is used to "fine tune" the behaviour of each node (things such as the "stiffness" and scale factor).


Questions

1) When to apply IK
The IK solver is capable of solving an entire scene graph in one pass, so it would make sense to have it kick in only once when needed -- whenever a node part of any IK chain becomes dirty. As I see it, this should happen after animation states have been applied, meaning in E_SCENEDRAWABLEUPDATEFINISHED. The problem is I can't just hijack that event for IK because what if the user wants to add their own bone modifications in addition to IK?

I could insert a new event called something like E_INVERSEKINEMATICUPDATE which is sent just before E_SCENEDRAWABLEUPDATEFINISHED. This begs the question: Do we even need an IK update event? Is this the way I should go, or is there a better way I can insert myself into the engine?

2) Build system
Should I add a CMake option URHO3D_IK to include/exclude the IK solver, or should it be something that is always available?

That's all of the questions I have for now. I'll post updates in this thread as this project evolves. You can test my progress by checking out the branch InverseKinematics from here: https://github.com/thecomet93/urho3d/tree/InverseKinematics (currently there's not much IK functionality).
I'm a non-binary non-cis sexually fluid cephalopod identifying genderqueer mocha frappé latte
User avatar
TheComet
Active user
Active user
 
Posts: 122
Joined: 29 Jan 2014, 14:07
Location: Germany

Re: Inverse Kinematics

PostPosted by 1vanK » 26 Feb 2016, 21:39

User avatar
1vanK
Moderator
Moderator
 
Posts: 430
Joined: 26 Jun 2015, 19:16
Location: Internet

Re: Inverse Kinematics

PostPosted by TheComet » 06 Jun 2016, 22:29

I've hardly had the time to work on this (uni, exams), but I haven't given up on this yet!

Below you can see screenshots of before and after the first iteration of FABRIK, the inverse kinematic algorithm I chose to implement. In this case, the arm consists of 3 rigid joints. The end effector is trying to reach a target located on the right (out of bounds).

Image

Image

The neat thing about FABRIK as opposed to, say, jacobian based methods, is it requires vastly less iterations to reach a target, a single iteration requires less computing time, and it always converges (i.e. no singularities).
I'm a non-binary non-cis sexually fluid cephalopod identifying genderqueer mocha frappé latte
User avatar
TheComet
Active user
Active user
 
Posts: 122
Joined: 29 Jan 2014, 14:07
Location: Germany

Re: Inverse Kinematics

PostPosted by Mike » 07 Jun 2016, 06:24

I also think that FABRIK is the way to go, as most of the things I've experimented with gave very unrealistic behavior.
Also one advantage of FABRIK is that it splits the tasks instead of handling everything blindly.
Keep it up :P
User avatar
Mike
Moderator
Moderator
 
Posts: 353
Joined: 16 Jan 2014, 20:35
Location: France

Re: Inverse Kinematics

PostPosted by xalinou » 07 Jun 2016, 12:26

Image
User avatar
xalinou
New user
New user
 
Posts: 11
Joined: 06 Jun 2016, 02:22

Re: Inverse Kinematics

PostPosted by TheComet » 07 Jun 2016, 22:20

Today I implemented initial pose restoring, which allowed me to finally run the algorithm in real-time. Here's a video.



I think you can see for yourself why FABRIK is superior. Just 10 iterations and the result is almost perfect. Jacobian based methods will often times require up to 1000 iterations to achieve the same tolerance.

Current issues:
* Removing IKEffector from a node doesn't update initial pose data
* Negative maxIteration

Todo:
* Chain objects need to share the same Vector3 objects for base/effector positions to make solving for multiple chains easier.
* Apply angles from chain objects back to scene node (currently only translations are applied)
* Add support for enabling/disabling pose restoring -> will allow support for animations as well as just scene node IK
* Add support for manually updating initial pose.
* Apply bullet constraints
* Optimise
I'm a non-binary non-cis sexually fluid cephalopod identifying genderqueer mocha frappé latte
User avatar
TheComet
Active user
Active user
 
Posts: 122
Joined: 29 Jan 2014, 14:07
Location: Germany

Re: Inverse Kinematics

PostPosted by hd_ » 08 Jun 2016, 00:40

You are making exciting progress, great work !
User avatar
hd_
Contributor
Contributor
 
Posts: 220
Joined: 21 Jul 2014, 08:55
Location: Australia

Re: Inverse Kinematics

PostPosted by Mike » 08 Jun 2016, 04:35

Well done ;)
User avatar
Mike
Moderator
Moderator
 
Posts: 353
Joined: 16 Jan 2014, 20:35
Location: France

Re: Inverse Kinematics

PostPosted by Modanung » 08 Jun 2016, 20:53

Really cool! :D
for (Person* p : people)
ΞΞΞΞp->StopUsingWindows("https://www.linuxmint.com");
User avatar
Modanung
Active user
Active user
 
Posts: 171
Joined: 22 Jan 2015, 14:53
Location: The Netherlands

Re: Inverse Kinematics

PostPosted by TheComet » 09 Jun 2016, 23:53

The solver now supports multiple end effectors, as long as they share the same base node. Next up: Multiple end effectors with multiple intermediate base nodes. Have a video:



Current TODO list:
Code: Select all
 *  - IKEffector doesn't save target node name when saving scene in editor
 *  - Initial pose is not saved when saving scene in editor. Instead, the
 *    solved state of the chain(s) are saved.
 *  - Target angle in addition to target position -> use weighted angles
 *    approach
 *  - Add an IKEffector weight parameter, so the user can specify
 *    (between [0..1]) how much influence the solved chains have.
 *  - Apply angles from chain objects back to scene nodes (currently only
 *    translations are applied).
 *  - Add support for enabling/disabling initial pose to support animated
 *    models as well as scene nodes.
 *  - Add support for manually updating initial pose.
 *  - Apply bullet constraints to joints.
 *  - Optimise.
I'm a non-binary non-cis sexually fluid cephalopod identifying genderqueer mocha frappé latte
User avatar
TheComet
Active user
Active user
 
Posts: 122
Joined: 29 Jan 2014, 14:07
Location: Germany

Next

Return to Developer Talk

Who is online

Users browsing this forum: No registered users and 0 guests

cron