[Bf-committers] Carve vs. Bmesh booleans
howard.trickey at gmail.com
Wed Apr 18 17:04:18 CEST 2018
I am actively working on trying to improve the Bmesh booelans. This is
- Howard Trickey
On Wed, Apr 18, 2018 at 12:38 PM Kai Kostack <kaikostack at gmx.net> wrote:
> Dear Blender devs,
> After the removal of Carve for booleans, which is an important part of the
> Fracture Modifier, I did some tests with Bmesh booleans to find out the
> differences and what we need to change in order to make FM work with that
> system. I'd like to share some of my observations and maybe discuss
> improvements for consistency with you.
> Overview: http://pasteall.org/pic/a7286dabbb2f49f71dc548d5653f5720
> Blend file: http://pasteall.org/blend/index.php?id=49342
> (Note that you need an older Blender build with Carve)
> Our premise always was to make the Fracture Modifier a robust tool that
> not be nitpicky about the given input mesh. It should basically work for
> artist at all times. This means the FM should also accept and work with
> non-manifold, self-intersecting and complex meshes which are typical use
> in production and provide solutions for that. We have used Carve for this
> the past and analyzed and utilized its behavior to make that possible,
> thus my
> tests include all those possible variants.
> My first impression was that Bmesh is doing quite well now. It produces
> predictable results for non-manifold targets and even for some manifold
> Here are my observations:
> 1. Bmesh is leaving free edges in non-manifold results (well visible in
> in the lower right), those should be removed after operation.
> 2. Bmesh is not face normals aware. I'm not sure if this is good or bad
> in a higher sense, but I know that this is limiting factor for some users
> inverted normals variants which would flip results in Carve).
> 3. As a result of 2. Bmesh can produce meshes with inconsistent normals as
> keeps the original normals of the operator object but ignores them for the
> actual boolean operation (row 3 and 6).
> This is what I could see, maybe there are more differences. I think that
> could be more consistent with Carve in general but it should at least
> clean results. We have no "make normals consistent" modifier in Blender
> instance to fix normals within a modifier stack.
> I'm aware that these are not necessarily considered being bugs, so I'm
> putting it here for discussion and making you aware of that. Maybe it can
> be helpful for the Code Quest.
> Best regards,
> Kai Kostack
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers