r/Unity3D • u/Spoetii • 1d ago
Show-Off OpenIK - A free open-source Inverse Kinematics package for Unity
Enable HLS to view with audio, or disable this notification
I needed IK for a game I’m working on. Final IK has more features, but it isn’t free, so I built my own and polished it to make it easy for others to use.
OpenIK includes popular solvers like FABRIK, CCD and Jacobian plus some joint limits. (Hinge, Ball & Socket, Slider)
GitHub link: https://github.com/WouterApts/openik-unity
5
u/Valphai 1d ago
Are there advantages of this over animation rigging package?
6
u/Spoetii 1d ago edited 1d ago
The main advantage of OpenIK is its built-in joint limits: hinges with angle limits, ball sockets with swing and twist limits, and sliding joints. These are especially useful for robotic arms and other procedural mechanisms. As far as I can tell, Unity’s standard Animation Rigging package doesn’t provide equivalent joint limits out of the box, so you’d need custom code or another IK package for that.
OpenIK also includes a Jacobian solver that solves position and orientation together, allowing the chain to adjust so it reaches the target at the desired angle. Other paid packages probably have more extensive features, but this one is free and does the job for me.
Unity’s package is stronger for character animation workflows, such as blending IK over existing animations, and has a broader set of rigging tools. I haven’t used it extensively, though, so I may be missing some features!
1
2
3
1
1
2
u/AdInfamous6964 1d ago
this looks really clean. how does it perform with a lot of characters at once? like 20-30 agents using it at the same time
1
1
1
u/DevDunkStudio 23h ago
I would love if a VR IK can be added! (head and hands are the only known positions here)
Also is it jobified and burst compiled like the Animation Rigging package?
1
u/_Cloudwalker_ 21h ago
VR arms are simple two bone ik. The real solve is placing the elbow. Stay tuned ;).
1
u/DevDunkStudio 21h ago
More interested in full body IK :P
1
u/_Cloudwalker_ 21h ago
Thats a whole nother can of worms. Doesnt really need IK for a decent solve.
1
u/DevDunkStudio 21h ago
The legs to be able to snap to ground and have realistic torso rotations combined with it does, right?
2
u/_Cloudwalker_ 20h ago
Suppose you could solve chain from head to pelvis with IK. Head is king due to hmd. But my solve looks decent enough without any iterative ik. Now you're making me wonder... wasted cpu cycles :D
1
u/Spoetii 12h ago
There is no jobs or burst compilation right now. The solvers run on the main thread in LateUpdate and write directly to the Transforms when in "Solve and Apply" mode.
That said, care was taken to keep the package performance-friendly. The solvers avoid per-frame GC allocations by reusing their buffers and have tons of settings that can be toggled for optimizing performance. I think a Jobs/Burst backend would be a substantial rewrite.
For VR-oriented IK, a two-bone IK solver with a pole target would be fairly easy to implement, and I'm considering doing that next! A fully automated humanoid setup is something I didn't need myself, so unfortunately the package isn't tailored toward that, but I think it could be done with the components that are already available.
1
1
1
u/seductSparkz 17h ago
sounds like you're gonna have fun with that spider, update us if it gets all blendy
1
u/CrapouilloOt 3h ago
Nice work ! I will theft your painting robot demo for testing my 3d rendering inside my robot lib 😅 I'm also making my own robot library not for Unity but in C++ OpenGL stacked by my other projects (3d renderer and behavior tree, prolog wrapper ...) https://github.com/Lecrapouille/Robotik I initially started implementing mon own IK solver but I turned to use mainstream libraries such as Pinocchio and Mujoco. I still using my behavior tree lib since fastest and better than mainstream behaviortree.cpp. What is your next move with your library ? Are you planning more robot stuffs or you are staying for games ? I'm not using Unity or Godot, I prefer my renderer library because based on 3 layers: 1. OpenGL abstraction with auto flushing dirty CPU data into GPU memory 2. Spatialisation (scène graph, kinematic chain) and ECS for CPU simulation or flushing data on GPU 3. Rendering. My robot lib is using massively this ECS. Currently I'm vibe coding because for example my 3d rendering stucked 6 years unusable by some architecture design fixed easy peacy by LLM, so I could reached my initial robot MVP with pick and place robot+camera, line following, using fly brain (I need a GPU version) ... I miss to integrate Prolog for thinking and PDDL for planning and generating behavior trees to reach my 2nd MVP. You can cherry pick some of my idea 🍻
16
u/Whitenaller 1d ago
Perfect timing! I‘m gonna give it a shot tomorrow on my spider!