- User Since
- Mar 20 2014, 5:04 PM (392 w, 2 d)
Tue, Sep 14
Note: the normals on the objects are inverted. After recalculating them, the modifier works without any issue.
Tue, Aug 31
Blender assumes that the unit scale in the .stl is in meters, and scales it correctly according to that.
However, the de facto standard is to use millimeters (which is used by most slicers).
Sat, Aug 28
(Please remember to provide a simplified case for bug reports in the future. Most included objects are unnecessary. Also include a description of what you expected to see instead, since that isn't immediately apparent.)
Aug 26 2021
Try testing this with a alpha version of Blender 3.0: https://builder.blender.org/download/daily/
It has most likely been fixed already. Blender 2.93 is known to have issues.
This is working as expected.
If you only want to remove self intersections, you can set the operand type to "Collection" instead. (See the manual: https://docs.blender.org/manual/en/latest/modeling/modifiers/generate/booleans.html)
Jun 28 2021
Looking through the code, handling negative scale is intended to work.
See for example the checks for is_negative_m4(object->obmat) in MOD_boolean.cc.
@Howard Trickey (howardt)
I disagree. The old behavior was both consistent and useful:
- When an object is scaled to a negative scale, the outside is kept as the outside (i.e. the normals are automatically flipped). This applies both to viewport display (as seen if the Face Orientation Overlay is activated) and rendering.
- It is useful for mirroring linked duplicates (by scaling them with a negative scale. I do this all the time in my workflow.). If the new behavior is kept, there is no longer an easy way to use those.
Seems to be a duplicate of T89391.
Jun 24 2021
I think I may have found a simpler case, with just 3 cubes. Maybe that helps?
Jun 23 2021
Changing priority to high, since this is a recent regression.
Jun 21 2021
@Howard Trickey (howardt) I think this would be for you.
Mar 12 2021
I've opened the file, unhid all the collections and objects, and switched to rendered preview, however, it doesn't seem to crash.
No reply for two weeks.
@Bird (Countty) The download seems to be unavailable.
You can upload files here directly via drag and drop (,or by clicking the cloud icon with the up arrow in the text editor).
Jan 11 2021
Jan 7 2021
Yes, just draw with the draw brush.
The things in parentheses are not steps, they are what happens.
I just remembered this one: T80174.
It may be related.
Jan 6 2021
Jan 5 2021
Dec 16 2020
I'd like to note that this bug was not about it actually crashing, but about it being very slow.
So this is not the same as the bug it was merged with.
Dec 10 2020
I get the same result as @Stanislav Blinov (radcapricorn).
Dec 6 2020
Okay, I must have misinterpreted something here, it appears the crash was indeed due to running out of memory.
The crash happened in source\blender\blenlib\intern\mesh_intersect.cc:trimesh_nary_intersect() in the call itt_map.reserve(tri_ov.overlap().size());.
I have tried this again with a debugger attached. At the time of crash, Blender has only allocated a total of ~4GB.
I will try to investigate further.
Nov 27 2020
I cannot confirm.
Does this only happen with high poly meshes? In that case you might be running out of memory.
Nov 26 2020
I would argue that this is not a bug.
The mesh does not describe a closed volume; its normals are pointing in the wrong way.
The exact boolean seems to detect this and flips the normals back.
Nov 25 2020
Nov 21 2020
Nov 15 2020
Nov 12 2020
This is not considered a bug.
Nov 11 2020
@Howard Trickey (howardt) Can this be reopened? I'm still getting the same wrong result with the latest 2.91 beta (2.91.0 4960780d76bf-windows64).
Nov 8 2020
I've been checking this with the latest builds from the buildbot: 2.91 beta 46da8e9eb958-windows64, 2.92 alpha 7be47dadea50-windows64.
I also built the latest master 39012146e142bf400c7140d90ecfd27c45b589ca myself.
Maybe there is a misunderstanding here:
I'm not talking about the long stretched flat faces that remain, the issue is that a part of the mesh on the right disappears.
This seems to have been fixed in part recently.
Nov 6 2020
No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.
Nov 2 2020
I can confirm that this no longer crashes, but the object disappears instead.
Oct 26 2020
I can confirm with 2.92.0 alpha e4728d0a167c
Oct 25 2020
First, try if updating the driver fixes the issue, see here for more information: https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html
I cannot reproduce.
Following your instructions, everything works correctly.
Oct 23 2020
renamed Empty to None
Oct 22 2020
Oct 20 2020
I'd also like to note that the root of the issue seems to be happening at the sampling (pressing S).
You can see that in the image editor the lines from wireframe disappear and it looks like it's drawn with "optimal display".
Oct 18 2020
Note that the crash doesn't seem to happen if there is not Image Editor open.
Oct 16 2020
Oct 12 2020
Oct 11 2020
Oct 9 2020
Not a bug, as far as I can tell.
This report does not contain all the requested information, which is required for us to investigate the issue.
Please submit a new report and carefully follow the instructions.
Oct 5 2020
Sep 25 2020
(tested with blender-2.91.0 0106e17f07fe linux64)
Not a bug.
The cap object has modifiers that are disabled in the viewport but enabled for render.
Sep 15 2020
Sep 2 2020
I can confirm that the file above also fails.
Though this probably has a different cause than the original bug here.
I have simplified the file further and isolated the step where it fails:
Aug 31 2020
Aug 29 2020
Jul 30 2020
Keep in mind that calculating the volume reliably can only work on manifold meshes.
The default Suzanne mesh is not manifold.
Jul 27 2020
@Demeter Dzadik (Mets) @Roman (roman13)
Keep in mind that this will not work with Curve objects, since they have another hidden matrix that the python api does not take care of.
(E.g. doing o.matrix_world = o.matrix_world will also move an object, rather than doing nothing.)
Jul 11 2020
Jul 3 2020
I cannot reproduce.
blender-2.90.0- 5a13f682ee5f -linux64
Jul 2 2020
I wrote a patch.
Tested with commit 85980743b058e287f1d6400a64dcc60f87fad000
Date: Thu Jul 2 10:16:54 2020 -0600
I cannot reproduce this.
Jun 27 2020
Jun 26 2020
This is not a finished implementation, right?
I believe there are multiple other places, where def_nr is changed, which would destroy the sorting.
Jun 19 2020
Jun 18 2020
Probably the same bug: T75846
Back then we were unable to reproduce.
Jun 17 2020
I'm sorry, but Blender 2.79 is not being patched anymore.
May 17 2020
May 5 2020
@Jason Boycott (BlenderPlebe) If you have found a bug, please report it as a new bug.
Apr 29 2020
@Richard Antalik (ISS) Did it actually crash for you when not using a debugger?
Apr 26 2020
Apr 24 2020
Apr 20 2020
@Richard Antalik (ISS)
I was starting with the CLOUD CHARACTER TRAINING 11.blend.
I do not know of a way to reproduce it from scratch.
Apr 18 2020
I can confirm that after using the "Cut"-brush (Crease), and then Undo, some faces turn green.
No faces are deleted.
Maybe this is related to face sets somehow?
Apr 2 2020
@Jonathan Lampel (jonathanl) In what sense is it broken? If you used 32 bit float textures, it should be ok.
If you plug in the result of a diffuse bake into an Emission shader (with strength 1.0), it should show the exact same result as if you just rendered with the original shader (disregarding specular).
Always applying the view transform would destroy that.
Apr 1 2020
I think this is the intended behavior.
Mar 24 2020
I just tried with a self-built master b759857825b80af98621c2ff4b52f106ab79576c Tue Mar 24 14:02:16 2020 +0100
and with the alpha from builder.blender.org 94b8166a8b05
Feb 24 2020
I ran with --factory-startup