@Daniel Genrich (genscher) sure, I don't have any objections. Indeed, as far as I know none of the El Topo code is actually being used anywhere. I'm currently a bit out of time to look at that, but feel free to remove this stuff if the core devs agree with that.

This update fixes/improves several things:

• Fixed the scaling issue.
• Improved culling behaviour, which previously suffered from some ambiguity.
• Implemented auto-detection of bone length, and a reset operator (when used with non-bones, it just resets to a distance of 1.0).
• Fixed RNA property, which was allowing for negative distances.

I discovered that this isn't working when the target has a scale transformation... I'll fix that as soon as I have some time.

Indeed I forgot to update the presets, sorry about that. Regarding revised values, yes I could set some better ones, though it is a tricky matter, as cloth in Blender is unfortunately still mesh density dependent. Because of that, the presets can be extremely misleading, as people might get vastly different results, depending on polygon density. But in any case, I can make the values a bit more reasonable, as they are currently not very suitable for most cases anyway.

@Brecht Van Lommel (brecht), thanks for all the helpful reviews! And sure, I'll compile some tests together, as soon as I can.

Ok, one last update... Hopefully...

I have implemented the self collision distance versioning.

Oh, right. That's because the self collision distance is even out of range for the new system. The new system uses actual distance for the self collision, while it was a factor for the old system, so the old default of 0.75 causes a huge amount of BVH overlap results, and makes everything collide. I'll just add versioning to bring that down to the new default.

Sorted all the issues I had found.

I found a couple of reliability issues, which I am looking into, and will get sorted ASAP. I'll update this patch as soon as I resolve these problems.

@Brecht Van Lommel (brecht), I forgot to mention, regarding continue_physics.blend not settling, there is another factor at play. The old collision system caused the cloth to be solved twice whenever collisions were found, and it applied both those solves to the cloth, causing it to move twice as fast, so that explains why you might see it settling sooner with the old system. Also, this should explain why more steps are needed to get reliable collisions in the cloth.blend file, as the old solver was effectively using twice as many steps (though the order in which collisions are applied is also a factor here, and I might actually revise the way I'm doing that).

Indeed I had a typo in impulse clamping, that caused it to be ignored. I fixed that now.

Thanks for looking at it, @Brecht Van Lommel (brecht).

Added versioning for the removed booleans (required subversion bump). Renamed "Property Scaling" to "Property Weights", as discussed with @Brecht Van Lommel (brecht) and @Alexander Gavrilov (angavrilov) in IRC. Also renamed the "Collision" panel to "Object Collision", to avoid any impression of it being a superset of the "Self Collision" panel (forgot to do that in the original patch).

Small update to fix issues raised by @Brecht Van Lommel (brecht). Thanks for the quick review!

Volume distribution of particles is currently quite a mess, and the issues go far beyond voxel textures, it actually often fails even just with a mesh.
Particles and caching are subject to an overhaul in 2.8, so we are limiting the work on the current system to only regressions.
Thanks for the report, but as this is not a regression, archiving it for now.

Hm, seems the issues here go much further than described. Besides not generating consistent amounts of fluid, the animated version causes the fluid to have a gigantic cavity, essentially turning it into a hollow "shell" of fluid.
From a quick look at the code I didn't get to any conclusion, but then again, I'm not familiar with the Elbeem code at all. This will require some more digging.

Can confirm. With new DEG, bone motion freezes when changing the IK length, and second attempt at moving causes crash.

Confirmed. Something in nlastrip_evaluate_controls is causing this.

Seems in your area @Bastien Montagne (mont29).

Just saw this revision now, didn't catch the notification for this :|
This looks fine. Just note that the same should be done for the opposite case... Setting the end frame lower than the start frame should also lower it.