[Bf-committers] Carve vs. Bmesh booleans

Howard Trickey howard.trickey at gmail.com
Wed Apr 18 17:04:18 CEST 2018


Thanks Kai.
I am actively working on trying to improve the Bmesh booelans. This is
useful input.

- 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
> possible
> 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
> should
> not be nitpicky about the given input mesh. It should basically work for
> the
> 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
> cases
> in production and provide solutions for that. We have used Carve for this
> in
> the past and analyzed and utilized its behavior to make that possible,
> thus my
> tests include all those possible variants.
>
> Results:
>
> My first impression was that Bmesh is doing quite well now. It produces
> more
> predictable results for non-manifold targets and even for some manifold
> ones.
> Here are my observations:
>
> 1. Bmesh is leaving free edges in non-manifold results (well visible in
> orange
> 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
> thing
> in a higher sense, but I know that this is limiting factor for some users
> (see
> inverted normals variants which would flip results in Carve).
>
> 3. As a result of 2. Bmesh can produce meshes with inconsistent normals as
> it
> 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
> Bmesh
> could be more consistent with Carve in general but it should at least
> output
> clean results. We have no "make normals consistent" modifier in Blender
> for
> instance to fix normals within a modifier stack.
>
> I'm aware that these are not necessarily considered being bugs, so I'm
> just
> putting it here for discussion and making you aware of that. Maybe it can
> even
> be helpful for the Code Quest.
>
> Best regards,
> Kai Kostack
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list