Modifiers are always reevaluated when using an image texture data-block #94609

New Issue

Ludvik Koutny · 2022-01-03T17:37:27+01:00

Ludvik Koutny commented

2022-01-03 17:37:27 +01:00

System Information
Operating system: Windows-10-10.0.19042-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.76

Blender Version
Broken: version: 3.0.0, branch: SelectThrough (modified), commit date: 2021-12-15 12:21, hash: 6349dd43b1
Worked: (newest version of Blender that worked as expected)

Short description of error
Most modifiers, such as remesh, but even Geometry Nodes are triggered to re-evaluate by a large amount, perhaps even a majority, of unrelated scene changes and operations. This makes the entire software extremely slow, sluggish and prone to crashes.

In this particular example, I have a mesh using GN modifier in one collection, and separate mesh in another separate collection. These two meshes do not share any datablocks. They do not share materials, textures, meshes, or even the same collection. Only thing they have in common is a view layer and the root scene collection.

Every time I make almost any scene operation to the objects and collections unrelated to the object with the GN modifier or the collection which contains it, the GN modifier on this object gets evaluated fully anyway, resulting in long freezes, and in this particular instance also a crash:
2022-01-03 17-24-40.mp4

Exact steps for others to reproduce the error

Open the attached blend file: Slow_GN_Update_Repro.blend
Select Roots_Vista mesh, and in the modifier panel, in the GN modifier, set the Detail Level value to 2
Make "Reference" collection active, select SM_HumanRef mesh and try to duplicate it a few times.
Try to enable or disable visibility or selactability of the "Reference" collection
Result: Operations to completely unrelated objects in completely unrelated collection trigger re-evaluation of heavy to calculate modifiers on the scene objects.
Expected: Operations which are not related to (and therefore do not affect) scene objects containing heavy to calculate modifiers do not trigger their re-evaluation.

EDIT: Adding crash report for the crash that happened at the end of the video: Slow_GN_Update_Repro.crash.txt

**System Information** Operating system: Windows-10-10.0.19042-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.76 **Blender Version** Broken: version: 3.0.0, branch: SelectThrough (modified), commit date: 2021-12-15 12:21, hash: `6349dd43b1` Worked: (newest version of Blender that worked as expected) **Short description of error** Most modifiers, such as remesh, but even Geometry Nodes are triggered to re-evaluate by a large amount, perhaps even a majority, of unrelated scene changes and operations. This makes the entire software extremely slow, sluggish and prone to crashes. In this particular example, I have a mesh using GN modifier in one collection, and separate mesh in another separate collection. These two meshes do not share **any** datablocks. They do **not** share materials, textures, meshes, or even the same collection. Only thing they have in common is a view layer and the root scene collection. Every time I make almost any scene operation to the objects and collections unrelated to the object with the GN modifier or the collection which contains it, the GN modifier on this object gets evaluated fully anyway, resulting in long freezes, and in this particular instance also a crash: [2022-01-03 17-24-40.mp4](https://archive.blender.org/developer/F12787150/2022-01-03_17-24-40.mp4) **Exact steps for others to reproduce the error** 1. Open the attached blend file: [Slow_GN_Update_Repro.blend](https://archive.blender.org/developer/F12787166/Slow_GN_Update_Repro.blend) 2. Select Roots_Vista mesh, and in the modifier panel, in the GN modifier, set the Detail Level value to 2 3. Make "Reference" collection active, select SM_HumanRef mesh and try to duplicate it a few times. 4. Try to enable or disable visibility or selactability of the "Reference" collection Result: Operations to completely unrelated objects in completely unrelated collection trigger re-evaluation of heavy to calculate modifiers on the scene objects. Expected: Operations which are not related to (and therefore do not affect) scene objects containing heavy to calculate modifiers do not trigger their re-evaluation. EDIT: Adding crash report for the crash that happened at the end of the video: [Slow_GN_Update_Repro.crash.txt](https://archive.blender.org/developer/F12787182/Slow_GN_Update_Repro.crash.txt)

Ludvik Koutny commented

2022-01-03 17:37:27 +01:00

Added subscriber: @Rawalanche

Ludvik Koutny changed title from ~~Most modifiers including Geometry Node modifier get re-evaluated by many completely unrelated operations~~ to Most modifiers including Geometry Nodes modifier get re-evaluated by many completely unrelated operations

2022-01-03 17:41:29 +01:00

Richard Antalik commented

2022-01-07 04:22:23 +01:00

Added subscribers: @HooglyBoogly, @iss

Richard Antalik commented

2022-01-07 04:22:23 +01:00

@HooglyBoogly I assume you are aware of this issue, can you tell if this is technical limitation? At least for GN. For other modifiers I don't think I could consider this to be a bug unless it is regression or trivial to resolve.

Ludvik Koutny commented

2022-01-07 10:50:27 +01:00

In #94609#1284197, @iss wrote:
@HooglyBoogly I assume you are aware of this issue, can you tell if this is technical limitation? At least for GN. For other modifiers I don't think I could consider this to be a bug unless it is regression or trivial to resolve.

How is triggering a re-evaluation of unrelated scene objects not a bug? When you have a scene object with complex modifier stack which takes multiple seconds to evaluate, and you make changes to completely unrelated object in completely unrelated part of scenes which is not tied to the complex object in any way, why would it have to reevaluate all the already computed data.

Or in other words, it's not possible to work in a scene where most of the scene operations cause your entire software to freeze for multiple seconds at a time.

The only way I could interpret this as not a bug would be if someone intentionally wrote the object evaluation part of the code in such a way that it re-evaluates all the modifier stacks on all the objects every time any operation is done to the scene, regardless of if this operations affects the other objects or not. But such design could never ever result into any usable piece of software.

> In #94609#1284197, @iss wrote: > @HooglyBoogly I assume you are aware of this issue, can you tell if this is technical limitation? At least for GN. For other modifiers I don't think I could consider this to be a bug unless it is regression or trivial to resolve. How is triggering a re-evaluation of unrelated scene objects not a bug? When you have a scene object with complex modifier stack which takes multiple seconds to evaluate, and you make changes to completely unrelated object in completely unrelated part of scenes which is not tied to the complex object in any way, why would it have to reevaluate all the already computed data. Or in other words, it's not possible to work in a scene where most of the scene operations cause your entire software to freeze for multiple seconds at a time. The only way I could interpret this as not a bug would be if someone intentionally wrote the object evaluation part of the code in such a way that it re-evaluates all the modifier stacks on all the objects every time any operation is done to the scene, regardless of if this operations affects the other objects or not. But such design could never ever result into any usable piece of software.

Richard Antalik commented

2022-01-08 04:58:10 +01:00

To be more specific, I would still confirm the issue, but if the issue is present for years, it will be likely classified as known issue instead of bug. It's rather technicality and it's up to module to decide. My intention was rather to provide context to the question.

But in general issues with performance unless it's a regression are not considered as bugs (again this is strictly technical term, it's not to mean, that we don't care). Bugs are generally mistakes or oversights and should be relatively easy to fix. If something is broken for long time, this is usually due to issues with feature design itself and there is no single problem to resolve, so it requires planning, review and tekes longer time in general. These are known issues.

To be more specific, I would still confirm the issue, but if the issue is present for years, it will be likely classified as known issue instead of bug. It's rather technicality and it's up to module to decide. My intention was rather to provide context to the question. But in general issues with performance unless it's a regression are not considered as bugs (again this is strictly technical term, it's not to mean, that we don't care). Bugs are generally mistakes or oversights and should be relatively easy to fix. If something is broken for long time, this is usually due to issues with feature design itself and there is no single problem to resolve, so it requires planning, review and tekes longer time in general. These are known issues.

Ludvik Koutny commented

2022-01-08 10:23:42 +01:00

In #94609#1284764, @iss wrote:
To be more specific, I would still confirm the issue, but if the issue is present for years, it will be likely classified as known issue instead of bug. It's rather technicality and it's up to module to decide. My intention was rather to provide context to the question.

But in general issues with performance unless it's a regression are not considered as bugs (again this is strictly technical term, it's not to mean, that we don't care). Bugs are generally mistakes or oversights and should be relatively easy to fix. If something is broken for long time, this is usually due to issues with feature design itself and there is no single problem to resolve, so it requires planning, review and tekes longer time in general. These are known issues.

I remember reporting something similar some months ago and it was triaged as a bug but eventually closed as I did not provide repro scene in time (it was a complex production scene file I could not share or strip down easily). This time, it also happened in a production file, but in early stage, so it was possible to strip it off all the NDA information and provide it. So it's a bit strange that the last time it was accepted as a bug, but now it isn't :|

Anyway, even if it gets acknowledged as known limitations, it will still be good. What's important is that with the advent of geometry nodes, this issue will become the limiting factor of the GN use, as it will regularly become unfeasible to use Geometry Nodes in scenes because they will slow down the rest of Blender too much.

> In #94609#1284764, @iss wrote: > To be more specific, I would still confirm the issue, but if the issue is present for years, it will be likely classified as known issue instead of bug. It's rather technicality and it's up to module to decide. My intention was rather to provide context to the question. > > But in general issues with performance unless it's a regression are not considered as bugs (again this is strictly technical term, it's not to mean, that we don't care). Bugs are generally mistakes or oversights and should be relatively easy to fix. If something is broken for long time, this is usually due to issues with feature design itself and there is no single problem to resolve, so it requires planning, review and tekes longer time in general. These are known issues. I remember reporting something similar some months ago and it was triaged as a bug but eventually closed as I did not provide repro scene in time (it was a complex production scene file I could not share or strip down easily). This time, it also happened in a production file, but in early stage, so it was possible to strip it off all the NDA information and provide it. So it's a bit strange that the last time it was accepted as a bug, but now it isn't :| Anyway, even if it gets acknowledged as known limitations, it will still be good. What's important is that with the advent of geometry nodes, this issue will become the limiting factor of the GN use, as it will regularly become unfeasible to use Geometry Nodes in scenes because they will slow down the rest of Blender too much.

Ludvik Koutny commented

2022-01-11 14:51:44 +01:00

To add to the severity of this report, even some operations completely unrelated to any scene data trigger the reevaluation, such as maximizing the active editor:
2022-01-11 14-49-42.mp4

To add to the severity of this report, even some operations completely unrelated to any scene data trigger the reevaluation, such as maximizing the active editor: [2022-01-11 14-49-42.mp4](https://archive.blender.org/developer/F12800930/2022-01-11_14-49-42.mp4)

Ludvik Koutny commented

2022-01-17 13:09:40 +01:00

Once again, increasing severity of this bug:
2022-01-17 13-07-03.mp4
When a geometry nodes attribute is being used in a shader, every single viewport operation will freeze Blender for substantial amount of time. Even such benign operations as deselecting the object or box selecting empty space.

This will happen even in workbench viewport, where the shader is not being displayed.

The issue will then persist even if the attribute is removed from shader editor, until Blender is restarted.

Once again, increasing severity of this bug: [2022-01-17 13-07-03.mp4](https://archive.blender.org/developer/F12808397/2022-01-17_13-07-03.mp4) When a geometry nodes attribute is being used in a shader, every single viewport operation will freeze Blender for substantial amount of time. Even such benign operations as deselecting the object or box selecting empty space. This will happen even in workbench viewport, where the shader is not being displayed. The issue will then persist even if the attribute is removed from shader editor, until Blender is restarted.

Hans Goudey commented

2022-01-20 19:26:17 +01:00

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

Hans Goudey commented

2022-01-20 19:26:17 +01:00

Added subscribers: @JacquesLucke, @Sergey

Hans Goudey commented

2022-01-20 19:26:17 +01:00

Next time please take some time to simplify the file in the report. In about 20 minutes I was able to simplify the problem to the following, which is so much easier for any developer to debug.
{F12813060 size=full}

I'm far from a dependency graph expert, but it seems like this might be a fairly straightforward problem to fix if there is an extra dependency somewhere.
@JacquesLucke or @Sergey, maybe the following simple file makes finding the problem easy?

#94609.blend

Next time please take some time to simplify the file in the report. In about 20 minutes I was able to simplify the problem to the following, which is so much easier for any developer to debug. {[F12813060](https://archive.blender.org/developer/F12813060/image.png) size=full} I'm far from a dependency graph expert, but it seems like this might be a fairly straightforward problem to fix if there is an extra dependency somewhere. @JacquesLucke or @Sergey, maybe the following simple file makes finding the problem easy? [#94609.blend](https://archive.blender.org/developer/F12813056/T94609.blend)

Ludvik Koutny commented

2022-01-20 20:04:46 +01:00

In #94609#1291980, @HooglyBoogly wrote:
Next time please take some time to simplify the file in the report. In about 20 minutes I was able to simplify the problem to the following, which is so much easier for any developer to debug.
{F12813060 size=full}

I'm far from a dependency graph expert, but it seems like this might be a fairly straightforward problem to fix if there is an extra dependency somewhere.
@JacquesLucke or @Sergey, maybe the following simple file makes finding the problem easy?

#94609.blend

Huh, I actually tried several times to create a simple repro scene, but I always failed. For some reason I did not understand, I could not reproduce it from the scratch, so I eventually gave up and stripped down a production scene instead. I did not have sufficient knowledge and tools to narrow it down to the Image Texture node. Now I know why :)

I actually spent over 45 minutes trying to make it happen on a default cube style scene. Had i known it was Image Texture, I would of course just send much simpler scene.

> In #94609#1291980, @HooglyBoogly wrote: > Next time please take some time to simplify the file in the report. In about 20 minutes I was able to simplify the problem to the following, which is so much easier for any developer to debug. > {[F12813060](https://archive.blender.org/developer/F12813060/image.png) size=full} > > > I'm far from a dependency graph expert, but it seems like this might be a fairly straightforward problem to fix if there is an extra dependency somewhere. > @JacquesLucke or @Sergey, maybe the following simple file makes finding the problem easy? > > [#94609.blend](https://archive.blender.org/developer/F12813056/T94609.blend) Huh, I actually tried several times to create a simple repro scene, but I always failed. For some reason I did not understand, I could not reproduce it from the scratch, so I eventually gave up and stripped down a production scene instead. I did not have sufficient knowledge and tools to narrow it down to the Image Texture node. Now I know why :) I actually spent over 45 minutes trying to make it happen on a default cube style scene. Had i known it was Image Texture, I would of course just send much simpler scene.

Hans Goudey commented

2022-01-20 20:08:26 +01:00

Huh, I actually tried several times to create a simple repro scene, but I always failed. For some reason I did not understand, I could not reproduce it from the scratch, so I eventually gave up and stripped down a production scene instead. I did not have sufficient knowledge and tools to narrow it down to the Image Texture node. Now I know why :)

I actually spent over 45 minutes trying to make it happen on a default cube style scene. Had i known it was Image Texture, I would of course just send much simpler scene.

Okay, no hard feelings :) Thanks anyway for the report. I hope this is fixable problem issue and not a monster lurking in the depsgraph.

>Huh, I actually tried several times to create a simple repro scene, but I always failed. For some reason I did not understand, I could not reproduce it from the scratch, so I eventually gave up and stripped down a production scene instead. I did not have sufficient knowledge and tools to narrow it down to the Image Texture node. Now I know why :) > >I actually spent over 45 minutes trying to make it happen on a default cube style scene. Had i known it was Image Texture, I would of course just send much simpler scene. Okay, no hard feelings :) Thanks anyway for the report. I hope this is fixable problem issue and not a monster lurking in the depsgraph.

Demeter Dzadik commented

2022-01-25 17:39:16 +01:00

Added subscriber: @Mets

Demeter Dzadik commented

2022-01-25 17:39:16 +01:00

Just to add to this, I also managed to find a case where this seems to happen, and I already made a test file before Bastien pointed me to this report, so might as well post it:

texture_displace_performance_bug.blend

The case our lighting artist is running into is a modifier stack of Subdiv+Texture Displacement+Subdiv, causing lag when duplicating unrelated lights. Of course now that we've figured it out we can work around it, but it took a lot of time to hunt this down (around 20 minutes, as you say), so I hope this can be fixed soon.

Just to add to this, I also managed to find a case where this seems to happen, and I already made a test file before Bastien pointed me to this report, so might as well post it: [texture_displace_performance_bug.blend](https://archive.blender.org/developer/F12823624/texture_displace_performance_bug.blend) The case our lighting artist is running into is a modifier stack of Subdiv+Texture Displacement+Subdiv, causing lag when duplicating unrelated lights. Of course now that we've figured it out we can work around it, but it took a lot of time to hunt this down (around 20 minutes, as you say), so I hope this can be fixed soon.

Ludvik Koutny commented

2022-01-25 18:58:53 +01:00

In #94609#1294718, @Mets wrote:
Just to add to this, I also managed to find a case where this seems to happen, and I already made a test file before Bastien pointed me to this report, so might as well post it:

texture_displace_performance_bug.blend

The case our lighting artist is running into is a modifier stack of Subdiv+Texture Displacement+Subdiv, causing lag when duplicating unrelated lights. Of course now that we've figured it out we can work around it, but it took a lot of time to hunt this down (around 20 minutes, as you say), so I hope this can be fixed soon.

Yes, that's why I titled the report as "Most modifiers", as I remembered it happened even before Geometry Nodes existed. However I am not realizing that this may be incorrect label, as the common culprit appears to be whatever evaluates the image texture datablock.

> In #94609#1294718, @Mets wrote: > Just to add to this, I also managed to find a case where this seems to happen, and I already made a test file before Bastien pointed me to this report, so might as well post it: > > [texture_displace_performance_bug.blend](https://archive.blender.org/developer/F12823624/texture_displace_performance_bug.blend) > > The case our lighting artist is running into is a modifier stack of Subdiv+Texture Displacement+Subdiv, causing lag when duplicating unrelated lights. Of course now that we've figured it out we can work around it, but it took a lot of time to hunt this down (around 20 minutes, as you say), so I hope this can be fixed soon. Yes, that's why I titled the report as "Most modifiers", as I remembered it happened even before Geometry Nodes existed. However I am not realizing that this may be incorrect label, as the common culprit appears to be whatever evaluates the image texture datablock.

Jacques Lucke commented

2022-01-26 17:37:08 +01:00

In the file from @Mets the update tag of the image/texture seems to come from foreach_id_cow_detect_need_for_update_callback. Didn't figure out the full reason for the issue yet.

In the file from @Mets the update tag of the image/texture seems to come from `foreach_id_cow_detect_need_for_update_callback`. Didn't figure out the full reason for the issue yet.

Paul Szajner commented

2022-02-01 15:01:16 +01:00

Added subscriber: @sozap

Charlie Jolly commented

2022-02-01 15:42:05 +01:00

Added subscriber: @CharlieJolly

Hans Goudey changed title from ~~Most modifiers including Geometry Nodes modifier get re-evaluated by many completely unrelated operations~~ to Modifiers are always reevaluated when using an image texture node

2022-02-08 20:40:20 +01:00

Ludvik Koutny commented

2022-02-09 08:32:22 +01:00

Maybe more fitting title would be "image texture datablock" instead of a node? Since this seems to also affect non-GN modifiers which use image texture, such as displace.

Hans Goudey commented

2022-02-09 23:03:48 +01:00

Oh, yes, good point, thanks.

Hans Goudey changed title from ~~Modifiers are always reevaluated when using an image texture node~~ to Modifiers are always reevaluated when using an image texture data-block

2022-02-09 23:03:57 +01:00

Roman commented

2022-02-11 22:19:45 +01:00

Added subscriber: @rwman

Ludvik Koutny commented

2022-02-18 09:11:31 +01:00

Since 3.1 release is getting dangerously close, will this be fixed in time? This severely limits usability of GN. As soon as Image Texture node is used, the overall Blender performance degrades to unusable levels nearly immediately. :(