Deploying to published from @ godotengine/godot-website@b53dd3860c 🚀

article/inverse-kinematics-returns-to-godot-4-6/index.html

@@ -9,7 +9,7 @@
 <span class=by>Silc Renew</span></div><span class=date data-post-date="2025-12-16 10:00:00 +0000">16 December 2025</span></div><div class=tags><a href=/blog/progress-report><div class="tag active">Progress Report</div></a></div></div><div class=article-body><style>article .content img{background-color:initial}</style><p>In Godot 4.6, IK is back in 3D!<p><img src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/picture01.webp alt="IK on the table"><p>Of course, “IK” means inverse kinematics.<p>If you have experience with Godot 3.x, you might remember that IK was removed during the upgrade to 4.0. I explained in a <a href=/article/design-of-the-skeleton-modifier-3d/>previous blog post</a> that it was removed because the old skeleton API design had issues and needed reworking.<p>Then, you might wonder if it was theoretically possible to implement IK alongside the <code class="language-plaintext highlighter-rouge">SkeletonModifier3D</code> implementation in 4.4. However, we had to avoid adding immature features and then hastily removing it again. To implement IK, we staged the elements for the entire IK across three versions.<p>This blog post will explain that journey.<p><img src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/picture02.webp alt="Journey is begun"><h1 id=godot-44>Godot 4.4</h1><p>In Godot 4.4, I implemented the base class for <code class="language-plaintext highlighter-rouge">SkeletonModifier3D</code>, along with two new modifiers, <code class="language-plaintext highlighter-rouge">LookAtModifier3D</code> and <code class="language-plaintext highlighter-rouge">RetargetModifier3D</code>.<h2 id=skeletonmodifier3d--lookatmodifier3d>SkeletonModifier3D / LookAtModifier3D</h2><p><code class="language-plaintext highlighter-rouge">LookAtModifier3D</code> was the minimal implementation to verify that the <code class="language-plaintext highlighter-rouge">SkeletonModifier3D</code> design was correct. <code class="language-plaintext highlighter-rouge">LookAtModifier3D</code> could be considered equivalent to one-bone IK, so it was suitable as a test case.</p><video autoplay loop muted playsinline>
 <source src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/preview-look-at-modifier-3d.webm?1 type=video/webm></video><h2 id=retargetmodifier3d>RetargetModifier3D</h2><p>However, when implementing <code class="language-plaintext highlighter-rouge">LookAtModifier3D</code>, I confirmed that users must specify the bone axis based on the bone rest. It was my initial concern that the retarget feature implemented in 4.0 discarded the bone rests of the imported skeleton.<p>As this concern became a certainty, I attempted to preserve bone rests by implementing <code class="language-plaintext highlighter-rouge">RetargetModifier3D</code>.<p><img src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/inspector-retarget-modifier-3d.webp alt="Inspector of RetargetModifier3D"><p>It was fortunate for me that the processing order design of <code class="language-plaintext highlighter-rouge">SkeletonModifier3D</code> matched the requirements for implementing <code class="language-plaintext highlighter-rouge">RetargetModifier3D</code>.<h1 id=godot-45>Godot 4.5</h1><p>In Godot 4.5, I implemented <code class="language-plaintext highlighter-rouge">SpringBoneSimulator3D</code> and <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> (and its three child classes <code class="language-plaintext highlighter-rouge">AimModifier3D</code>, <code class="language-plaintext highlighter-rouge">ConvertTransformModifier3D</code> and <code class="language-plaintext highlighter-rouge">CopyTransformModifier3D</code>).<p>By the way, I’m involved in a project that utilizes a 3D character model format known as <a href=https://vrm.dev/>VRM</a>. VRM has implementations of <a href=https://vrm.dev/en/vrm1/springbone/>SpringBone</a> and <a href=https://vrm.dev/en/vrm1/constraint/>Constraint</a> as model-specific configurations that can be ported to cross-platform environments, so ensuring compatibility with these was one of the purposes.<h2 id=springbonesimulator3d>SpringBoneSimulator3D</h2><video autoplay loop muted playsinline>
 <source src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/preview-spring-bone-simulator-3d.webm?1 type=video/webm></video><p>One challenging part of implementing <code class="language-plaintext highlighter-rouge">SpringBoneSimulator3D</code> was creating the bone chain internally. Specifically, by setting the root bone as the ancestor and the end bone as the descendant, we could retrieve the bones between them and automatically construct the joint array.<p><img src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/inspector-spring-bone-simulator-3d.webp alt="Inspector of SpringBoneSimulator3D"><p>Compared to users manually creating these arrays, this approach reduced user operations and validation on the core side, making it beneficial for both ends.<h2 id=boneconstraint3d-and-3-child-classes>BoneConstraint3D (and 3 child classes)</h2><p><code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> is a feature that allows bones to interact with other bones. The actual behavior and calculations it provides are simple.<p>What was challenging here was the design for a base class containing a virtual struct array as a member and extending that struct in a child class. This topic is a bit more advanced for beginner coders, but when using struct arrays as properties in Godot, you need to implement a slightly tricky approach.<p><img src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/inspector-bone-constraint-3d.webp alt="Inspector of BoneConstraint3D"><p>I already had the design idea that IK would have a base class similar to <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code>, with child classes extending the structure to implement the actual solver. So, I was confident that merging and establishing that method at this point would be beneficial for IK.<h1 id=godot-46>Godot 4.6</h1><p>Finally, I began implementing IK in Godot 4.6.</p><video autoplay loop muted playsinline>
-<source src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/preview-ik-modifier-3d.webm?1 type=video/webm></video><h2 id=ikmodifier3d-and-7-child-classes>IKModifier3D (and 7 child classes)</h2><p>As a first step, I defined <code class="language-plaintext highlighter-rouge">IKModifier3D</code> and <code class="language-plaintext highlighter-rouge">ChainIK3D</code> by reusing <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> and <code class="language-plaintext highlighter-rouge">SpringBoneSimulator3D</code>. After that, I implemented the process for moving joints called the IK solver.<p>Therefore, <code class="language-plaintext highlighter-rouge">IKModifier3D</code> has the following child classes:<ul><li>IKModifier3D<ul><li>TwoBoneIK3D<li>ChainIK3D<ul><li>SplineIK3D<li>IterateIK3D<ul><li>FABRIK3D<li>CCDIK3D<li>JacobianIK3D</ul></ul></ul></ul><p>When implementing those IKs, I made sure to keep them to the minimum functions.<p>Some IK systems outside of Godot might have additional “processing to make the IK results look better”, separate from the core calculation algorithm that rotates the bones. In the rich IK system, the IK class may include them and can enable their processing by their bool property.<p>Then, I believed separating them would help maintain maintainability and extendability. In other words, if only the “processing to make the IK results look better” can be reused, when users want to implement custom IK, they only need to implement a minimal IK solver.<p>The following are the improvements and additions made in Godot 4.6 to make the IK results look better.<h2 id=tweak-boneconstraint3d>Tweak BoneConstraint3D</h2><p>For example, there are cases where Twist is applied before IK calculation, or where the end bone is directed toward the IK target after IK calculation.<p>In Godot 4.5, the <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> could only assign bones as reference objects, but in 4.6, it can now assign [Node3D] objects.<p><img src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/inspector-new-bone-constraint-3d.webp alt="Inspector of new BoneConstraint3D"><p>This tweaking allows <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> to be used to perform these additional rotations.</p><video autoplay loop muted playsinline>
+<source src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/preview-ik-modifier-3d.webm?1 type=video/webm></video><h2 id=ikmodifier3d-and-7-child-classes>IKModifier3D (and 7 child classes)</h2><p>As a first step, I defined <code class="language-plaintext highlighter-rouge">IKModifier3D</code> and <code class="language-plaintext highlighter-rouge">ChainIK3D</code> by reusing <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> and <code class="language-plaintext highlighter-rouge">SpringBoneSimulator3D</code>. After that, I implemented the process for moving joints called the IK solver.<p>Therefore, <code class="language-plaintext highlighter-rouge">IKModifier3D</code> has the following child classes:<ul><li>IKModifier3D<ul><li>TwoBoneIK3D<li>ChainIK3D<ul><li>SplineIK3D<li>IterateIK3D<ul><li>FABRIK3D<li>CCDIK3D<li>JacobianIK3D</ul></ul></ul></ul><p>When implementing those IKs, I made sure to keep them to the minimum functions.<p>Some IK systems outside of Godot might have additional “processing to make the IK results look better”, separate from the core calculation algorithm that rotates the bones. In the rich IK system, the IK class may include them and can enable their processing by their bool property.<p>Then, I believed separating them would help maintain maintainability and extendability. In other words, if only the “processing to make the IK results look better” can be reused, when users want to implement custom IK, they only need to implement a minimal IK solver.<p>The following are the improvements and additions made in Godot 4.6 to make the IK results look better.<h2 id=tweak-boneconstraint3d>Tweak BoneConstraint3D</h2><p>For example, there are cases where Twist is applied before IK calculation, or where the end bone is directed toward the IK target after IK calculation.<p>In Godot 4.5, the <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> could only assign bones as reference objects, but in 4.6, it can now assign <code class="language-plaintext highlighter-rouge">Node3D</code> objects.<p><img src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/inspector-new-bone-constraint-3d.webp alt="Inspector of new BoneConstraint3D"><p>This tweaking allows <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> to be used to perform these additional rotations.</p><video autoplay loop muted playsinline>
 <source src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/preview-bone-constraint-3d.webm?1 type=video/webm></video><p><a href=/storage/blog/inverse-kinematics-returns-to-godot-4-6/adjusted-ik-3d-demo.zip>adjusted-ik-3d-demo.zip</a><h2 id=bonetwistdisperser3d>BoneTwistDisperser3D</h2><p>In theory, using <code class="language-plaintext highlighter-rouge">ConvertTransform3D</code> allows you to apply the rotation of descendant bones to their ancestors. However, the process for setting this up properly was somewhat complex and could only be handled by advanced users.<p><code class="language-plaintext highlighter-rouge">BoneTwistDisperser3D</code> provides a simple way to achieve that process.</p><video autoplay loop muted playsinline>
 <source src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/preview-bone-twist-disperser-3d.webm?1 type=video/webm></video><h2 id=limitangularvelocitymodifier3d>LimitAngularVelocityModifier3D</h2><p><code class="language-plaintext highlighter-rouge">LimitAngularVelocityModifier3D</code> is a modifier that limits angular velocity. The behavior is quite simple, so it doesn’t need much explanation.<p>However, it’s worth learning that there are two types of IK.<h2 id=deterministic-ik>Deterministic IK</h2><p>In computer science, “deterministic” means that the result is always the same for a given input. In particular, for game applications like Godot, the term means that the result does not depend on the state of the previous frame. Incidentally, since <code class="language-plaintext highlighter-rouge">AnimationMixer</code> already has a <a href=/article/migrating-animations-from-godot-4-0-to-4-3/#deterministic-blending>deterministic option</a>, that immediately made me decide to adopt this term.<p><code class="language-plaintext highlighter-rouge">TwoBoneIK3D</code> and <code class="language-plaintext highlighter-rouge">SplineIK3D</code> are always deterministic. However, in <code class="language-plaintext highlighter-rouge">IterateIK3D</code>, whether it is deterministic depends on the options.<p><code class="language-plaintext highlighter-rouge">IterateIK3D</code> repeats the routine provided by the solver to approach the end bone toward its goal. At this point, the number of repetitions per frame depends on the option.<p>When the deterministic option is disabled, it means that the iteration is performed by carrying over the state from the previous frame. In this case, even with a small number of iterations per frame, the end bone can reach the goal eventually as frames progress.</p><video autoplay loop muted playsinline>
 <source src=/storage/blog/inverse-kinematics-returns-to-godot-4-6/preview-non-deterministic-ik-3d.webm?1 type=video/webm></video><p>In contrast, when the deterministic option is enabled, the previous frame’s state is not carried over. Therefore, if the number of iterations per frame is small, the end bone may never reach its goal.</p><video autoplay loop muted playsinline>

atom.xml

@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom"><title>Godot Engine Official</title><link href="https://godotengine.org/atom.xml" rel="self"/><link href="https://godotengine.org/"/><updated>2025-12-16T09:41:13+00:00</updated><id>https://godotengine.org/</id><entry><title>Inverse Kinematics Returns to Godot 4.6</title><link href="https://godotengine.org/article/inverse-kinematics-returns-to-godot-4-6/"/><updated>2025-12-16T10:00:00+00:00</updated><id>https://godotengine.org/article/inverse-kinematics-returns-to-godot-4-6/</id><summary>Now Godot has Inverse Kinematics in 3D.</summary><content type="html">&lt;style>article .content img { background-color: initial; }&lt;/style>
+<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom"><title>Godot Engine Official</title><link href="https://godotengine.org/atom.xml" rel="self"/><link href="https://godotengine.org/"/><updated>2025-12-16T10:14:56+00:00</updated><id>https://godotengine.org/</id><entry><title>Inverse Kinematics Returns to Godot 4.6</title><link href="https://godotengine.org/article/inverse-kinematics-returns-to-godot-4-6/"/><updated>2025-12-16T10:00:00+00:00</updated><id>https://godotengine.org/article/inverse-kinematics-returns-to-godot-4-6/</id><summary>Now Godot has Inverse Kinematics in 3D.</summary><content type="html">&lt;style>article .content img { background-color: initial; }&lt;/style>
 &lt;p>In Godot 4.6, IK is back in 3D!&lt;/p>
 &lt;p>&lt;img src="/storage/blog/inverse-kinematics-returns-to-godot-4-6/picture01.webp" alt="IK on the table" />&lt;/p>
 &lt;p>Of course, “IK” means inverse kinematics.&lt;/p>
@@ -66,7 +66,7 @@
 &lt;p>The following are the improvements and additions made in Godot 4.6 to make the IK results look better.&lt;/p>
 &lt;h2 id="tweak-boneconstraint3d">Tweak BoneConstraint3D&lt;/h2>
 &lt;p>For example, there are cases where Twist is applied before IK calculation, or where the end bone is directed toward the IK target after IK calculation.&lt;/p>
-&lt;p>In Godot 4.5, the &lt;code class="language-plaintext highlighter-rouge">BoneConstraint3D&lt;/code> could only assign bones as reference objects, but in 4.6, it can now assign [Node3D] objects.&lt;/p>
+&lt;p>In Godot 4.5, the &lt;code class="language-plaintext highlighter-rouge">BoneConstraint3D&lt;/code> could only assign bones as reference objects, but in 4.6, it can now assign &lt;code class="language-plaintext highlighter-rouge">Node3D&lt;/code> objects.&lt;/p>
 &lt;p>&lt;img src="/storage/blog/inverse-kinematics-returns-to-godot-4-6/inspector-new-bone-constraint-3d.webp" alt="Inspector of new BoneConstraint3D" />&lt;/p>
 &lt;p>This tweaking allows &lt;code class="language-plaintext highlighter-rouge">BoneConstraint3D&lt;/code> to be used to perform these additional rotations.&lt;/p>
 &lt;video autoplay="" loop="" muted="" playsinline="">

rss.xml

@@ -66,7 +66,7 @@
 <p>The following are the improvements and additions made in Godot 4.6 to make the IK results look better.</p>
 <h2 id="tweak-boneconstraint3d">Tweak BoneConstraint3D</h2>
 <p>For example, there are cases where Twist is applied before IK calculation, or where the end bone is directed toward the IK target after IK calculation.</p>
-<p>In Godot 4.5, the <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> could only assign bones as reference objects, but in 4.6, it can now assign [Node3D] objects.</p>
+<p>In Godot 4.5, the <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> could only assign bones as reference objects, but in 4.6, it can now assign <code class="language-plaintext highlighter-rouge">Node3D</code> objects.</p>
 <p><img src="/storage/blog/inverse-kinematics-returns-to-godot-4-6/inspector-new-bone-constraint-3d.webp" alt="Inspector of new BoneConstraint3D" /></p>
 <p>This tweaking allows <code class="language-plaintext highlighter-rouge">BoneConstraint3D</code> to be used to perform these additional rotations.</p>
 <video autoplay="" loop="" muted="" playsinline="">