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

New Issue

Vyacheslav Kobozev · 2020-01-17T16:15:47+01:00

2020-01-17 16:15:47 +01:00

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.

**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](https://archive.blender.org/developer/F8283208/2020-01-17_18-02-50.mp4) **Exact steps for others to reproduce the error** - Open [#73199-testboolean.blend](https://archive.blender.org/developer/F8296702/T73199-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.

Vyacheslav Kobozev commented

2020-01-17 16:15:47 +01:00

Added subscriber: @Vyach

blender-admin commented

2020-01-17 16:15:47 +01:00

#102361 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#88332 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#81871 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#80892 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#79693 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#79147 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#79047 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#77956 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#71490 was marked as duplicate of this issue

blender-admin commented

2020-01-17 16:15:47 +01:00

#75646 was marked as duplicate of this issue

Richard Antalik commented

2020-01-20 19:39:01 +01:00

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

Sybren A. Stüvel commented

2020-01-23 11:00:03 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-01-23 11:00:03 +01:00

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.

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 commented

2020-02-19 14:43:51 +01:00

Added subscribers: @Sergey, @mont29

Bastien Montagne commented

2020-02-19 14:43:51 +01:00

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

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

Sergey Sharybin commented

2020-02-19 15:02:07 +01:00

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.

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.

Vyacheslav Kobozev commented

2020-02-22 03:16:07 +01:00

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

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

Philipp Oeser commented

2020-04-13 11:10:10 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-04-13 11:10:10 +02:00

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

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](https://archive.blender.org/developer/P1162.txt) 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...]

Philipp Oeser commented

2020-04-13 11:12:54 +02:00

Added subscribers: @hadrien, @VincentBlankfield

Sybren A. Stüvel commented

2020-04-14 11:20:58 +02:00

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

Philipp Oeser changed title 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

2020-04-14 11:26:26 +02:00

Philipp Oeser commented

2020-04-14 11:28:11 +02:00

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

Hadrien Brissaud commented

2020-04-14 12:07:21 +02:00

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.

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.

Vyacheslav Kobozev commented

2020-04-22 00:05:35 +02:00

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.

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

Evan Wilson commented

2020-06-17 19:56:14 +02:00

Added subscriber: @thomason1005

Vyacheslav Kobozev commented

2020-06-25 20:25:09 +02:00

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

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](https://archive.blender.org/developer/F8644026/untitled.blend) [2020-06-25_20-18-32.mp4](https://archive.blender.org/developer/F8644025/2020-06-25_20-18-32.mp4)

Matt commented

2020-06-26 02:08:59 +02:00

Added subscriber: @mattli911

Richard Antalik commented

2020-07-21 05:01:18 +02:00

Added subscriber: @jaggz

Karja Krähwald commented

2020-08-03 09:39:25 +02:00

Added subscriber: @karja

Vyacheslav Kobozev commented

2020-08-08 18:29:39 +02:00

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.

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](https://archive.blender.org/developer/F8759575/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.

Dalai Felinto commented

2020-08-10 13:02:22 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2020-08-10 13:02:22 +02:00

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.

Vyacheslav Kobozev commented

2020-08-10 18:11:29 +02:00

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

Richard Antalik commented

2020-09-28 10:17:19 +02:00

Added subscriber: @3di

Richard Antalik commented

2020-10-22 19:13:39 +02:00

Added subscribers: @viadvena, @iss

Vyacheslav Kobozev commented

2020-10-29 07:16:15 +01:00

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.

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

Vyacheslav Kobozev commented

2020-11-06 16:02:25 +01:00

I suppose, this is the same issue.
2020-11-06_17-56-43.mp4

I suppose, this is the same issue. [2020-11-06_17-56-43.mp4](https://archive.blender.org/developer/F9218933/2020-11-06_17-56-43.mp4)

Aleksandr commented

2020-11-07 13:59:44 +01:00

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

Jaggz H commented

2020-11-07 17:50:45 +01:00

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.

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.

Jarek Staniek commented

2021-04-23 15:42:32 +02:00

Added subscriber: @jstaniek

Jarek Staniek commented

2021-04-23 15:42:32 +02:00

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

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

Vyacheslav Kobozev commented

2021-04-23 17:26:03 +02:00

@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

@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

Philipp Oeser commented

2021-05-18 13:30:02 +02:00

Added subscriber: @vasiln

Germano Cavalcante changed title from ~~Switched off modifier still recalculates if there is second one, that switched on~~ to Object referenced in a disabled modifier still force the other modifiers on the stack to update

2022-02-10 16:58:33 +01:00

Hans Goudey commented

2022-02-16 22:35:48 +01:00

Added subscribers: @HooglyBoogly, @lone_noel

Enzio Probst commented

2022-03-16 16:35:00 +01:00

Added subscriber: @EnzioProbst

Jaggz H commented

2022-04-10 05:34:09 +02:00

[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

[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

Germano Cavalcante changed title from ~~Object referenced in a disabled modifier still force the other modifiers on the stack to update~~ to Editing an object that is referenced in a disabled modifier (of another object) forces the other modifiers on the same stack to update

2022-05-30 14:14:45 +02:00

Pratik Borhade commented

2022-11-09 07:24:23 +01:00

Added subscribers: @kursadk, @PratikPB2123

Soeren Schmidt-Clausen commented

2023-01-26 10:52:10 +01:00

Added subscriber: @F_Scociety

Philipp Oeser removed the

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