[Bf-committers] Carve vs. Bmesh booleans

Kai Kostack kaikostack at gmx.net
Wed Apr 18 14:38:13 CEST 2018

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

More information about the Bf-committers mailing list