Boolean modifier defaults to Exact mode, causing Blender freeze with high poly meshes. #84666

New Issue

Ludvik Koutny · 2021-01-13T11:20:37+01:00

Ludvik Koutny commented

2021-01-13 11:20:37 +01:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79

Blender Version
Broken: version: 2.91.0, branch: master (modified), commit date: 2020-11-25 11:06, hash: b50598bc78
Worked: (newest version of Blender that worked as expected)

Short description of error
Boolean modifier now defaults to Exact mode, which is so slow it often freezes Blender for such a long periods of time it's indistinguishable from program crash.

Exact steps for others to reproduce the error

Open any .blend file with high poly mesh (1.5M+ polygons)
Duplicate the mesh and move it to intersect with the original mesh
Add boolean modifier on it and select original mesh as the boolean modifier object
Result: Blender freezes for extremely long time, making it appear it has crashed.
Expected: As a means of error/crash prevention, boolean modifier should default to fast mode, with exact mode having to be explicitly selected.

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79 **Blender Version** Broken: version: 2.91.0, branch: master (modified), commit date: 2020-11-25 11:06, hash: `b50598bc78` Worked: (newest version of Blender that worked as expected) **Short description of error** Boolean modifier now defaults to Exact mode, which is so slow it often freezes Blender for such a long periods of time it's indistinguishable from program crash. **Exact steps for others to reproduce the error** 1. Open any .blend file with high poly mesh (1.5M+ polygons) 2. Duplicate the mesh and move it to intersect with the original mesh 3. Add boolean modifier on it and select original mesh as the boolean modifier object Result: Blender freezes for extremely long time, making it appear it has crashed. Expected: As a means of error/crash prevention, boolean modifier should default to fast mode, with exact mode having to be explicitly selected.

Ludvik Koutny commented

2021-01-13 11:20:37 +01:00

Added subscriber: @Rawalanche

Robert Guetzkow commented

2021-01-13 12:10:04 +01:00

Added subscribers: @howardt, @rjg

Robert Guetzkow commented

2021-01-13 12:10:05 +01:00

Changed status from 'Needs Triage' to: 'Archived'

Robert Guetzkow closed this issue

2021-01-13 12:10:05 +01:00

Robert Guetzkow commented

2021-01-13 12:10:05 +01:00

It's a trade-off between quality and speed. You generally have to consider the complexity of your mesh when using modifiers, you can equally run into issues with e.g. the subdivision surface or remesh modifier if the base mesh is complex.

I have close the ticket because this is not a bug, but an intentionally chosen default. If you would like to discuss the current defaults, I would suggest to either write a post on DevTalk or contact @howardt on blender.chat.

It's a trade-off between quality and speed. You generally have to consider the complexity of your mesh when using modifiers, you can equally run into issues with e.g. the subdivision surface or remesh modifier if the base mesh is complex. I have close the ticket because this is not a bug, but an intentionally chosen default. If you would like to discuss the current defaults, I would suggest to either write a post on DevTalk or contact @howardt on blender.chat.

Ludvik Koutny commented

2021-01-13 13:57:35 +01:00

In #84666#1092643, @rjg wrote:
It's a trade-off between quality and speed. You generally have to consider the complexity of your mesh when using modifiers, you can equally run into issues with e.g. the subdivision surface or remesh modifier if the base mesh is complex.

I have close the ticket because this is not a bug, but an intentionally chosen default. If you would like to discuss the current defaults, I would suggest to either write a post on DevTalk or contact @howardt on blender.chat.

The issue here is that you are defaulting mode which will cause Blender to freeze on even high end hardware with meshes of what's today considered quite regular polycount. So you are basically defaulting to more or less crashing behavior without any means of error prevention whatsoever. Other, more mature software usually has some form of error prevention, which either warns you before running such action, or allows you to interrupt the action during the processing. But since Blender does not have any form of this kind of error prevention, it's just inappropriate to default to this behavior.

Since Blender UI completely freezes during modifier calculations, it's not possible to save .blend file during the freeze and will likely result in work/data loss for the artist.

This also comes with more implications. If you are working with high poly meshes and boolean modifier set to fast mode, when you duplicate the said modifier, it will still freeze/crash blender because the newly duplicated modifier is initialized to exact mode, before being switched to fast one. So there are currently multiple actions related to boolean modifier which can freeze Blender and result in data loss.

> In #84666#1092643, @rjg wrote: > It's a trade-off between quality and speed. You generally have to consider the complexity of your mesh when using modifiers, you can equally run into issues with e.g. the subdivision surface or remesh modifier if the base mesh is complex. > > I have close the ticket because this is not a bug, but an intentionally chosen default. If you would like to discuss the current defaults, I would suggest to either write a post on DevTalk or contact @howardt on blender.chat. The issue here is that you are defaulting mode which will cause Blender to freeze on even high end hardware with meshes of what's today considered quite regular polycount. So you are basically defaulting to more or less crashing behavior without any means of error prevention whatsoever. Other, more mature software usually has some form of error prevention, which either warns you before running such action, or allows you to interrupt the action during the processing. But since Blender does not have any form of this kind of error prevention, it's just inappropriate to default to this behavior. Since Blender UI completely freezes during modifier calculations, it's not possible to save .blend file during the freeze and will likely result in work/data loss for the artist. This also comes with more implications. If you are working with high poly meshes and boolean modifier set to fast mode, when you duplicate the said modifier, it will still freeze/crash blender because the newly duplicated modifier is initialized to exact mode, before being switched to fast one. So there are currently multiple actions related to boolean modifier which can freeze Blender and result in data loss.

Howard Trickey commented

2021-01-13 14:49:31 +01:00

Added subscriber: @ideasman42

Howard Trickey commented

2021-01-13 14:49:31 +01:00

I liked/lobbied-for the default of Exact because it is a better choice for, especially, new users who often are confused/file bugs when they try things that involve exact overlaps of faces or edges and find they don't work. Also it was a way to make sure that the code was tried and bugs found on initial release.

I am not wedded to this, and really I should not be the one with final say here. Added Campbell to see if he thinks the default should be changed.

I will note several things:

this is a general problem: some modifiers/modifier settings can cause too much computation on high poly meshes, and there is no way to cancel/turn off the application of the modifier after it has begun
I hope for the speed of Exact to be within a factor of, say 4, of the speed of Fast. And generally seem to achieve that. For instance, I have two spheres of 250,000 quads each and when I intersect them with Boolean, it takes 11.6 seconds with Exact, 3.7 seconds with fast (a debug build on a mac). I haven't tried 1.5M face spheres yet, but will do so as I am continuing to performance tune towards that goal. So if I achieve that goal, if it "takes forever" with Exact, it will "take forever" with Fast too, more or less.
But two things stand in the way of the previous statement. First, the current fallback method used if the model is not a manifold, volume-enclosing one, can be very slow for Exact. I am working right now on fixing that. Second, I haven't done memory tuning yet, and it is quite possible that the reason for the "takes forever" is that the user's machine is running out of physical memory, and resorting to swapping. This might argue for making Fast the default, since it will likely always use less memory.
A workaround for the problem (not great, I know, but just to say...): after adding a modifier, but before adding the modifier operand object, change the solver to Fast and/or hit the button to disable the evaluation of the modifier in display

I liked/lobbied-for the default of Exact because it is a better choice for, especially, new users who often are confused/file bugs when they try things that involve exact overlaps of faces or edges and find they don't work. Also it was a way to make sure that the code was tried and bugs found on initial release. I am not wedded to this, and really I should not be the one with final say here. Added Campbell to see if he thinks the default should be changed. I will note several things: - this is a general problem: some modifiers/modifier settings can cause too much computation on high poly meshes, and there is no way to cancel/turn off the application of the modifier after it has begun - I hope for the speed of Exact to be within a factor of, say 4, of the speed of Fast. And generally seem to achieve that. For instance, I have two spheres of 250,000 quads each and when I intersect them with Boolean, it takes 11.6 seconds with Exact, 3.7 seconds with fast (a debug build on a mac). I haven't tried 1.5M face spheres yet, but will do so as I am continuing to performance tune towards that goal. So if I achieve that goal, if it "takes forever" with Exact, it will "take forever" with Fast too, more or less. - But two things stand in the way of the previous statement. First, the current fallback method used if the model is not a manifold, volume-enclosing one, can be very slow for Exact. I am working right now on fixing that. Second, I haven't done memory tuning yet, and it is quite possible that the reason for the "takes forever" is that the user's machine is running out of physical memory, and resorting to swapping. This might argue for making Fast the default, since it will likely always use less memory. - A workaround for the problem (not great, I know, but just to say...): after adding a modifier, but before adding the modifier operand object, change the solver to Fast and/or hit the button to disable the evaluation of the modifier in display

Robert Guetzkow commented

2021-01-13 14:51:02 +01:00

This comment was removed by @rjg

*This comment was removed by @rjg*

Ludvik Koutny commented

2021-01-13 17:46:50 +01:00

@howardt I agree with most of what you say. If Exact mode had sufficient performance, that would solve majority of the issue. I am aware of the workaround to always select Fast first, that's what I am doing. My issue is that I've already lost work several times due to forgetting that one crucial step of this workaround. I often gave blender up to 10-15 minutes, much more than the time from last autosave of manual save, but it never finished. So ultimately, there should be at least some effort to prevent extremely long freezes.

Ludvik Koutny commented

2021-01-15 12:14:03 +01:00

@howardt Another day, another lost work:

When attaching multiple high poly objects together using boolean, the room for error is incredibly large. I've remembered to click fast button and set mode to union on 2 modifiers. On 3rd one, I just accidentally missed the order of operations, where instead of setting the boolean mode, setting the solver setting the operand object, I set the operand object before solver and froze my blender for what's now been over 15 minutes.

Come on, you can't be punishing users so hard for each error they make. This is really poor design. Software should always default to error prevention, and error mitigation. But Blender in many places actually defaults to increasing room for error, and then exacerbating the effects of the consequent error.

@howardt Another day, another lost work: ![image.png](https://archive.blender.org/developer/F9580266/image.png) When attaching multiple high poly objects together using boolean, the room for error is incredibly large. I've remembered to click fast button and set mode to union on 2 modifiers. On 3rd one, I just accidentally missed the order of operations, where instead of setting the boolean mode, setting the solver setting the operand object, I set the operand object before solver and froze my blender for what's now been over 15 minutes. Come on, you can't be punishing users so hard for each error they make. This is really poor design. Software should always default to error prevention, and error mitigation. But Blender in many places actually defaults to increasing room for error, and then exacerbating the effects of the consequent error.

Tim commented

2021-05-16 10:31:05 +02:00

Added subscriber: @Dandjix

Tim commented

2021-05-16 10:31:05 +02:00

As a new blender user I must say that, to me fast mode is wayyyy more instinctive. I havent ran into any problems using it till now, I dont really understand why exact mode makes the target object simply disappear most of the times and I really wish fast was the default cuz I always use it.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Boolean modifier defaults to Exact mode, causing Blender freeze with high poly meshes. #84666