Compositor freeze in heavy scenes #121188

New Issue

Open

opened 2024-04-28 12:43:02 +02:00 by Rincewind · 5 comments

Rincewind commented

2024-04-28 12:43:02 +02:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.86

Blender Version
Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: e1743a0317bc
Worked: never

Short description of error
Compositor freeze in heavy scenes.

Exact steps for others to reproduce the error
This is a follow up of #101861 (which was fixed in 4.1 - but there seem to be other conditions which freeze the compositor).
In this case the issue is caused by hair nodes.

Open the attached blend file.
Go to the compositor
Change a node (disconnect, delete, add a new one)
Compositor freeze for several seconds.

Also happens in the latest alpha of 4.2.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 4090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.86 **Blender Version** Broken: version: 4.1.1, branch: blender-v4.1-release, commit date: 2024-04-15 15:11, hash: `e1743a0317bc` Worked: never **Short description of error** Compositor freeze in heavy scenes. **Exact steps for others to reproduce the error** This is a follow up of #101861 (which was fixed in 4.1 - but there seem to be other conditions which freeze the compositor). In this case the issue is caused by hair nodes. 1. Open the attached blend file. 2. Go to the compositor 3. Change a node (disconnect, delete, add a new one) 4. Compositor freeze for several seconds. Also happens in the latest alpha of 4.2.

blender_X30igkRMJY.mp4

325 KiB

slow compositor.blend

1.0 MiB

Rincewind added the

labels 2024-04-28 12:43:02 +02:00

Richard Antalik added

and removed

labels 2024-04-29 08:07:49 +02:00

Omar Emara self-assigned this 2024-04-30 12:45:36 +02:00

Omar Emara removed their assignment 2024-04-30 15:44:08 +02:00

Omar Emara commented

2024-04-30 15:50:20 +02:00

Member

This is caused by the Geometry Node stack evaluating everytime the compositor executes. In particular, when evaluating the compositor dependency graph. The graph constructs the entire scene while I expect it to be minimal enough, so something might be wrong in the depsgraph construction.

@Sergey Any idea?

This is caused by the Geometry Node stack evaluating everytime the compositor executes. In particular, when evaluating the compositor dependency graph. The graph constructs the entire scene while I expect it to be minimal enough, so something might be wrong in the depsgraph construction. @Sergey Any idea?

Sergey Sharybin commented

2024-04-30 17:47:26 +02:00

Owner

This is a variation of a known short-coming of the dependency graph w.r.t ID properties. Currently, all ID properties are considered "needed to be evaluated", so if, say, scene points to a collection, everything if that collection will be evaluated. This is exactly what happens here.

For the pipeline addons type of a use-case i was trying to implement a concept of weak-referencing, so it is possible to reference ID from custom property, but not force the ID to be evaluatable. It turned out to be less straightforward than I hoped it will be, so it is on a longer list now.

For this issue I think we should be able to optimize out evaluation of the IDs referenced by custom properties. It will solve the majority of the performance impact, but not the memory usage.

In any case, it is something to be handled by the Core/Depsgraph. Don't think it is something we can do from from the compositor side.

This is a variation of a known short-coming of the dependency graph w.r.t ID properties. Currently, all ID properties are considered "needed to be evaluated", so if, say, scene points to a collection, everything if that collection will be evaluated. This is exactly what happens here. For the pipeline addons type of a use-case i was trying to implement a concept of weak-referencing, so it is possible to reference ID from custom property, but not force the ID to be evaluatable. It turned out to be less straightforward than I hoped it will be, so it is on a longer list now. For this issue I think we should be able to optimize out evaluation of the IDs referenced by custom properties. It will solve the majority of the performance impact, but not the memory usage. In any case, it is something to be handled by the Core/Depsgraph. Don't think it is something we can do from from the compositor side.

Rincewind commented

2024-05-01 06:26:18 +02:00

Author

@Sergey
is there a chance that we see that optimization workaround in 4.2? At least for me, those dependency graph issue makes the compositor regularly impossible to use.

@Sergey is there a chance that we see that optimization workaround in 4.2? At least for me, those dependency graph issue makes the compositor regularly impossible to use.

Sergey Sharybin commented

2024-05-01 11:20:58 +02:00

Owner

@Rincewind3D Hard to tell, hopefully yes. But maybe there will be some unforeseen issue with the approach discovered.

Maybe it is also something you can work-around from your side by avoiding custom properties on a scene which points to an ID? Here at the studio we avoid those and use a poor-man's weak-referencing using string property with a name of ID instead of a direct reference to the ID.

@Rincewind3D Hard to tell, hopefully yes. But maybe there will be some unforeseen issue with the approach discovered. Maybe it is also something you can work-around from your side by avoiding custom properties on a scene which points to an ID? Here at the studio we avoid those and use a poor-man's weak-referencing using string property with a name of ID instead of a direct reference to the ID.

Rincewind commented

2024-05-01 16:11:50 +02:00

Author

Thank you! I'm happy to hear that you try it.

That compositor freezes torments me since years! I did already multiple reports about it, which all got fixed - but I always find a new condition which is causing those. Hopefully this is the last one.

To be honest, I never reference IDs. I guess this is always caused by addons or assets I use. ;)
In this case, the built-in geo node hair.
But I have these issues also with scattering with Geo-Scatter, so I guess Geo-Scatter may also use IDs.

There is really no feasible way to avoid this, for me.

But there is an interesting detail I want to share. My workaround is, to use addons for most composition work.
Addons which change the compositor via Python does not cause the freeze! As long the compositor is not visible in the UI, eveything is fine. But sometimes I need adjustments my addons can't do and than it's get ugly. Sometimes 20 to 30 secs, for every single change in the compositor.

Thank you! I'm happy to hear that you try it. That compositor freezes torments me since years! I did already multiple reports about it, which all got fixed - but I always find a new condition which is causing those. Hopefully this is the last one. To be honest, I never reference IDs. I guess this is always caused by addons or assets I use. ;) In this case, the built-in geo node hair. But I have these issues also with scattering with Geo-Scatter, so I guess Geo-Scatter may also use IDs. There is really no feasible way to avoid this, for me. But there is an interesting detail I want to share. My workaround is, to use addons for most composition work. Addons which change the compositor via Python does not cause the freeze! As long the compositor is not visible in the UI, eveything is fine. But sometimes I need adjustments my addons can't do and than it's get ugly. Sometimes 20 to 30 secs, for every single change in the compositor.

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project (Legacy)

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 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#121188

No description provided.