Committed w/ minor edits, thanks.
Fri, Sep 18
When testing, I came across this assert:
BLI_assert failed: ...\source\blender\modifiers\intern\MOD_solidify_nonmanifold.c:2441, MOD_solidify_nonmanifold_modifyMesh(), at 'loop_index == numNewLoops'
BLI_assert failed: ...\source\blender\modifiers\intern\MOD_solidify_nonmanifold.c:2440, MOD_solidify_nonmanifold_modifyMesh(), at 'poly_index == numNewPolys'
Made requested changes.
On one hand I think this is a really handy operator that could speed up this workflow a lot. However, I wonder if this is solving the problem in a way that's too specific to this situation.
@Germano Cavalcante (mano-wii), not sure how performance is related to the out of memory exception?
This problem is caused by the new blender subdivision modifier which is unfortunately slow with non-quad faces.
It is already known issue and will be addressed with the tasks:
T60733: Subdivision Surface Performance Degrades Markedly With Non-Quad Meshes
T73564: Adaptive subdivision modifier takes to much memory
Thu, Sep 17
Default metal_shiny.exr matcap worked great here, I can reproduce easily by sculpting in area displayed in your second image.
Wed, Sep 16
It seems unlikely that someone will work on this before the new hair type is usable. Therefore, I'll reclassify this as known issue.
not a bug, caused because you had 0 scale on z, and was solidifying to the z (local) direction
Tue, Sep 15
It seems to be a problem related to the one described in T73344: Modifiers disabled in viewport are not rendered if the object is in edit mode.
But perhaps the cause is entirely different.
So I am confirming this as another bug.
Mon, Sep 14
I will fix this in the upcoming days hopefully. I would rather change complex solidify to fit simple solidify even when the behaviour of simple solidify was strange. Otherwise older files using that feature would need versioning to be converted to the new version. (which would not be that big of a deal, if someone has a strong opinion on this let me know).
Fri, Sep 11
Ok should I start / open another ticket for the crash?
Thu, Sep 10
Thanks but I just found a bug with that to if I try and change the "Thickness" value more than twice It causes Blender 2.91.0 alpha to fully crash. But it is an Alpha
Note that exact calculation are considerably slower than simple floating point boolean operations and if the solidify modifier is producing a self intersecting mesh, you will also need to enable the "self" checkbox on the boolean or it still won't work. Enabling self intersections is also MUCH slower. Expect to wait like 15-30 seconds.
In both those gifs "mode" still set to "simple." Try "Exact."
The issue is still happening using the version you told me to try see animation / video attached / File
Please download development build from https://builder.blender.org/download/ and use exact solver method on boolean modifier. Does that olve your issue?
Yes, the 'self' option was added very recently and is intended to solve exactly this case: when one of the operands has self intersections. One might argue that this should be the default but it results in slower execution, so for now am not making it the default.