Page MenuHome

Switched off Boolean modifier still recalculates if there is second one, that switched on
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Operating system: Windows-7-6.1.7601-SP1 64 Bits
Graphics card: GeForce GTX 660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 441.20

Blender Version
Broken: version: 2.82 (sub 6), branch: master, commit date: 2020-01-15 21:07, hash: rB689a873029b9

Short description of error
When there are two Boolean modifiers, and the second one is disabled, editing its shape still recalculates the Boolean operation if the first one is enabled.
Even when both modifiers are disabled, editing their shapes is slower than editing the same shape that is not targeted by a Boolean modifier.

As an example:

Exact steps for others to reproduce the error

  • Open (or add two cubes, make a dense mesh, add Boolean modifiers to the dense mesh each targeting a cube).
  • Switch off a single Boolean modifier.
  • Edit the mesh that is targeted by that Boolean modifier. This is slow.
  • Switch off the other Boolean modifier.
  • Edit the same mesh as above. This is now much faster.
  • Add a third cube and edit it. This is still faster than in the previous step.

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Jan 20 2020, 7:39 PM

I've replaced the example file that's slightly easier to use for debugging:

  • Renamed the cube objects so that they have a sensible name (I won't remember which one was Cube.002 when looking through the depsgraph plots, so Cube.LeftBool makes more sense)
  • Removed the add-on overrides from the workspaces. I didn't expect these, and was wondering why my debugging add-on wasn't showing.
  • Removed non-essential workspaces now that I was looking at workspaces anyway.
  • Removed the subdivision modifier from the cube (by applying it) so that there are only modifiers that are relevant to this report.

I can confirm the reported behaviour, and IMO it's indeed a bug. The performance of editing the Cube.LeftBool mesh should IMO be independent of whether the boolean modifier targeting Cube.RightBool is active.

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Known Issue".Wed, Feb 19, 2:43 PM

Issue here is that for the depsgraph, it has no knowledge whether the modifier is disabled or not, so it keeps following the rules established by the relations generated in updateDepsgraph() modifier's callback.

We could imagine something like calling DEG_relations_tag_update() when enabling/disabling a modifier's "visibility", and then check in the various updateDepsgraph() callbacks whether modifier is enabled or not... But that does not seem to go along current design really, updateDepsgraph() is not even aware of evaluation context at all currently (which makes sense).

Think we need depsgraph mastermind lights here before we do anything, @Sergey Sharybin (sergey)?

Also, this is definitively not a bug, things are working as expected in current design afaikt, and not how simple it will be to change that behavior..

This is indeed a known issue.

There is no easy solution here, since modifier "visibility" can be driver/animated. So if we want to be smart and completely remove relations from disabled modifiers then we will very quickly run into feedback loop: we need to know whether modifier is enabled or not during dependency graph construction, but to know that we need to evaluate dependency graph.

One possible solution is to have heuristic similar to collections: ignore collections which are not visible and which visibility is not animated/driven. But that' s an optimization rather than a bug fix.

@Sergey Sharybin (sergey)
Anyway, I'll be happy with such optimisation, because mostly I work with static scenes and sculpts.