Editing an object that is referenced in a disabled modifier (of another object) forces the other modifiers on the same stack to update #73199

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: 689a873029

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:

2020-01-17_18-02-50.mp4

Exact steps for others to reproduce the error

Open #73199-testboolean.blend (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.

Added subscriber: @Vyach

#102361 was marked as duplicate of this issue

#88332 was marked as duplicate of this issue

#81871 was marked as duplicate of this issue

#80892 was marked as duplicate of this issue

#79693 was marked as duplicate of this issue

#79147 was marked as duplicate of this issue

#79047 was marked as duplicate of this issue

#77956 was marked as duplicate of this issue

#71490 was marked as duplicate of this issue

#75646 was marked as duplicate of this issue

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

Added subscriber: @dr.sybren

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.

Added subscribers: @Sergey, @mont29

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?

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
Anyway, I'll be happy with such optimisation, because mostly I work with static scenes and sculpts.

Added subscriber: @lichtwerk

Isnt this the same as {#71490}?
Also had a play there with adding relations conditionally (but not the complete way as @Sergey suggested...), see P1162

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

Added subscribers: @hadrien, @VincentBlankfield

I think merging #71490 here is a good idea indeed.

Added subscribers: @FrancoisRimasson, @GabrielMoro, @M.Pivetta, @ZachHixson, @mano-wii

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

In #73199#876123, @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.

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.

In #73199#876123, @Sergey wrote:
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.

Added subscriber: @thomason1005

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.
untitled.blend
2020-06-25_20-18-32.mp4

Added subscriber: @mattli911

Added subscriber: @jaggz

Added subscriber: @karja

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)
MadMirror.blend

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.

Added subscriber: @dfelinto

Hi @Vyach - 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.

@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.

Added subscriber: @3di

Added subscribers: @viadvena, @iss

In #73199#876123, @Sergey wrote:
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.
2020-11-06_17-56-43.mp4

**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."

In #73199#876123, @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.

Added subscriber: @jstaniek

Fi>>! In #73199#876123, @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).

@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

Added subscriber: @vasiln

Added subscribers: @HooglyBoogly, @lone_noel

Added subscriber: @EnzioProbst

[Edited to correct] I presume modifier visibility is rarely used by drivers, although possibly heavily by some users / in some projects.

Perhaps I'm not understanding the implications correctly, but isn't there some balance that can be reached here? What about a default, toggleable from a Modifier's pulldown menu, that INCLUDES it in depsgraph updates (opt-in seems like a good default). Additionally, if you manually add a driver to a visibility/renderability, it can auto-toggle it on for you; however, if you're using python/drivers to "externally" modify it, you have to go turn it on, or have the "default" preference checked.
So, in prefs somewhere: "- [x] Modifier dependency graph test default" <-- no clue what to call this.

Seems like a strange thing to be unable to resolve, and it impacts a lot of people who are working on editing things that are slow with their modifiers, and they only want it later when they enable it, or during render.

In #73199#1151169, @Vyach wrote:
@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

Added subscribers: @kursadk, @PratikPB2123

Added subscriber: @F_Scociety

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Editing an object that is referenced in a disabled modifier (of another object) forces the other modifiers on the same stack to update #73199