Modifier are still evaluated even when not required. #95198

New Issue

yoann · 2022-01-25T15:43:10+01:00

yoann commented

2022-01-25 15:43:10 +01:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.13

Blender Version
Broken: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: f1cca30557
Worked: never

Short description of error
Modifiers are evaluated, even when blank, for example a lattice modifier without any lattice, would still make depth graph calculation or something like that, that make each action (select, move, rotate, etc.) verry slower.

Exact steps for others to reproduce the error
Create/ import a large object (60M poly mesh for example).
Add lattice modifier, let all option blank.
Disable viewport visibility of this modifier.
Try to move/rotate/scale the object in the viewport, the performance is really low.

In order to transform your mesh, you need to remove all modifiers, and add then back once transform is convenient.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.13 **Blender Version** Broken: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: `f1cca30557` Worked: never **Short description of error** Modifiers are evaluated, even when blank, for example a lattice modifier without any lattice, would still make depth graph calculation or something like that, that make each action (select, move, rotate, etc.) verry slower. **Exact steps for others to reproduce the error** Create/ import a large object (60M poly mesh for example). Add lattice modifier, let all option blank. Disable viewport visibility of this modifier. Try to move/rotate/scale the object in the viewport, the performance is really low. In order to transform your mesh, you need to remove all modifiers, and add then back once transform is convenient.

yoann commented

2022-01-25 15:43:10 +01:00

Added subscriber: @softyoda

Philipp Oeser commented

2022-01-25 16:25:57 +01:00

Added subscribers: @Sergey, @dr.sybren, @lichtwerk

Philipp Oeser commented

2022-01-25 16:25:57 +01:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Philipp Oeser commented

2022-01-25 16:25:57 +01:00

@Sergey, @dr.sybren: is there a reason why we add a DEG relation to own transform (even if the modifier does nothing really?)

See DEG_add_modifier_to_transform_relation in updateDepsgraph of the lattice modifier (but also many other modifiers : Curve etc).


diff --git a/source/blender/modifiers/intern/MOD_lattice.c b/source/blender/modifiers/intern/MOD_lattice.c
index 29d1ecf6050..0b702a41375 100644
--- a/source/blender/modifiers/intern/MOD_lattice.c
+++ b/source/blender/modifiers/intern/MOD_lattice.c
@@ -101,8 +101,8 @@ static void updateDepsgraph(ModifierData *md, const ModifierUpdateDepsgraphConte
   if (lmd->object != NULL) {
     DEG_add_object_relation(ctx->node, lmd->object, DEG_OB_COMP_GEOMETRY, "Lattice Modifier");
     DEG_add_object_relation(ctx->node, lmd->object, DEG_OB_COMP_TRANSFORM, "Lattice Modifier");
+    DEG_add_modifier_to_transform_relation(ctx->node, "Lattice Modifier");
   }
-  DEG_add_modifier_to_transform_relation(ctx->node, "Lattice Modifier");
 }
 
 static void deformVerts(ModifierData *md,

Above seems to work correctly and gets rid of the lag in following file:
#95198.blend

@Sergey, @dr.sybren: is there a reason why we add a DEG relation to own transform (even if the modifier does nothing really?) See `DEG_add_modifier_to_transform_relation` in `updateDepsgraph` of the lattice modifier (but also many other modifiers : Curve etc). ``` diff --git a/source/blender/modifiers/intern/MOD_lattice.c b/source/blender/modifiers/intern/MOD_lattice.c index 29d1ecf6050..0b702a41375 100644 --- a/source/blender/modifiers/intern/MOD_lattice.c +++ b/source/blender/modifiers/intern/MOD_lattice.c @@ -101,8 +101,8 @@ static void updateDepsgraph(ModifierData *md, const ModifierUpdateDepsgraphConte if (lmd->object != NULL) { DEG_add_object_relation(ctx->node, lmd->object, DEG_OB_COMP_GEOMETRY, "Lattice Modifier"); DEG_add_object_relation(ctx->node, lmd->object, DEG_OB_COMP_TRANSFORM, "Lattice Modifier"); + DEG_add_modifier_to_transform_relation(ctx->node, "Lattice Modifier"); } - DEG_add_modifier_to_transform_relation(ctx->node, "Lattice Modifier"); } static void deformVerts(ModifierData *md, ``` Above seems to work correctly and gets rid of the lag in following file: [#95198.blend](https://archive.blender.org/developer/F12823330/T95198.blend)

Demeter Dzadik commented

2022-01-25 16:43:28 +01:00

Added subscriber: @Mets

Demeter Dzadik commented

2022-01-25 16:43:29 +01:00

Our lighting artist has also been running into an issue for the past couple of days when working on a complex scene where duplicating lights and some other actions causes tremendous lag.

We found out just now that enabling Simplify fixes the issue, so I suspect that the bug behind this report might be the cause of our issue as well. Do you think that could be the case, based on what you've found out? Duplicating an object causing a scene-wide re-evaluation of all objects' modifiers? Or would that be a separate issue?

Our lighting artist has also been running into an issue for the past couple of days when working on a complex scene where duplicating lights and some other actions causes tremendous lag. We found out just now that enabling Simplify fixes the issue, so I suspect that the bug behind this report might be the cause of our issue as well. Do you think that could be the case, based on what you've found out? Duplicating an object causing a scene-wide re-evaluation of all objects' modifiers? Or would that be a separate issue?

Sergey Sharybin commented

2022-01-25 17:01:54 +01:00

@lichtwerk, not much more reasons other than how the original code was handling things before we took over. Guess was never really a priority to look into because why would one have lattice modifier which doesn't have lattice deformed assigned,, right? ;)

Think the suggestion you brought up in the patch is fine to have implemented for lattice and curve modifiers. Just add some comment explaining that without lmd->object the modifier is disabled, so for the performance reasons relation on the own transform is ignored.

@Mets, duplicating lights should not cause modifiers re-evaluation. If it does, it will be caused by some other root cause. Please make sure the slowdown is reported as a separate task.

@lichtwerk, not much more reasons other than how the original code was handling things before we took over. Guess was never really a priority to look into because why would one have lattice modifier which doesn't have lattice deformed assigned,, right? ;) Think the suggestion you brought up in the patch is fine to have implemented for lattice and curve modifiers. Just add some comment explaining that without `lmd->object` the modifier is disabled, so for the performance reasons relation on the own transform is ignored. @Mets, duplicating lights should not cause modifiers re-evaluation. If it does, it will be caused by some other root cause. Please make sure the slowdown is reported as a separate task.

Bastien Montagne commented

2022-01-25 17:09:09 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2022-01-25 17:09:09 +01:00

@Mets This sounds very similar to #94609 (Modifiers are always reevaluated when using an image texture data-block), maybe good to check this report first? especially the file added in one of the latest comment, https://developer.blender.org/T94609#1291980

yoann commented

2022-01-25 17:22:05 +01:00

Yes, my bug report wasn't about any light, but it also related to this #94609 as it recalculate modifier when not needed.

I opened this bug not only because the lattice modifier get recalculated when no lattice is selected, but also because it gets recalculated :

when you first add the modifier (and no object is selected),
when you disable the real-time display modifier in viewport,
when you add another object in the scene (even if the large object where the disabled lattice modifier with no lattice is in a disabled collection, it still slows the file the time the calculation is done (and the more your object is large, the longer it takes, with photogrammetry it takes too much time to work conveniently, even with a lot of patience,
when you remove the object that have the lattice modifier (it may still exist in undo memory) the viewport is still slow (for example entering edit mode is really fast, exiting edit mode still is a bit slow)

Yes, my bug report wasn't about any light, but it also related to this #94609 as it recalculate modifier when not needed. I opened this bug not only because the lattice modifier get recalculated when no lattice is selected, but also because it gets recalculated : - when you first add the modifier (and no object is selected), - when you disable the real-time display modifier in viewport, - when you add another object in the scene (even if the large object where the disabled lattice modifier with no lattice is in a disabled collection, it still slows the file the time the calculation is done (and the more your object is large, the longer it takes, with photogrammetry it takes too much time to work conveniently, even with a lot of patience, - when you remove the object that have the lattice modifier (it may still exist in undo memory) the viewport is still slow (for example entering edit mode is really fast, exiting edit mode still is a bit slow)

kursad k commented

2022-01-26 07:20:46 +01:00

Added subscriber: @kursadk

kursad k commented

2022-01-26 07:20:46 +01:00

I think that this might be related as well, having a super dense multires object also seems to affect the scene performance whether it is the active object or not.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Modifier are still evaluated even when not required. #95198