Page MenuHome

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

Related Objects

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".Feb 19 2020, 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.

Isnt this the same as T71490: All modifiers are recalculated because of one that is disabled.?
Also had a play there with adding relations conditionally (but not the complete way as @Sergey Sharybin (sergey) suggested...), see P1162

If these reports should be merged [I think they should], should we do it by merging T71490 into this one? [comments here are much more to the point...]

I think merging T71490 here is a good idea indeed.

Philipp Oeser (lichtwerk) renamed this task from Switched off Boolean modifier still recalculates if there is second one, that switched on to Switched off modifier still recalculates if there is second one, that switched on.Apr 14 2020, 11:25 AM

Thanks for the merge I wasn't sure the issue affected all modifiers.

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.

That makes sense. I imagine depsgraph can't evaluate relations up to the point where it knows whether or not the modifier is enabled (if driven/animated), and then decide to evaluate it or not ? Surely you've explored this already, probably pointless to suggest it.

In any case, I know I would benefit greatly from this optimization : for most scenes my modifiers' states are usually static (that wouldn't apply to character rigs). My exact case is, I have a short script that checks for a specific lattice modifier on all mesh objects and toggles it to gain performance - at least that's what I expected to happen, but performance stays the same hence the bug report.

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.

Yep, It looks smart and proper way to fix it. Anyway In most cases modifiers are static.
I will wait this great improvement.

Idk if it is correct place, but I have this bit of info about modifiers unnecessary recalculation,
may be it can help to check Blender`s behavior more precisely.


Here is another example. Even if you apply Subsurf, switched Mirror will be calculated on every move. You can test it with this file (if lags are not so noticable — increase subdiv)

2.79 has small but noticable slowdown in this case. 2.9 have heavy lags.

Is it the same problem? It is very annoying, and become more dramatic, because mirror duplicate geometry instead instancing it.

Hi @Vyacheslav (hitrpr) - this is already marked as known issue, so although more information can help, the report already has all the information a developer would need to look at it. In your case you can just report your issue as a new bug, and the triaging team can handle the investigation and eventually merge the tasks if it comes to that. Just please refer to this task when opening a new one.

@Dalai Felinto (dfelinto) Got it! I thought this was exact the same issue, so I didn`t new report. But if U suggest so, I'll try.

Vyacheslav (hitrpr) added a comment.EditedOct 29 2020, 7:16 AM

But that' s an optimization rather than a bug fix.

Of course optimization/design.
But very important optimization, that will affect total performance much.
I hope, this will be fixed once.

I suppose, this is the same issue.

Crucial Bug! With bugs like this one Blender stay too far from proprietary apps. It's confusing me how often new releases coming but bugs that corrupt whole workflow isn't resolving for so long. I hope devs will take all efforts to squash this bug and others.

If we can flag modifiers as targets/dependencies of drivers, that could allow at least a workable solution.

In fact, if that's possible, a little notification of it being such a target would be useful, maybe with a mouseover:
"This modifier (or its visibility) is controlled by drivers. It will still be calculated even if you disable its visibility."

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.

Fi>>! In T73199#876123, @Sergey Sharybin (sergey) wrote:

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.

My thoughts 16 months later: fixing critical performance degradation versus animation features.
It depends how we define meaning of the visibility. If we separate the "viewport/design-time" meaning of the visibility flag from the "animation/render-time" visibility we might find a solution at conceptual level.

Is it true that Blender 2.7 or older had no such issue or not so clearly noticeable? As a heavy user of booleans with hi-poly I remember using the modifier visibility was a help there (as well as for subdiv, etc).

@Jarek Staniek (jstaniek) so changing driver-values should also count as «animation time».
As stupid person I can`t understand why checking modifier == executing modifier.

but to know that we need to evaluate dependency graph.

Then, there should be parallel method to check it without touching depsgraph.
Or even just memorize, whats animated/drivered and what is not, and only check it on load.
Then update only when user make something animated