Thank you for the heads up, Greg.

The video was done before some changes were made to the skeleton. Originally the skeleton did not have the IK targets included in the weights, and instead, the upper and lower leg bones were just scaled when needed. Scaling the bones is actually my preferred way to do it, but for demonstration purposes, it was changed. Apologies for not updating the video. It seems with the new YouTube I can't even add an annotation.

More than two bones generally requires using an iterative approach, where bones are continuously adjusted until they reach the target. This is because there are many different solutions which would result in the bones reaching the target, so the solution that should be chosen needs to depend on the previous bone transforms. Two bone IK can be solved analytically, as there are only ever one or two solutions possible. The bend direction eliminates one of the solutions, so we always know the solution to use. The benefits of an analytical solution are that we can apply the animation at any time and know the complete pose. If the pose at a particular time within the animation depends on previous poses, this gets a lot more complicated.

Imagine a game is being serialized, so we record the skeleton was playing animation A at time X. The game is closed and later the player comes back and loads the serialized game state. Without knowing the pose leading up to time X, we can't be sure how to arrange the IK bones. If A is the only animation being applied, we could run through the animation, computing the poses up until time X. If something dynamic was going on (eg the player or environment can manipulate bones), then it isn't possible to know the poses leading to time X. The only solution would be to serialize the entire pose instead of just the animation and time.

Still, we do plan to go down that path in the future. The complexity is not only for IK, but also for physics since that also has dependencies on previous poses, eg to calculate velocity. Physics would be fantastic for easy secondary motion.

Back to stretchyman, certainly the rig could be simplified if there was a feature that provided the same functionality. Though, while the stretchy legs are quite neat, once the IK target goes past the IK bones, you get the leg to stretch in a straight line only which may have limited usefulness. Likely part of why Shiu prefers to use scale to extend the leg is so you don't lose the knee (the latest example project doesn't actually include stretching the leg to the target when it is out of IK range). Also note you can manipulate the path directly for even more control, though of course it is ideal to have the rig behave as you want without a lot of fiddling.

On the topic of fancy rigging, Shiu will have an interesting tentacles rig video available soon.

Haha, there's no secrets. You got it right (even misspelling Søren's name, a favorite pastime

Norwegian names are hard). I think it makes sense to use my name. Everyone else is pretty weird, but they grow on you. S?ren and I were the founders, I'm a coder and he's an artist/animator type. Mario is a coder. Erika is an artist/animator type. You did miss Pharan, our resident Unity guru who is an artist/animator/coder hybrid unicorn.