Page MenuHome

Boolean Difference works like Boolean Union - modifier bug
Confirmed, NormalPublicBUG


System Information
Operating system: Windows 10 pro
Graphics card:

Blender Version
Broken: (example: 2.80, edbf15d3c044, master, 2018-11-28, as found on the splash screen)
Worked: (optional)

Short description of error
When i follow the cup tutorial from MASTERING DRIVERS ON BLENDER 3D in the 2.8 version, using a wireframe cube on target of boolean in difference mode, after move down on Z the difference work like union function.

Exact steps for others to reproduce the error
Based on the default startup or an attached .blend file (as simple as possible).

Event Timeline

The modifier seems to work correctly for me. It could be a bug in the wireframe shader or in your graphics driver. Are you using the latest driver? Can you upload your system-info file (Help > Save System Info)?

matc (matc) lowered the priority of this task from 90 to 30.Aug 2 2019, 8:13 PM


Same here but :
I have a complex mesh i want to clean and was using boolean to cut parts out.

  • load the mesh (4 millions vertices)
  • add cube and scale to match the part i need to erase
  • select the mesh and add boolean modifier
  • choose difference mode and select the cube

Result : the cube is beeing added to the mesh (tried 4 times)

Strange enough :

  • i quit blender
  • using the default scene
  • tried with the default cube and duplicated it and added a boolean modifier

-> Everything ok

  • import my complex mesh and added the cube to clean it
  • add the cube and booblean modifier with difference mode

-> everything is ok !

Blender 2.8.1 alpha
macOS 10.14.5
Macbook Pro 15" 2018 core i9 2,9 Ghz
Radeon Pro 560X 4 Go
Intel UHD Graphics 630 1536 Mo

Bastien Montagne (mont29) raised the priority of this task from 30 to 50.

Confirmed, when moving the cylinder up at some point the solution from the modifier gets wrong...

@Howard Trickey (howardt) since you are interested in that feature iirc, mind having a look? Doesn't look like the usual coplanar issues...

I can't tell how to reproduce this problem. Does the attached blend file (mastering drivers copo.blend) have anything to do with reproducing the bug? From the screenshots, it looks like you are just doing a boolean of a cube with a smaller cylinder. I don't know what it means to say that you have a "wireframe cube" -- do you just mean that the display is set to wireframe? When I try a cube and a cylinder, in wireframe display mode, it works ok for me.

The second report (from Bo) is too vague for me to reproduce.

@Howard Trickey (howardt) Move the small cylinder up, at some point boolean op seems to switch from diff to union (generating a geometry that contains both part of the cylinder outside of the cube, and the cube itself). This happens before the cylinder is actually fully moved inside of the cube (no idea what is supposed to happen once cyclinder is fully inside of the cube, but the result before it gets there is definitively not right for me).

Looks like somehow the Y axis is relevant. Moving/resizing of either object along the Y axis makes the glitch disappear. Rotation around any other axis than Y makes the glitch disappear too.

I still can't make this happen. Can someone who can make this happen please upload a simple .blend with a cylinder and cube with boolean modifier set to difference where the result of the boolean is the union rather than the difference?

Although, I have to say, my rewrite of Boolean will use a different method for deciding what is in the boolean output after intersecting, so if this problem looks hard to fix then I am likely to leave it unfixed until the new boolean is ready.

matc (matc) added a comment.EditedAug 21 2019, 8:53 PM

Steps to reproduce the file:

  1. Delete everything from default scene
  2. Add Cylinder
  3. Add Cube (Will not work with default cube.)
  4. Scale Cube by 3
  5. Scale Cube by 0.5 along Z axis
  6. (optional, but better visibility) Set Cube 'Viewport Display' to 'Display As: Wire'
  7. Add Boolean modifier to Cylinder with 'Target: Cube'
  8. Move Cube along Z axis (somewhere between -0.5m and 1.5m)

Note: Order of steps does not really matter, but the scaling dimensions are somehow crucial.

Edit: Behaves in 2.79 the same.

I downloaded this file and uploaded to blender 2.81a and yes its working as union but is difference selected. Im working a lot with booleans and Yes this is happening to me a lot of time. Thank You all for great work for improve this. I cant wait to see new boolean

Here is a simplified version of the file created by matc. The difference is that I created the cylinder with only 3 sides, which hopefully will make it easier to pinpoint the bug. I intend to have a look at the bug myself, as I've run into this many times, but I'm new to the blender code so I cannot give any guarantees.

Interesting fact: If you slide the top face of the cube in the z-direction, when it reaches 3m the modifier suddenly behaves correctly.
Also interesting: as soon as you change the Y-scale of the cube, which in theory should have no effect at all, the modifier also behaves correctly. Changing the X-scale makes no difference at all though.

To rule out that the scale was filled in incorrectly somewhere, I recreated the same meshes with all scales set to 1. This shows the exact same issues:

So, I've delved into the code a bit and found that isect_bvhtree_point_v3 appears to give the wrong result for the first face. I'm not sure why yet. But if you call BM_face_calc_center_median just before that call, it considers it a 'no hit', making the issue disappear, whereas the with the existing code, which calls BM_face_calc_point_in_face, it does consider it a hit and the issue shows. Mind you, calling BM_face_calc_center_median cannot be the correct fix. BM_face_calc_point_in_face does return a valid point inside the given face, just a different one than the median, so something else must be wrong. Investigating isect_bvhtree_point_v3 requires some understanding of the BVH tree, which is a bit out of my league, but I'll do my best.

OK, I the problem is indeed that isect_bvhtree_point_v3 gives the wrong result. It determines whether a face is inside or outside a given object by casting a ray and counting the number of intersections of that ray with the object. If the number is even, it must be outside the object, if it is odd, it must be inside. A complicating factor here is that there may a small error in the calculation, which can make it difficult to determine this number of intersections correctly.
I think I have a fix for this, but I'm not 100% sure it is correct, so it may not pass code review.

Aaron Carlisle (Blendify) changed the subtype of this task from "Report" to "Bug".

My initial diagnose was incorrect. I initially thought that isect_bvhtree_point_v3 gave the wrong result because the it found two intersection points that were so close together that they were incorrectly considered to be identical. The actual problem is that the ray exactly hits an edge of the cylinder, which is not recognized as such.