Draft: GSoC 2026 - Expanded Auto IK

[paulhanson2000]

Paul Hanson
Email: paulhanson2000 at gmail
Blender chat: @paulhanson2000

PRs:
• #156412 (WIP): Ability to restrict IK stretch to Y only; addresses #83911
• #156548: Fixes IK stretch with targetless/auto IK
• Tiny fixes #155496 and #155499

Synopsis

The goal of this project is to lay the groundwork for an expanded Auto IK system in Blender. In this system, a rig is defined by simple settings on each bone and how they interact with different control modes. These interactions lead to many emergent ways to control the rig which normally require complicated mechanisms to set up traditionally. And all this with only one set of bones, no FK/IK switching!

This builds on how Auto IK already works: temporary constraints appear when a transform operation is invoked; when the operation is confirmed the transforms are baked to an FK pose and the constraints disappear. The expanded system would allow more control over where constraints appear. Admittedly, this system shares a problem with Auto IK in that everything is still interpolated with FK. There are workarounds to achieve other types of interpolation, but this system is especially intended to save time in cases where stepped or FK interpolation is acceptable.

Benefits

Temporary constraints from Auto IK may conflict with regular bone constraints. But no matter how complex a rig’s constraint mechanisms, as long as it has some sort of top-level interface that is FK (such as when all FK/IK switches are set to FK), you can use this system to animate it. But why care if you already have a fancy rig with all the controls you need? One advantage is that it would remove the hassle of FK/IK snapping/switching during the blocking pass. Fixing the FK interpolation later is relatively easy: after animating, bake the (FK) keyframes to the traditional rig’s IK controls and do a quick second pass just to keyframe the IK switches.

This would also lower the rigging entry barrier for beginner animtors. With the expanded Auto IK system, one could have access to semi-complicated behaviors such as knee and elbow pinning, all with a minimal FK rig. (As long as FK or stepped interpolation is acceptable.)

(Note the system would depend on parent-child relationships between the bones. Rigs which fake these relationships using bone constraints would not be compatible.)

Project Details

There are 4 parts to the system:

• Per-bone properties
• Rig-wide presets/“snapshots” of those bone properties the user can create and switch between
• Global control modes (analogy: like sculpt brushes, but for animation)
• Global toggles (e.g. X-Axis Mirror)

Examples:

Take a typical humanoid FK rig. Suppose there is a bone property called IK Mark, with an associated Default Chain Length property. I tick IK Mark box for the hip, clavicle, fingertips, and thumbtip, setting chain lengths of 0, 0, 3, and 2 respectively.

Now for the control modes. Each interacts differently with the IK Mark property. (Videos show the intended behavior. Green/Red bones represent FK/IK.)

• IK mode
  • Automatically creates an IK chain to the tail of the nearest upstream IK mark,
    and a reverse-IK chain from the tail of the nearest downstream IK mark.
  • Here the forearm is grabbed. The nearest downstream IK mark is the fingertips, so they are pinned with reverse-IK up to their specified Default Chain Lengths. The nearest upstream IK mark is the clavicle, so the arm movement stops at the shoulder.
    
  • This next video does the same, but switches to a different rig preset where the fingers are not IK-marked.
    
• FK mode
  • Rotates the current bone in FK, but the tail of the nearest downstream IK Mark is pinned.
  • Here the clavicle grabbed and moved freely, while keeping the fingers pinned. (If I had been in IK mode, an IK chain would have been created down the spine because the hip is the nearest upstream IK Mark.)
    
  • One more example which switches to a preset with no IK marks, so the fingers are not pinned:
    
• Connected mode: This would simply be the existing Auto IK functionality under a new name.

There are many more possible modes (e.g. backwards-FK, or even modes that apply temporary physics to the bones like the cloth simulation brushes of sculpt mode). I won’t have time to implement them all in this project, but I believe the above three are the most important.

UI:

• New “Auto IK” panel in bone properties.
• New “Auto IK Presets” panel in armature properties (a list view similar to bone collections).
• Expanded “Pose Options” side panel in the 3D viewport, similar to the prototype UI in the videos above.

Testing strategy: There will be 3 layers of testing.

• A suite of minimal rigs to test the basic logic.
• A simple FK humanoid as shown in the videos, with a suite of rig presets to test more practical scenarios.
• A couple more complex rigs such as from Rigify. I will not impose it on myself to be compatible with all these rigs, but it will be interesting to observe what issues I run into.

Deliverables

• An expanded version of Auto IK which can:
  • Automatically create IK chains in convenient user-defined places depending on the context.
  • Pin any joint.

Schedule

I expect this to be a small (90-hour/8-week) project. I could start right away and anticipate no conflicts in my schedule as I work only part time.

• Week 1-2: Boilerplate
  • DNA/RNA property definitions
  • UI elements to access the properties
  • Ability to store & recall rig presets
• Week 2: Create test suite of rigs and rig presets
• Week 3-4: Connected mode and FK mode
• Weeks 5: IK mode
• Weeks 6-7: Finalizing
  • Docs
  • UI polish
  • Final testing and bug fixes
• Week 8: (extra week to account for delays)

Stretch Goals

If time allows, there are some other useful additions which could fit in the schedule of this small project:

• “Free” control mode
  • Always pins the immediate parent and child regardless of IK marks, and enables IK stretch. This allows free movement of a single joint without affecting anywhere else.
    
• X-Axis mirror compatibility
• A global toggle along the lines of “IK Mark Children Inherit Rotation”. This would lock the rotation of any bones downstream an IK Mark.
  • Here is an example of what it would look like on an IK-Marked wrist:
    

Bio

Hello! I’m a 25 year old data analyst working at a hospital in the Boston area. I’ve been interested in animation for many years, but only recently did it occur to me how applicable programming can be to 3D animation, and I started to wonder if I could pursue it despite not having gone to art school. Last year I started to practice 3D more seriously.

My field is a big mess of bash, R, and Python, so that is most of my experience. Regarding C, I managed to sneak in some C & Vulkan for a school project (a particle life simulation: short video). Earlier, I made a simple ASCII game engine for the terminal in C. As for Python, besides work I have written some add-ons for myself with bpy, such as one to stream hand mocap data from LeapMotion trackers into Blender (another short video).

Why am I the best person to work on this project? Because I really want these features for myself so I am motivated to implement it!

Acknowledgements

Thanks to Raf Anzovin, the inventor of “ephemeral rigging". If you’ve never heard of ephemeral rigging, see this presentation; it was my main inspiration! Also thanks to @Pxy-Gnomes and @Nacho_de_Andres for inspriation and ideas, and @Jeacom for the human mesh used in my examples.

[Draise]

This is super exciting! I have used an addon called FreeIK by XBodya13 that had this solution, by adding a “pinning” system then full body IK that would limit start and end points by a dynamic “pin” you can toggle onto a bone - and recording to a new transform space (the work around). Your initiative is a dream come true for me!

Power to you. Hope you get this done well, and mature it well.

[Pxy-Gnomes]

@paulhanson2000, it’s fascinating to have a developing project like this one in Blender for Rigging & Animation!

By the way, if you ever need anyone doing tests, checks, and perhaps for feedback on features, you can sure count on me.

Thank you for the vision and engagement!
Cheers!

[Nacho_de_Andres]

Looks great, looking forward to seeing how the presets will work and what is the MVP for the implementation. I see a lot of future expansion on the system but this could already set solid bases to expand the current systems.

Thanks for the mention, happy my crazy views helped add some ideas to the mix.

[sybren]

@paulhanson2000

In short, an ephemeral rig is defined by simple settings on each bone and how they interact with different control modes.

Ephemeral rigging is hard to condense into a single sentence, I know Here I think it’s better to talk in terms of ‘controllers’, which live in world space. These do manipulate the underlying bones, which in turn may have some hierarchy to them, but that’s irrelevant for the Ephemeral Rigging system.

Unfortunately, this shares the same problem as Auto IK: everything is still interpolated via FK, but more on that later.

IIRC Ephemeral Rigging solves this in a different way: no interpolation! The tools for editing across ranges of frames are so good, and working with the system so fast, that it becomes feasible to give control over every frame. But yeah, not something you can just build in this GSoC project

@paulhanson2000

(Note the semi-ephemeral rigging system depends on parent-child relationships between the bones. Some complex rigs don’t have real parent-child relations and instead use constraints which give that illusion. These would not be compatible. Unfortunately, I believe this includes Auto Rig Pro rigs.)

I think this is fine, especially as a first implementation. A new way of working doesn’t have to immediately be compatible with the entire planet.

@paulhanson2000

The grab behavior disconnecting the arm is not a sane example. A more practical use for the FK grab would have been to grab the clavicle or hip, but you get the idea.

Then why use this example?

@paulhanson2000

Regarding C, I managed to sneak in some C & Vulkan for a school project (a particle life simulation: short video). Earlier, I made a simple ASCII game engine for the terminal in C.

Blender’s code is mostly C++ though. Do you have experience with that too?

---

Overall, I think there are big enough differences between your proposal and Ephemeral Rigging (ER) that I don’t think ER should be mentioned in the title & scope. Of course it can be mentioned as an inspiration, but this to me looks more like “richer auto-AI” than ER.

Your proposal seems to have changed quite significantly, compared to last time we spoke about this. Back then it was just pinning via selection, and transforming would be using only the active bone. The schedule is also rather tight. It might be hard to implement IK control mode in only 2½ days. I do like that you’re starting with a test suite, often enough people leave that to the end (with all the lovely surprises that it brings).

[paulhanson2000]

IIRC Ephemeral Rigging solves this in a different way: no interpolation!

Yes and similarly, the result of this project would be mostly intended for animating with stepped/constant interpolation. It’s possible to get IK interpolation by baking as I mentioned, but that’s a bit inconvenient and still requires a rig with traditional IK mechanisms at the end of the day.

The next thing I’d implement after GSoC would be something like the Breakdown/Bias slider from the ER presentation. It would take into account the IK Marks on the bones and interpolate appropriately. I envision a UI/UX like Grease Pencil’s interpolate tool. I think that will be the last piece before the system could truly stand on its own to make a serious animation.

Blender’s code is mostly C++ though. Do you have experience with that too?

Not much, but from what I am seeing working on my PRs, it’s not so bad :^) looks like Blender uses C++ responsibly and doesn’t go overboard with the crazy language features.

The schedule is also rather tight. […] Back then it was just pinning via selection, and transforming would be using only the active bone.

I think the control modes will be relatively simple, no more complicated than Auto-IK is. FK mode’s implementation boils down to: “traverse children of the active bone, spawn IK constraint on the first IK Mark encountered in each branch, give it chain length = floor(default_chainlen, chainlen_up_to_transforming_bone)”. The IK solver can handle tree IK already, so no worries if IK chains overlap.

IK mode is identical to FK mode, just spawns an additional IK constraint on the active bone itself. The only gotcha is if the parent-side IK starts at the active bone’s tail, but the children-side IK reaches the active bone’s head, then you need to decide which side gets the active bone.

Multi-selections should not be an issue. The problem is simplified a lot because I’ll only be dealing with real parent-child relations (no Child-Of constraints), and Blender automatically blocks transforms on selected children if any upstream bone is selected. Thus all I have to care about is the parentmost selected bone(s).

X-Axis Mirror does scare me a little, not sure why but I feel like it’s gonna bite me!

I think the timeline is feasible; and, I don’t want to drag my feet but worst case I can work some extra weeks. I’m doing this because I want the features for myself anyways.

Ephemeral rigging is hard to condense into a single sentence, I know […] Overall, I think there are big enough differences between your proposal and Ephemeral Rigging (ER) that I don’t think ER should be mentioned in the title & scope.

That will simplify the proposal a lot, and I won’t have to write “ephemeral” everywhere!

---

Thanks for the feedback! (And to those who commented above thanks for the support!) I’ll keep improving the proposal and working on PRs.

[SpookyDoom]

Woah! The Epic presentation was a lot more exciting than I expected it to be. If this could actually be integrated into Blender, then this would probably be, at least for me, the most excited I’ve been for a new system of editing since Substance Designer/Painter and Marvelous Designer. This would be able to break down so many hurdles for animators all over the world.

Sorry, I don’t have to add anything really useful to the technical side other than encouragement in getting started with this, if you feel up for it. Any groundwork for this is fantastic.

[sybren]

@paulhanson2000

worst case I can work some extra weeks.

That is not acceptable. Your proposal should be sound for the duration of the project. If you already feel the need to open up the possibility of extending it by several weeks, I would strongly recommend trimming down the proposal instead. If the project is not done at the end of the schedule, I can’t mark you as ‘passed’ in the GSoC evaluation form, and that’ll mean that you won’t get your final payment.

In my experience, perspectives change. Before the project starts, GSoC contributors always want to stick around after it ends, but in practice, life takes over. Once the final payment is in, the “this is now my day job” period is over, and other time sinks (like a new day job) can very easily drain their energy for volunteer work. I’m not saying that this is you, just sharing my mentoring experience.

So how about this. Trim down the project to the minimum that actually is useful when animating. Then define stretch goals. If things go smoothly, you’ll have time to work on these stretch goals after completing the main project. That way you go from “finished” to “finished and even better”, which is not only easier for me to mentor & grade, but also way more motivating for you to work on.

[paulhanson2000]

Fair enough; the minimum would be the FK & IK modes. That’d fulfill the most important use: the ability to block out shots without FK/IK switching. I’ll move Free mode, the “IK Mark Children Inherit Rotation” toggle, and X-Axis Mirror to stretch goals. That way I’ll have plenty of time and can feel good about picking up a few stretch goals. I’ll update the proposal tonight!

[Manan]

Hi, I’m exploring the Blender repository as a GSoC 2026 applicant and came across this issue. I’m currently trying to understand this part of the codebase and would be interested in helping investigate or work on this if guidance is available.

[Pxy-Gnomes]

Hello, @paulhanson2000;

Do you happen to have those videos elsewhere, maybe links or files?

Until this point, I was never able to watch any of them: they do not load in my computer for some mysterious reason; I’ve tried several things to no avail. I’m not sure if I’m the only one having this issue.

[paulhanson2000]

@Manan Did you submit a proposal already?—I believe the deadline was Mar 31. But if you are also generally interested in improving Auto IK, any help or ideas are welcome! Is there anything specific you need guidance on? What helped me start understanding the code was using a debugger to set a breakpoint in one of the Auto IK-related functions, then doing a stack trace. There are notes in the developer docs about how to do this. Most of the Auto IK logic lives in this file: blender/source/blender/editors/transform/transform_convert_armature.cc at main - blender - Blender Projects.

@Pxy-Gnomes Hm… I wonder if it is because I used h265 instead of h264 encoding. Anyways, I needed to upload the videos to YouTube for when I submitted my proposal as a PDF, so here they are!:

• IK mode, fingers pinned
• IK mode, fingers not pinned
• FK mode, fingers pinned
• FK mode, fingers not pinned
• Free mode
• “IK Mark Children Inherit Rotation” toggle

[Mamta_Bankoti]

This is a well-thought-out proposal. Expanding Auto IK with simple bone settings and control modes feels like a smart way to simplify animation without complex rigs or FK/IK switching.

I like the focus on practical use, especially for faster blocking and making things easier for beginners. The plan and scope also seem realistic.

[paulhanson2000]

The speed I’m going I believe I overestimated my time/abilities so I withdrew my application (nooo my hubris!). But I’m still going to implement this! Just slower. I’ll keep posting updates here.

Over the past month I made these PRs (mostly one-liners tbh):

• #105429 (Document Auto IK’s reverse-IK behavior)
• #155499 (Allow Auto IK reverse-IK even with non-connected parent)
• #156548 & #156665 (Fix targetless/Auto IK stretch)
• #156412 ((Still WIP) IK stretch can affect Y axis only)
• #155496 (Fix Auto IK X-Axis mirror)
• #156919 (Faster pie menu navigation (will be useful later))

Next up, I want to fix live autokeying with Auto IK (currently, only the selected bone gets keyed). This could be a decent band-aid on the fact that Auto IK is interpolated with FK.
I also want to fix #151457 (currently, Auto IK behaves weirdly when pressing R to rotate).

I also have my eyes on the Pivot Constraint. This poor lad is rarely used in rigs because it’s based in worldspace which often behaves weirdly with bones since their Y axis faces up by default (see #85350). But this constraint has so much potential! I’m going to give it some love and make it more intuitive to use. This is relevant because besides the “IK Mark”, another bone property I was thinking of is an optional “Pivot”. That way, you can have rig presets with a convenient pivot point defined per bone… could save a lot of clicks moving the 3D cursor and using the Transform Pivot Point menu.

[Pxy-Gnomes]

WOW!!!

Just check who’s the #001 here for mastering Rigging & Animation in Blender today!!!

For me, you’re already a legend, bro!

And sure, big thanks and recognitions for everyone been contributing so far for the whole construction of Blender, making this possible… and that’s just the beginning…!

PS: It’s working (Blender 5.2.0 Alpha, a portable version)! I’m very excited to see which Rig contraptions I can achieve… JUST with this new feature! This is quite groundbreaking!

[TheLittleMouse]

One of the major problems of Auto IK is that it doesn’t respect rotation limits, or it lacks pole vector, which are needed for the joints to bend correctly in the standard IK. Is that something that you can fix?

[paulhanson2000]

Actually, Auto IK does respect rotation limits set in the bone IK properties, even though the options appear greyed out in the UI (see issue #119678, will fix). For now, I think rotation limits are good enough, but it could still be useful to have more control over the roll of the IK chain somehow while you’re transforming a bone. Maybe the “IK mode” could let you control the roll with the scroll wheel or something? (Basically the scroll wheel would act as if you were orbiting a pole vector around the chain.) But it would be nice if there were an easy way to control it if you’re using a tablet too… if anyone has better ideas let me know. But, I probably won’t get around to this feature for a while yet.

[Pxy-Gnomes]

@paulhanson2000

but it could still be useful to have more control over the roll of the IK chain somehow while you’re transforming a bone. Maybe the “IK mode” could let you control the roll with the scroll wheel or something? (Basically the scroll wheel would act as if you were orbiting a pole vector around the chain.) If anyone has better ideas let me know. But, I probably won’t get around to this feature for a while yet.

Yes… it often appears to me that the Y Axis (Roll) has an especially hardcore Stiffness, even when it is 0.000, in comparison to the X and Z Axes. I suspect this is something that affects Inverse Kinematics, not only of Auto IK Option, but of IK Bone Constraint as well. I can’t confirm very well, because, differently from the X & Z Axes, the Y Axis, when we play with Limits on the Inverse Kinematics Panel, do not have a ‘drawing’ like the ‘arcs’ (of Limit X or Limit Z) or ‘shield’ (of Limit X & Z combined), making it harder to track down the motion of the Y Axis Rotation / Roll.

Maybe there’s even a bug? It’s very hard to tell for me, but you’re idea, of devising a system which can manipulate the Roll / Y Axis Rotation ‘Stiffness’ in a more dynamic way… seems very intriguing. Maybe, some combination of Shift / Ctrl / Alt + Mouse Wheel Scroll? for all Bones in the Auto IK Length? I’ll be thinking; they might work instead of an absolulte way, a relative way (‘temporary Pose adjustments’), on top of the original values set up for each Bone’s Y ‘Stiffness’, but which might still respect Limit Y Min/Max (if this is Enabled).

[TheLittleMouse]

You are right. It does. However, one other problem still persists. I can’t move a foot bone to any position in Auto IK, while I can in standard IK. It feels like I’m blocked from moving to certain positions while using Auto IK.

[paulhanson2000]

Maybe your foot bone is not connected to your calf bone?

Currently, Auto IK only works on the bones in a connected chain, whereas a standard IK constraint can extend through any bones as long as they have a parent-child relationship (even if they are not connected).