Thank you, Dr., for adding me as a subscriber. I am happy to test this patch, maybe it will be the push I need to finish my own patch! If this isn't just a better solution.
Is the aim of this Differential to solve a specific bug report, and if so, which one? Seems to fix T81704, but there's a hitch...

I would have to read this much more carefully to understand what you're doing, but it looks like you are doing the thing I tried with Sphere-intersecting each of the line-segments that make up the curve. IIRC I ran into problems when I tried this when the curve was very jagged. Here's a gif, using this patch, that demonstrates one of the problems we run into.

Also, this currently breaks Fit-To-Curve if the bones are too short in Edit Mode.
EDIT: this has been fixed:)

Eh, it looks like you updated this while I was writing. Will have another build and another look.
EDIT: fixed the fit-to-curve thing, but the gif is still accurate

In D10849#276302, @Joseph Brandenburg (TheAngerSpecialist) wrote:

I would have to read this much more carefully to understand what you're doing, but it looks like you are doing the thing I tried with Sphere-intersecting each of the line-segments that make up the curve. IIRC I ran into problems when I tried this when the curve was very jagged. Here's a gif, using this patch, that demonstrates one of the problems we run into.

I was also running into a problem that crashed Blender when runtime-data was needed but unavailable. Your patch avoids this, it seems.

I don't think there is anyway to avoid that if we truly want to preserve the bone lengths.

To me, it seems like your curve has too steep bends which makes it jump around like that as there is no valid solution that preserves the bone lengths without this discontinuity.
Here for example:

(The red line is the sphere in the first frame and the green line is the sphere in the second frame)

When you move the bone further up the curve, the only valid point the tail can be at is at a point much further along the curve.

Oh, for sure! I understand what's happening here, but I remember having a discussion with Dr. Stüvel and what he told me was that the discontinuous motion would be undesirable for animation... I'd like to have a perfect bone-length preservation option and an option that tries to preserve bone length but also moves continuously. My patch is over-complicated because it tries to do the latter -- it's a surprisingly difficult problem to solve. I still need to clean it up and finish it. IMO both behaviors are desirable to a rigger at different times.

At any rate, I'm really glad to see this getting attention from a Blender-Foundation team member. I think you'll produce a better patch than me :). But I'll be here to help test and stuff.

what he told me was that the discontinuous motion would be undesirable for animation...

That's still true. But if it's caused by some mathematical principle, they'll just have to live with it. It's the same with knee popping -- it's undersirable, but since it's caused by math being mathy, there is little we can do about it.

In D10849#276537, @Sybren A. Stüvel (sybren) wrote:

That's still true. But if it's caused by some mathematical principle, they'll just have to live with it. It's the same with knee popping -- it's undersirable, but since it's caused by math being mathy, there is little we can do about it.

In this case there is no way around it if we are going to preserve the bone lengths.
As you pointed out, if the user presents a problem that do not have a solution that is continuous, there is little we can do.

This could actually be used to see if a road/train track/canal has too sharp turns for a vessel of a certain length to be able to pass!
If the result is continuous, then it will be able to pass (at least in theory) ;)

I think it is useful to preserve bone-length exactly, too. As a rigger, it's nice being able to rely on something to behave predictably. For instance, if the bone-length is preserved exactly then it's fairly easy to calculate the length of the spline-ik-chain in a driver, provided all of the bones are initially the same length (the driver can use bone's original length * y-scale * number of bones in the chain to get the length). Moreover, I think that if you want continuous motion, just add more bones. Spline IK will take up to 255 bones. Dr. Stüvel mentioned knee-popping -- which is the result of "math being mathy" -- but almost every rigger will learn to use a "soft-IK" system to solve this. Workarounds exist for almost any problem. That being said -- it *is* possible to solve T81704 without introducing discontinuous motion. If we correct the way Blender calculates the joint-bindings, then we can adjust the entire spline IK chain instead of individual bones in the chain. This would be similar to the original behavior of the constraint, which has continuous motion, without the bug.
So really, I think that this solves the problem by introducing a new behavior. Maybe there should be a check-box that says "preserve bone scale exactly". Ideally we can choose between adjusting individual joints in the chain, or adjusting the ends of the chain and scaling the joint-bindings along with them.
Finally, I will suggest a situation where the original behavior is good, if only it were implemented correctly: sliding a bone along a chain of bones. Currently, you have to set up a convoluted system of constraints and drivers to do this. It's too heavy a solution for such a simple goal. Using Spline IK, however, you can slide a bone's end along a spline using a single constraint. One additional bone and constraint is enough to place a bone's head at an arbitrary, sliding point on the spline. If you remember Mr. Biped from Humane Rigging, he had a spine which used the former method. This may already be possible with this diff's result, so here's another example: say you have a character with tentacles that need to wiggle, bend, stretch and squash smoothly. Preserving the exact length of individual segments isn't very useful in this case. It's far better for the bones to move smoothly as the chain is scaled up and down. Finally, I worry that if a "pop" can occur in the spline's motion, then it may produce bad motion-blur if it occurs on a sub-frame unbeknownst to the animator. This kind of error can be especially frustrating.
I want to reiterate that I think this solution to the problem is useful and carries the benefit of simplicity. Regardless of where this differential goes, however, I intend to finish my patch since I think that both behaviors are useful.

Anyways, it seems there is still some anomalous behavior. I ran into this before when I tried this, I don't remember if I was able to figure out a solution.

In D10849#276666, @Joseph Brandenburg (TheAngerSpecialist) wrote:

That being said -- it *is* possible to solve T81704 without introducing discontinuous motion. If we correct the way Blender calculates the joint-bindings, then we can adjust the entire spline IK chain instead of individual bones in the chain. This would be similar to the original behavior of the constraint, which has continuous motion, without the bug.

You will have to explain this a bit better, I don't understand how that would work.

I can't see how it would be possible to solve that without introducing discontinuous motion.
If you want to preserve the length of the bones there is no way around it.
The only bone that will have a continuous deform is the first bone in the chain as only the tail will move along the curve.
This will only be true if the curve doesn't change shape and the start point doesn't change though...
Every other bone will have discontinuity issues if the curve has too sharp turns to allow them to slide back and forth smoothly.

I don't see how adjusting the IK chain will fix this.

If you don't preserve the length, then "apply as rest pose" will still have the issue of changing the bone length.

So really, I think that this solves the problem by introducing a new behavior. Maybe there should be a check-box that says "preserve bone scale exactly". Ideally we can choose between adjusting individual joints in the chain, or adjusting the ends of the chain and scaling the joint-bindings along with them.

If there is a use for it, we could indeed introduce a "new" option that instead places the bones at evenly spaced points along the curve.

But I don't think a "preserve bone scale exactly" is the way to go. The manual and tool tip of the current options "None" and "Bone Original" says that is should preserve the length, but it only does so if the curve itself is a straight line.
As it calculates the "distance traveled" along the curve of each bone and not the final "shortest path" from the head to the tail of the bone.

Having a "actually do what is says it should do" checkbox is not good in my opinion.

Anyways, it seems there is still some anomalous behavior. I ran into this before when I tried this, I don't remember if I was able to figure out a solution.

Nice catch! Thanks for testing.

This was because I didn't check if the first test segment was the same as the previous bone segment.
So it could go backwards in the chain if the the tessellated segments were longer than the bones.
I fixed this now! :)

However while testing I also noticed that the curve path does not match with the displayed path.
This was true before my patch and also with other constraints (like the object "follow path" constraint):

Fixing that will be for an other patch though.

I've actually already made a Bug Report for that: https://developer.blender.org/T81707

"Having a "actually do what is says it should do" checkbox is not good in my opinion." I agree, but the other thing that isn't good is naming things incorrectly to begin with, and then making changes to established behavior. to match the name.. although to be fair this is only as old as 2.80 and has always been broken. The only example of anyone using it that I've been able to find is a rig Alexander Gavrilov made for Rigify, which avoids the bug by using a perfectly straight curve. Well, I use it, but I can adapt 😄 I would be thrilled to have to adapt to a bugfix for this.

If you want to preserve the length of the bones there is no way around it.

Yes, this is true -- if you want to preserve the length of every individual bone. You can, however, preserve the length of the *entire chain* relative to the curve, which is what the current behavior is. Or, well, it tries. It has a fatal miscalculation, in that it doesn't take into account the shape of the curve and how, because bones are long and straight, the bones end up being shorter than the curve (which is continuous). This is generally true, and I think it's related to the problem with where_on_path giving different results than the viewport representation of the curve. Unfortunately, since where_on_path is very mathy, I don't understand it well enough to try and fix it myself :/ Well, I have written about it elsewhere.
Here's a mockup I made which uses my patch: https://developer.blender.org/T81704#1058662
And you should keep reading past that a bit to see the Dr.'s and Brecht's feedback. I think I explain what causes the bug a little higher up and also in the comments of my patch.

To explain further: The current algorithm stores "joint bindings" that say how far along the curve each joint should be (as a percentage of a curve, from 0.0-1.0). They are calculated, however, as a percentage of the length of the bone chain. So, in order to make up for the difference, the joint bindings are scaled by a bit, which IIRC is the length of the bone chain divided by the length of the curve. (Now we're at "None" y scale mode. The pose scale is also multiplied with this scaling factor to get to "Bone Original".) Anyhow, this ends up being wrong, because the bone's joint bindings should have been stored relative to the curve to begin with, and they shouldn't be scaled like that.
My working patch, IIRC, solved this problem by calculating the joint bindings relative to the curve and then scaling them only with the pose-scale. It might have been more involved than that, but the only thing it really needs is a way of getting some data from the curve in a way that is guaranteed to work (right now it uses the runtime data which can crash Blender if it isn't available). I probably wrote out my reasoning for everything in comments under the patch, though. In fact, I'd like for you to read a lot of it. I was careful to write it all down because I hoped it would help others (or me, since I tend to work in fits and starts). The problem is that there's a lot and I make a few incorrect guesses that are corrected later. So if you read it, maybe start at the end and read backwards until you have what you need. You'll also see a lot of the errors I make and correct, which will help you to know how to test your patch for corner cases that are hard to find. ( I stopped working on my patch when it reached a point where I could use it in my production in a pinch, and my focus shifted back to my production once the vacation ended. Oh, and I did a distro-hop since then! Perhaps you've motivated me to take it back up, though.)

EDIT:

This was true before my patch and also with other constraints (like the object "follow path" constraint):

IIRC where_on_path is only used by these two constraints and it's the culprit in both of them.
also, here is a link to a description of the way my patch works, so you don't have to search for it. https://developer.blender.org/D9244#243080

@Joseph Brandenburg (TheAngerSpecialist) do you have time to test if everything still works as before?
I had to change the code a bit after my changes to anim_path. It seems to work as before to me, but you can never be too sure ;)

This still works :)