• Remove unnecesary lines of code added in the process of figuring

Re-implement state->curve_length

I've reimplemented the factoring for curve/chain length. However,
My implementation isn't quite right, either. I think it is closer
than the old one. I've left the print statements in for now, so
that anyone who tries this patch can see the effect.

Anyhow, it's clear to me that even if I scale the ctime paramater
where_on_curve correctly based on the length of the chain in
edit mode and the length it would be if it were set to
Fit To Curve, the result will be "wrong". I need to find out how
to measure the error and adjust accordingly.

Why is this happening? I think it is because the actual WS distance
between two points on a curve is hard to predict. I'm starting to
think it's not possible to solve this problem without using
sphere intersection, a bisect search, or some sort of iterative
method to get the exact value.

• Account for individual segment error;

I've added some code to account for the error in each individual

segments' length. This makes the result of the constraint much
more accurate. It still isn't perfect, but it's a huge improvement
over the original behavior.

In my next commit I will attempt to make this bit of code iterative until the error is below some arbitrary threshold.

Note: I'm not sure this is the right approach, to be honest! I've come around full-circle to thinking that evaluating the curve as a mesh and doing a sphere intersection is the right thing to do, but I don't know how to do that in C. I could write up a Python mock-up, though.

• Segment Length compensation is now iterative.
• Formatting

I think this really does solve the bug completely, but I think it is an ugly solution to the problem. The error values are now well below the four-significant-figure threshold that I use to check my own work. As long as it works, I can use it for my own needs, regardless of whether it's a pretty solution 😏 !

I know that I need to correct a lot of code style things. my next commit will be a make format and then after that I will need feedback from more experienced developers, since I don't know how to do some of the improvements I still want to do. In particular -- cleaning up anything in the math, using Infinity in the spot where it is needed, and Float Epilson or whatever instead of the 0.00001f.

Finally, I think that it's possible to calculate all of this a single time when initializing the tree, but right now most of the calculation occurs for every bone that is evaluated, every time. I don't know how to make the dynamic-length list I would need for this (It would need to be the length of the number of bones in the chain... and from what I understand structs need to have a known, fixed size when they are defined).

• Remove prints and a commented-out line of code.

If you want to check the logic, I can add them back in.

Here is the test file used in the images above.

• Added sanity checks and tweaked some values
• Format

• Address comments, organize and clean up code

Still to do:

• create a unit test and update the manual.
• test corner cases
  • Specifically -- if the error for a segment *increases* when trying to correct it, then it should fall back to the value it had before any corrections were made. This can happen in cases where the curve is deformed in an extreme way.
• experiment with another method
• clean, clean, clean.

• Revert to master and rename the IK state's curve_scale to adjustment
• Rename IK Tree's points to more descriptive joint_bindings
• Implement new joint binding algorithm that sets the joint bindings so that the initial pose will not scale the bones, modify adjustment code to use the new adjustment calculation correctly.

Specifically:

• First, check if the curve is available,
• Then, for each bone, search forward in the curve to find the bounds for the binary search (since there could be two or more points on the curve that intersect the circle, we want only the first one.)
• Once the bounds have been set, do a binary search until exactly the correct point is found. If the bounds are not set correctly, this result may be wrong, although this is unlikely.
• Once the joint bindings are set, they are adjusted again in the case of "Even Divisions" -- this does not attempt to factor in bones' length, although I can make it average the length of the bones' first and then calculate the joint bindings with the average length of all of the bones instead of the length of the current bone. This is a design detail that I haven't thought about much.
• At this point, the joints are bound. In splineik_evaluate_init, to adjust the curve, we compare the length of the segments between the spline-segments with the length of all of the bones together -- when the curve is in rest-pose, this value should be exactly 1.0. When the curve is posed, it will change.
• in the evaluation function, finally, there's a small change to the way adjustment works. Now, instead of scaling the joint bindings down, since they were always normalized to 0.0-1.0 before, we can scale them up or down depending on the situation. For example, if Fit To Curve is enabled, then the values are normalized and used directly. Otherwise, they are adjusted by adjustment (and by posescale if Bone Original is enabled). This will be 1.0 if the rig is in rest pose, but it will be more or less if it isn't.

This is a pretty difficult behavior to explain succinctly, so feel free to poke me in blender.chat with questions. Anyhow, there's still a lot of testing and checking to do - sanity checks, testing for corner cases, etc. As an added bonus, we can use a similar method to get exact bone-scale preservation if needed (this method only 100% guarantees the bones' scale when the rig is in rest pose).

EDIT: I can confirm that this crashes in some cases, e.g. changing a shape-key on the curve... will have to spend some time carefully enumerating these situations and solving the problems. Probably won't be able to spend much time on this for a few days, goal is to have a 💯% fix by Dec 17th meeting.

• Updated NULL check, should be more reliable now;

• Added some code that hacks around a bug that seems to occur non-deterministicly, and some commented-out-code for demonstrating the bug.

To elaborate:
I think I've fixed the T81704. Fixed. Solved. Terminated. However, because my fix relies on runtime data to do anything, it sometimes doesn't work. Part of the reason is, sometimes the runtime data isn't there. That's no good! But the other part of the problem is -- sometimes the NULL check is passed, but it fails later on in another function or code-block. If you un-comment my test and compile it, you'll see that the iteration where the NULL-check fails is random and non-deterministic. Someone in blender.chat suggested it may be due to another thread.

Anyways, the worst thing that this can do is create error messages in the console that should be suppressed. The real problem is that runtime data doesn't seem to exist until some user-interaction in the UI. I'm not sure if this is reliable within Python, for instance. I wish there were a way of getting the data without relying on runtime, or at the very least, to keep a copy of it around to use instead, in case there isn't a valid runtime for use immediately.

I think I'm at the point where I donno what else to do. I think my solution to the bug is essentially the right way to do it, unless we decide to use a mesh-approximation of the curve, instead. Making it work without any hitches will require changes to other parts of Blender, maybe even depsgraph code, and I don't feel comfortable doing that without guidance.

OH! I also think the behavior is still bad if the chain is longer than the curve.. will need to investigate that situation further.