Pro and cons of custom IK solver (with maya nodes) vs Maya Ik solver?

1

While playing around to create a custom IK solver ( well thanks to Cult of Rig i started playing with it..) , given maya 2026 has all the new fancy nodes (pow, acos etc) so i did not use expressions to create the solver .

I was testing this solution against maya native ik , i loaded 500 referenced rigs with regular IK vs Custom IK ,and essentially got the same FPS (felt faster the custom one ), which gave me the spark to pursue this as a possible solution as i was concerned with the rig performance.

So i was wondering have you ever done something like this in production?
is it a viable solution to get away from using maya old IK system ? Or is too fancy and not worth the troubles?

Pros and Cons ?

Is fun to learn about it , but I’m wondering if is it worth investing time onto it , to then use in rig production?

I want to stay within vanilla maya nodes (not custom solver plugin ) due to the ease of compatibility for anyone using the rigs.

so far a few pro:

  • can create a cleaner hierarchy and NO need to use joints to solve the ik
  • can add extra nodes to customize the IK (soft bend, stretch etc)
  • possibly reusing some of the nodes to simplify/optimize calculations of other things (stretch, elbow pin etc)

cons :

  • if accidentally screw up the math on some nodes attrs..the whole rig wont work
  • harder to debug
  • its a few extra nodes compared to the standar IK (which has 3 ish?), although it jumps already up if you start adding fancy add-ons..so might end up being similar?

Just curious what are your thoughts on this, if you already went this way and stick to it or regret it.

ps: i did think of creating a custom bifrost solver..but i am unsure of performance currently, and it seems still too young still, perhaps in the near future ?

2

The hit of a rig is almost always gonna come in deformation. Calculating 30 math nodes for an IK solution vs running 5 matrix multiplications for each of 50,000 points, and blending them (even on a GPU). So my take is that rig speed won’t be the thing you optimize for in this case as long as its Good Enough™. Rigger interaction will be more important.

And I don’t think any rigger would want to build that kind of setup by hand in a production rig. I know I’d certainly want it scripted out. And that gets rid of your “accidentally screw up” con replaced with “you’ve gotta script it out to be useful” :slight_smile:

Another con for an IK solver in nodes: You can’t use numerical methods. One of the best IK solvers I ever messed with did everything with an iterated approach. One solver handled an entire leg: hip to toes, but it took about 100 loops to converge in extreme cases.

And if you’re doing something for a real production: Don’t discount the custom node solver. Yeah it feels clean to do it just using built-in maya nodes, but nodal programming for math equations is terrible for anything as complicated than the quadratic formula, and it just gets worse from there. XSI’s ICE was way better than maya nodes for visual programming (Not sure how Bifrost stacks up to it. I haven’t retried Bifrost recently), but we still did the IK solver as a compiled plugin back when we worked in XSI. And productions will have mechanisms to distribute plugins.

If you’re trying to sell a rig, though, “no plugins required” could definitely be a selling point.

2 Likes
3

Thank you Mr Fox! Always very helpful reading your replies!

You are absolutely right, the setup itself it is scripted (so not manual madness), the screwing up bit would be mostly in “accidentally added features that could potentially break some stuff i haven’t thought about..yet” ahha ( i saw this happen in a few places)

For now i wanted to keep it “no custom plugins” and see where it goes, as It is easier to get a rig around to people if all they have to do is load the maya scene and play with it.

Iterative IK solver sounds quite another challenge..do you have any good document(that is human readable ? :smiley: )

Also, for anyone wondering, such kind of setup could lead to not needing even joints to make the IK solver work, which technically makes it quite good, as you deal with less nodes to create a standard IK-FK setup, you also get the stretch ability almost for free.

4

Unfortunately I don’t. It’s probably something taken from robotics, though. There’s probably a bunch of papers on this, and reading through those technical papers is absolutely a skill worth developing I think. (I just accept that their math works and ignore the terms I don’t understand. I look for the nuggets of information, or that one last “conclusion” equation/pseudocode. Then when I try to implement it, I’ll naturally come up with questions. And those questions are usually answered earlier in the paper, but I can actually follow the reasoning now that I’ve got an idea of the problem.)

Or maybe another way to think of it is that it’s kind of like a single strand of a hair or cloth simulation? There’s a bunch of tutorials online for that kind of stuff.

This solver allowed for multiple subgoals and pole vectors over any number of joints. I think it solved the primary goal, then modified the intermediate joints to go for the subgoals and pole vectors. Or maybe it solved the subgoals first and modified them to hit the primary goal? I don’t know, but I could see both ideas possibly working.

2 Likes
5

This is a bit more of a general observation than something specific to IK Solvers…

The biggest con I’ve seen in production environments for any type of non-vanilla setup is portability. You never know if halfway through a project you will involve outsourcing teams who then may need access to your studio’s toolchain to use rigs, then suddenly you have to involve IT and legal, and then they may use a different maya version. It’s just a whole ordeal that I prefer to avoid if possible, speaking from experience.

There are of course cases where you want something that’s hard to do with nodes, and way easier to express in code (RBF solvers, convex hull nodes, surface intersections), so to mitigate the portability issue I would try to package rig-related plugin features into their own .mll instead of lumping everything together, if you also have pipeline or export-related plugin code.

1 Like
6

@tfox_TD
That’s quite interesting, thank you for sharing, yes, there are a lot of robotics explanations i found online, perhaps also some python code that might do “the trick”, although is definitely a challenge for another time.

@JoDaRober
Yes that has been also my experience, unless is something that is quite out of the ordinary (some very fancy spline/rigs , dynamic solvers, or completely customized and compiled rigs etc) most places always seems to opt for standard nodes on puppet rigs.
That is also why i started to look into this in the first place, given now maya has way more standard math nodes(finally..) and the given performance of such setup seemed quite comparable with the standard IK, I thought of giving it a spin.

To be completely honest, I was also hoping the autodesk people would’ve given an updated IK and Spline Ik nodes by now, but i guess not in their plans yet.

Thank you for sharing.

7

If all you need is the basic triangular IK, Maya’s normal IK solver is fine - performance can be an issue won’t come into play unless you have on the order of a hundred hinges in a scene or so, in my experience.

HOWEVER, IK and curve framing are the two huge problems that Maya still doesn’t have a great solution to IMO, and if you ever get into more complex mechanical rigs, you’re gonna have a real bad time with native IK, trying to isolate and solve each axis of each joint at a time or however you try and tackle it.

My first ever custom node was an attempt at Cyclic Coordinate Descent here GitHub - rigGitLikeYouDigGit/generalIk: multi-purpose maya node to implement any arbitrary ik solver (it’s trash I’m sorry)

CCD is the most approachable IK algorithm out there - no inverting the jacobian etc, and you natively get support for things like degrees of freedom in joints. It’s equally viable in Bifrost or in custom code, but for other more intense versions of IK you’ll probably start needing Eigen in C++, Bifrost has the same problem as Vex where it’s great with 3x3 and 4x4 matrices, but more clunky for larger ones.

For complex linkages you’ll also run into hysteresis - as it becomes possible to solve a large motion in many poses, you might see snapping in the joints if you try and solve them from rest every time. You can mitigate this by adding sub-goals for intermediate bits of the arm (just like the pole vector on a rotate-plane solver) but I think even that will get unstable as you add joints and degrees of freedom in the system.

So then it becomes a time-dependent problem, almost a simulation, where you might have to save keyframes of a certain pose on the node itself to use as a goal, to stop your animation from changing based on prior motion. In some ways it really is a similar problem to curve framing, just that instead of stability in space along the curve, we want stability in time through the joint poses.

1 Like
8

If you had the time, it might even be easier to start from the simulation approach - instead of special-casing IK, just get a good rigid-body solver and some constraints to set goal positions, even goal orientations. That way you wouldn’t need to special-case mechanical systems or even stuff like HumanIK - it would be more work, but you’d have a general, extensible system to attack any relation between motion.

2 Likes
9

Thank you @EdArt ! Great information, thanks for sharing your code also, its always good to check someone’s code to better understand the actual process.

In case someone is wondering, Bifrost now also has an IK solver node, (i still find it quite complicated to understand using nodes), but is also an interesting thing to study.

It becomes indeed like a simulation of bones, and at that point i started to wonder if a ML node in the future could be the “way to go” approach for complex IK/bone/solvers structures?
Something along the lines of :

  • Users create the structure, sets limits and solutions for all joints
  • ML Trainer, goes through a set of auto poses, cooks for a while, and spits out the data
  • Rig works now with such limits using the data, and it doesn’t really need to calculate much, as its like a cache?

This could also work for fancy stuff, like infinite twists or complex facial, unbreakable shoulders/elbows etc, the td simply fix it manually, adding an extra pose, then re-trains if needs or adds to the data more granularly.

If i remember correctly there are few example of an ik as Bifrost tutorials, although their example ik wasn’t perfectly moving..?(maybe that is the downside?)

1 Like
10

ML might be interesting if you have a good way to generate a lot of valid poses, but I think you’d still run into the flipping issue if you train it on static poses and goals.

I’m not an ML god by any means so sorry if my understanding is lacking, but if you train it to solve from a common start pose to the end, you may still end up with it snapping between 2 valid poses, since they both reach the goal, and that’s all the network wants.

It might be easier to see the ML network as replacing the jacobian inversion to get the derivatives at any pose, to any new pose. So for training pick a load of random start poses, and then train the network on how to move the system to match small deltas from those starts. That way in animation you can continuously pass in the previous frame pose as the start, and this frame as the goal, and as long as there’s no massive discontinuities in the animation, it should be stable.

1 Like
11

Very interesting, i wonder if Autodesk will get out some sort of ML Attributes/Transforms node like they did for the ML deformer (as it should essentially do similar things ?), they seem to be on this new trend?

Maybe specific motions could be split in simpler “parts” each with its own motion-logic, although they could still also be attached to one another , it would be quite interesting to play and compare the two approaches .

ps. Such node would also need to “blend” between points data? For instance if the data has only 3 points, the node would be smart enough to linearly interpolate through those? not sure how it works, although MLDeformer seems to do that, approximating positions where there is not enough data?

12

Such node would also need to “blend” between points data?

Yep, I think that’s how you would do it -

If you imagine the IK system at any static pose, all of its goals (positions, matrices, random distance attributes, whatever you want) will form a base state. For now just imagine the goal is a single position target at the end of the chain.

In training, you’d pick a load of random poses, and then see how changing each joint slightly would change the position of that goal - that relationship to the change in the goal vector, from that pose, is what the network learns.

In actual eval, if you move that target slightly, you’ll again get a goal delta vector - a slight deviation vector from the current goal state, with the same dimensionality. That delta is what you use to interpolate - each pose-delta pair you’ve trained the system on is a data point, and now you’re looking for the best way to move the overall system, to match this desired delta vector. It’s more stable too if you split up the vector into tiny steps, where you run the network, apply any constraints between degrees, then take the new delta vector as ( goal - wherever that iteration got you ).

If you were to literally keep every training pose in memory and try and interpolate them directly, you’d run out of memory very quickly, since the amount of training data goes up geometrically as you add degrees of freedom in the pose.

There’s probably some super-smart way to reduce the amount of info you take from each training pose too - if you consider CCD, it works by considering each joint in isolation as it tries to align them to the goals. Maybe if you split up the delta vector enough during the actual solve, you could do the same here; train each degree separately in how they affect the goals, and try and mash them all together at once during the solve? It would cut down dimensionality hugely, but it depends on parts of the linkage not being too interconnected.
(Off top of my head, if you imagine 2 gears meshing together, this wouldn’t take account of the constraint between them, so you might get quite slow convergence during the full solve, or none at all)

Anyone else feel free to jump in if I start talking rubbish here, like I say I only have a novice’s grasp on this stuff

1 Like