I've encountered some issues myself as well. I'm looking into this.

This has been committed together with D4436 in rB871248a77d8a9ae7dbb43ef28f3802601cbfe5c6

For future reference, note that while the commit message doesn't mention it, this commit also includes the changes from D4345 (probably should've been a separate commit). This causes the bleed behaviour to continue brush strokes into the bleed, instead of just extending the pixels at the boundary.

I have submitted my further changes as separate patches (D4436 and D4437), as they are really independent changes, that can selectively be applied, and are not directly related to the change made in this patch.

Yep, the problem is the gcc version. Centos is not happy with glibc 2.24. Therefore I'm building with gcc 4.9, but even still, the libstdc++ version is slightly too new for Centos.

Oh, I see what you mean. That makes sense.

The increase in portability is significant. With static libstdc++, builds will run in RHEL/Centos 7, for example.

@Brecht Van Lommel (brecht), I don't think a pixel dilate operation would work well in this case. It would disregard brush strokes, and bring back the issue that this patch fixes. We don't want the bleed to just stretch the pixels at the edges outwards, instead, the bleed should reproduce as closely as possible what happens on the other side of the seam.

This is fixed by @Rombout Versluijs (rombout) and @Philipp Oeser (lichtwerk) in rBf572a157ba7846940012271a030de89db0a93c33.

@Campbell Barton (campbellbarton), indeed it would be nice to get some more feedback. I wrote this patch because of troubles I was having myself when texture painting, and I can say that I found them to be significant enough, even on higher density meshes. This change has generally improved results, though I still have some issues in corners, where the naive UV extension can cause slight overlap problems.

Thanks for taking a look at this.

@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.