Freeze on performing any operation when compositor tab is open #101861

Closed
opened 2022-10-16 18:02:30 +02:00 by Rincewind · 34 comments

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

Blender Version
Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a9
Worked: (newest version of Blender that worked as expected)

Short description of error
Freeze on performing any operation when compositor tab is open.
Subsurf modifier seems important for redoing the issue

Exact steps for others to reproduce the error
This is the continuation of #99695

The Bug in #99695 was fixed, but there seems to be more conditions which make the Compositor slow.

Dorian from Scatter5 was so nice and made again a simplified version of a secene with the bug.

The slowdown caused by an unkown combination of geometry nodes, which makes the Compositor unusable slow.

  1. Open the attached file
  2. Go to the Compositor
  3. Enjoy the freeze
  4. Try to disconnect a node in the Compositor
  5. Again, enjoy the freeze

COMPOSITOR SLOW.blend

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.40 **Blender Version** Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: `b292cfe5a9` Worked: (newest version of Blender that worked as expected) **Short description of error** Freeze on performing any operation when compositor tab is open. Subsurf modifier seems important for redoing the issue **Exact steps for others to reproduce the error** This is the continuation of #99695 The Bug in #99695 was fixed, but there seems to be more conditions which make the Compositor slow. Dorian from Scatter5 was so nice and made again a simplified version of a secene with the bug. The slowdown caused by an unkown combination of geometry nodes, which makes the Compositor unusable slow. 1. Open the attached file 2. Go to the Compositor 3. Enjoy the freeze 4. Try to disconnect a node in the Compositor 5. Again, enjoy the freeze [COMPOSITOR SLOW.blend](https://archive.blender.org/developer/F13692731/COMPOSITOR_SLOW.blend)
Author

Added subscriber: @Rincewind3D-1

Added subscriber: @Rincewind3D-1

#103054 was marked as duplicate of this issue

#103054 was marked as duplicate of this issue

Added subscriber: @mod_moder

Added subscriber: @mod_moder

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'

This is a slightly simplified version. Please write in detail about what exactly your cryptomat layers are. As I understand it, their number correlates with the load.
It is also a prerequisite that an object with geometry nodes be in the collection.
COMPOSITOR SLOW (2).blend

This is a slightly simplified version. Please write in detail about what exactly your cryptomat layers are. As I understand it, their number correlates with the load. It is also a prerequisite that an object with geometry nodes be in the collection. [COMPOSITOR SLOW (2).blend](https://archive.blender.org/developer/F13693147/COMPOSITOR_SLOW__2_.blend)
Author

The cryptomate layers are just node example. You can use any other nodes in the compositor to get the slowdown.

The cryptomate layers are just node example. You can use any other nodes in the compositor to get the slowdown.

Open the file. Check the lags. Delete your layers. There are no lags. Describe what exactly you have indicated in these layers?

Open the file. Check the lags. Delete your layers. There are no lags. Describe what exactly you have indicated in these layers?
Author

Indeed, your simplified file improved the lags massiv, but there are still there, but hardly noticable.
There is still some minor delay if add/remove or connect nodes in the compositor.

I recommend for analyzing the original file, after there the lag is more obvious.

Indeed, your simplified file improved the lags massiv, but there are still there, but hardly noticable. There is still some minor delay if add/remove or connect nodes in the compositor. I recommend for analyzing the original file, after there the lag is more obvious.
Author

I did a video from your simpified version.
You see, it's still lagging a bit.

The issue is propably connected to the complexity of the mesh in the scene which are used by the geo nodes.

blender_TXPgGfnqEI.mp4

I did a video from your simpified version. You see, it's still lagging a bit. The issue is propably connected to the complexity of the mesh in the scene which are used by the geo nodes. [blender_TXPgGfnqEI.mp4](https://archive.blender.org/developer/F13693432/blender_TXPgGfnqEI.mp4)

I am not affiliated with a cryptomat. I don't know what this property is. And I don’t understand what kind of python the script is introduced in it. But the problem is with him. To more correctly name the problem, tell us what it is.
2022-10-16 20-57-49.mp4

I am not affiliated with a cryptomat. I don't know what this property is. And I don’t understand what kind of python the script is introduced in it. But the problem is with him. To more correctly name the problem, tell us what it is. [2022-10-16 20-57-49.mp4](https://archive.blender.org/developer/F13693546/2022-10-16_20-57-49.mp4)

Although I think I get it. If you move the object to another collection, there are no lags. It looks like you somehow specified a collection as a data source for the cryptomat. This in turn triggers an update each time.

+I won't be able to correctly fill out this report, so I hope I helped one of the render moderators with my investigation of this file.

Although I think I get it. If you move the object to another collection, there are no lags. It looks like you somehow specified a collection as a data source for the cryptomat. This in turn triggers an update each time. +I won't be able to correctly fill out this report, so I hope I helped one of the render moderators with my investigation of this file.

Changed status from 'Needs User Info' to: 'Needs Triage'

Changed status from 'Needs User Info' to: 'Needs Triage'
Author

Again, this issue should not be caused by Cryptomatte. I guess you can disable Cryptomatte completly and you still have the lag.

the issue is somehow caused by the geometry node which are attached to the "Some Geonodes" mesh. Those are referencing the mesh inside the collection.

Something inside the geo-nodes is causing the slowdown.

The geo-nodes are originally generated by Scatter5 (Blender addon). The creator from Scatter5 was so nice and simplified is geo-nodes as good as possible to make it easier to analyze why Blender has here this strange slowdown.

I guess the slowdown is based on the complexity of the mesh, inside the collection.

Again, this issue should not be caused by Cryptomatte. I guess you can disable Cryptomatte completly and you still have the lag. the issue is somehow caused by the geometry node which are attached to the "Some Geonodes" mesh. Those are referencing the mesh inside the collection. Something inside the geo-nodes is causing the slowdown. The geo-nodes are originally generated by Scatter5 (Blender addon). The creator from Scatter5 was so nice and simplified is geo-nodes as good as possible to make it easier to analyze why Blender has here this strange slowdown. I guess the slowdown is based on the complexity of the mesh, inside the collection.

Sorry. I reviewed your file for problems with geometry nodes from the very beginning. After not finding them, I discovered that the cryptomat layer causes the collection to be recalculated every composer update. I am not affiliated with the composer and cryptomat. But the nodes of geometry do not count here. Here is the new version of the file. It contains nothing but

  1. collection
  2. object (complex modifiers)
  3. Cryptomat layers
  4. composer nodes
    So I think the problem is somewhere in this. or in your script embedded in the cryptomat layer. But I will not be able to expand on this topic further, since this is not my area of ​​activity.
    COMPOSITOR SLOW (2).blend
Sorry. I reviewed your file for problems with geometry nodes from the very beginning. After not finding them, I discovered that the cryptomat layer causes the collection to be recalculated every composer update. I am not affiliated with the composer and cryptomat. But the nodes of geometry do not count here. Here is the new version of the file. It contains nothing but 1. collection 2. object (complex modifiers) 3. Cryptomat layers 4. composer nodes So I think the problem is somewhere in this. or in your script embedded in the cryptomat layer. But I will not be able to expand on this topic further, since this is not my area of ​​activity. [COMPOSITOR SLOW (2).blend](https://archive.blender.org/developer/F13693679/COMPOSITOR_SLOW__2_.blend)
Member

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

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

Added subscriber: @PratikPB2123

Added subscriber: @PratikPB2123
Member

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

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

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

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

I'm able to redo this. Memory usage rises on performing any operation while compositor tab is open.
Reason is unclear to me so forwarding this report to devs


Removal of Subdivision surface modifier did solve the issue

I'm able to redo this. Memory usage rises on performing any operation while compositor tab is open. Reason is unclear to me so forwarding this report to devs - - - Removal of Subdivision surface modifier did solve the issue
Pratik Borhade changed title from Geometry nodes executes superfluously when the compositor node tree change Part 2 to Freeze on performing any operation when compositor tab is open 2022-10-17 11:24:40 +02:00
Author

Removal of Subdivision surface modifier did solve the issue

As mentioned before, I guess it's a weird bug which is caused by the Geo Nodes in combination with complex geometry.

This issue is hunting me since I started to use Scatter5 and I already regocnized that that this lag appears more likley in scenes where my scattered objects have a more complex mesh.

This means, removing Subdivision surface modifier just treats the symptom ;)

> Removal of Subdivision surface modifier did solve the issue As mentioned before, I guess it's a weird bug which is caused by the Geo Nodes in combination with complex geometry. This issue is hunting me since I started to use Scatter5 and I already regocnized that that this lag appears more likley in scenes where my scattered objects have a more complex mesh. This means, removing Subdivision surface modifier just treats the symptom ;)

No geonode error. You just made a modifier on a hidden tree model. Her subdiv has led to this 9 times. And this is called by updating the cryptomat layer

I delet this in my version

No geonode error. You just made a modifier on a hidden tree model. Her subdiv has led to this 9 times. And this is called by updating the cryptomat layer I delet this in my version
Author

No geonode error. You just made a modifier on a hidden tree model. Her subdiv has led to this 9 times. And this is called by updating the cryptomat layer

I delet this in my version

Please stop confusing people.

You can apply the subdivion modifier and disable Cryptomatte and you still get the slowdown.

But if you delete the "Pine V1 07" mesh and add to the collection a simple object (like a plane) the slow down is gone.

The Mesh inside this collection is referenced by a geo-node system, which is somehow responsible for the slowdown.

> No geonode error. You just made a modifier on a hidden tree model. Her subdiv has led to this 9 times. And this is called by updating the cryptomat layer > > I delet this in my version Please stop confusing people. You can apply the subdivion modifier and disable Cryptomatte and you still get the slowdown. But if you delete the "Pine V1 07" mesh and add to the collection a simple object (like a plane) the slow down is gone. The Mesh inside this collection is referenced by a geo-node system, which is somehow responsible for the slowdown.
Member

As mentioned before, I guess it's a weird bug which is caused by the Geo Nodes in combination with complex geometry.

Hi, I'm not really sure how Geometry node tree is involved in this. Your file only has one GN tree of disconnected Group input+output node
I tried to simplify your file. Now it only has Object collection and Pine V1 07 object. Freeze is also avoidable by moving the object outside of the collection
#101861-simplified.blend


@Rincewind3D-1, could you share the exact way to recreate the file from scratch?
Did you import the model from somewhere with Object collection?

> As mentioned before, I guess it's a weird bug which is caused by the Geo Nodes in combination with complex geometry. Hi, I'm not really sure how Geometry node tree is involved in this. Your file only has one GN tree of disconnected Group input+output node I tried to simplify your file. Now it only has `Object` collection and `Pine V1 07` object. Freeze is also avoidable by moving the object outside of the collection [#101861-simplified.blend](https://archive.blender.org/developer/F13701633/T101861-simplified.blend) - - - @Rincewind3D-1, could you share the exact way to recreate the file from scratch? Did you import the model from somewhere with `Object` collection?

@PratikPB2123 If you're interested, I've already done the simplification, my version can be found above

@PratikPB2123 If you're interested, I've already done the simplification, my version can be found above
Author

Added subscriber: @BD3D

Added subscriber: @BD3D
Author

OK, I found out something pretty weird.

I guess there are multiple triggers which are causing the compositor lag.

For the scene I shared here, it seems to be the subdivion modifier.
As soon I remove the subdivion modifier or disable the render toggle
grafik.png
the compositor is fast again.

If I load the original tree to a new scene I get also a (smaller) compositor lag, until I disable or remove the subdivision modifier.
Also appliyng the subdisvion modifier fixes the lag.

But there's still a second issue, which seems to be connected to the geo-nodes created by Scatter5.
Unfortunatelly this issue dosn't seem to be reproducable in this file.
If I open my original scene, where the issue occured and remove there the subdivison modifier from the trees, the lag improves darmatically, but is still not complelty gone.
This issue is verly likly caused by the geo-node setup.

@BD3D was so nice and somplified my original scene. So I can't you sent easily a simplified new version of the with the lag without the subdivion modifier. I guess Dorian removed the issue which is causing the geo-node slowdown in the simplified version from this issues, after we weren't are that also the subdivision modifier of some meshes are *addtionally causing slowdowns.

Btw, I'm not the only person who is getting Slow Downs in the compositor using the Scatter5 node system. At least on other user on the Scatter5 Discord told that he has in some scenes also Compositor lags.

The tree asset is from DAZ Studio and converted to Blender. I added this tree asset pack to my Asset Browser.

I guess we should focus in this ticket on why subdivision are causing a lag. And once this is fixed take again a look on the presumed geo-node slowdown.

OK, I found out something pretty weird. I guess there are **multiple** triggers which are causing the compositor lag. For the scene I shared here, it seems to be the subdivion modifier. As soon I remove the subdivion modifier or disable the render toggle ![grafik.png](https://archive.blender.org/developer/F13702738/grafik.png) the compositor is fast again. If I load the original tree to a new scene I get also a (smaller) compositor lag, until I disable or remove the subdivision modifier. Also appliyng the subdisvion modifier fixes the lag. But there's still a second issue, which seems to be connected to the geo-nodes created by Scatter5. Unfortunatelly this issue dosn't seem to be reproducable in this file. If I open my original scene, where the issue occured and remove there the subdivison modifier from the trees, the lag improves darmatically, but is still not complelty gone. This issue is verly likly caused by the geo-node setup. @BD3D was so nice and somplified my original scene. So I can't you sent easily a simplified new version of the with the lag without the subdivion modifier. I guess Dorian removed the issue which is causing the geo-node slowdown in the simplified version from this issues, after we weren't are that also the subdivision modifier of some meshes are **addtionally* causing slowdowns. Btw, I'm not the only person who is getting Slow Downs in the compositor using the Scatter5 node system. At least on other user on the Scatter5 Discord told that he has in some scenes also Compositor lags. The tree asset is from DAZ Studio and converted to Blender. I added this tree asset pack to my Asset Browser. I guess we should focus in this ticket on why subdivision are causing a lag. And once this is fixed take again a look on the presumed geo-node slowdown.

Please, do we have a specific file with a problem, or is the problem still in the cryptomat and the layer script?

Please, do we have a specific file with a problem, or is the problem still in the cryptomat and the layer script?
Member

Added subscribers: @Tyrexchip, @OmarEmaraDev

Added subscribers: @Tyrexchip, @OmarEmaraDev

just want to mention that I still have regularly new scenes where I can‘t use the compositor tab because of this issue.
I‘m surprised that there are no duplicates if this issue, after it seems to happen for me pretty regularly in new scenes.

just want to mention that I still have regularly new scenes where I can‘t use the compositor tab because of this issue. I‘m surprised that there are no duplicates if this issue, after it seems to happen for me pretty regularly in new scenes.

good news, the problem described in this ticket seems to be solved in 4.1.
The files from this ticket are running now quick in 4.1.

But I've still some project (which I can't share) files where the compositor is super slow.

I will close this issue for now and open a new one as soon if I figure out what else is causing the slowness in Blender 4.1+

good news, the problem described in this ticket seems to be solved in 4.1. The files from this ticket are running now quick in 4.1. But I've still some project (which I can't share) files where the compositor is super slow. I will close this issue for now and open a new one as soon if I figure out what else is causing the slowness in Blender 4.1+

ah, I can't close this one, after I created it with an count which I no longer have access.

ah, I can't close this one, after I created it with an count which I no longer have access.
Member

Problem might still there in 3.3/3.6LTS
Not sure if it would be fixed for LTS versions as well.

Problem might still there in 3.3/3.6LTS Not sure if it would be fixed for LTS versions as well.

Not sure if older versions will get this one fixed.
I personally guessing that this one was not fixed with intention. Probably it's a side effect of all the performance optimizations done in the last time.

Not sure if older versions will get this one fixed. I personally guessing that this one was not fixed with intention. Probably it's a side effect of all the performance optimizations done in the last time.
Member

Most likely, yes. closing then.

Most likely, yes. closing then.
Blender Bot added
Status
Archived
and removed
Status
Confirmed
labels 2024-02-14 04:42:40 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#101861
No description provided.