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 ) could give me the “good to go” as well as some advice on some of these points.
My current concept for approaching this are 3 new components:
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).
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).