"Updating Objects Flags" Stalling Blender #88435

New Issue

rohan stevenson · 2021-05-20T19:42:23+02:00

rohan stevenson commented

2021-05-20 19:42:23 +02:00

{F10130762}System Information
Operating system: Linux-5.8.0-53-generic-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: GeForce RTX 3070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.73.01

Blender Version
Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: 02948a2cab
Worked: Not working down to 2.83 LTS

Short description of error
This file will not render the Scene named "Cycles" with the Cycles render engine.

Exact steps for others to reproduce the error

Open attached blend file. Note everything except camera and lights are turned off.
Using command line, attempt to render a single frame (say 130).
Result = Everything initialises but the render stalls on "Updating Objects Flags".
Open the file in UI
Render image renders a blank image (expected).
Turn on Buildings and Landscape, 9 collections from the top, and Nautilus and Submarine Search Lights at the bottom.
Render a single frame, or the cycles render layer in the compositor.
Result = A single image may render in cycles (followed by the second scene in Eevee that composites).
Render animation
Result = Blender hangs on "updating objects flags" and it does not render, and it is not possible to cancel the render.

It may be possible to get back rendering by saving the file as a new file. But as soon as rendering an animation as attempted, "updating objects flags" hangs Blender either in command line or in UI mode.

Notes:

I have tried the same file on multiple machines and multiple Operating Systems with the same result.
Quite a number of files have similar kinds of problems. Most commonly, the files will not render in UI mode. Usually though, rendering in command line works. In this case it does not.
I have tried every permutation of trouble-shooting I can think of. I have added meshes back in one by one, re-baking ocean modifer, particles, everything. Trying recently, I had to re-bake the particles after which rendering stopped working in any configuration. The particle systems have been baked to a disk cache.
Reconstructing from a new blend file is pointless - new blend files are fine and I do not know what is happening to bring about the bug.
It may be necessary to re-send the file in its state when it cannot render. Please let me know if anymore information is required.

{[F10130762](https://archive.blender.org/developer/F10130762/22_Nautilus_through_City_-_Cycles___Eevee.zip)}**System Information** Operating system: Linux-5.8.0-53-generic-x86_64-with-debian-bullseye-sid 64 Bits Graphics card: GeForce RTX 3070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.73.01 **Blender Version** Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: `02948a2cab` Worked: Not working down to 2.83 LTS **Short description of error** This file will not render the Scene named "Cycles" with the Cycles render engine. **Exact steps for others to reproduce the error** 1. Open attached blend file. Note everything except camera and lights are turned off. 2. Using command line, attempt to render a single frame (say 130). 3. Result = Everything initialises but the render stalls on "Updating Objects Flags". 4. Open the file in UI 5. Render image renders a blank image (expected). 6. Turn on Buildings and Landscape, 9 collections from the top, and Nautilus and Submarine Search Lights at the bottom. 7. Render a single frame, or the cycles render layer in the compositor. 8. Result = A single image may render in cycles (followed by the second scene in Eevee that composites). 9. Render animation 10. Result = Blender hangs on "updating objects flags" and it does not render, and it is not possible to cancel the render. It may be possible to get back rendering by saving the file as a new file. But as soon as rendering an animation as attempted, "updating objects flags" hangs Blender either in command line or in UI mode. Notes: 1. I have tried the same file on multiple machines and multiple Operating Systems with the same result. 2. Quite a number of files have similar kinds of problems. Most commonly, the files will not render in UI mode. Usually though, rendering in command line works. In this case it does not. 3. I have tried every permutation of trouble-shooting I can think of. I have added meshes back in one by one, re-baking ocean modifer, particles, everything. Trying recently, I had to re-bake the particles after which rendering stopped working in any configuration. The particle systems have been baked to a disk cache. 4. Reconstructing from a new blend file is pointless - new blend files are fine and I do not know what is happening to bring about the bug. 5. It may be necessary to re-send the file in its state when it cannot render. Please let me know if anymore information is required.

rohan stevenson commented

2021-05-20 19:42:23 +02:00

Added subscriber: @rohan.stevenson

Pratik Borhade commented

2021-05-21 19:13:39 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2021-05-21 19:13:39 +02:00

Thanks for the report. Please provide a simplified test file (~100mb would be fine).

rohan stevenson commented

2021-05-24 11:54:08 +02:00

Hi thanks for the response.

I'm afraid this problem requires the full blend file - I cannot replicate from a fresh blend file. In fact the workaround for this problem continually occurring is to reconstruct the blend file - effectively what I would be doing by trying to slim it down to 100mbs.

I seem to have made some progress pinning down the culprit though.

The reason why reconstructing the file does not result in the problem being reproduced is because I think it has to do with the disk cache for particles.

Updating flags issue blocks rendering either in UI mode or both UI and command line
reconstruct file
rendering is ok but the reconstructed file loses its reference to the disk cache for the particle simulation
Re-bake particles to disk
90% of the time rendering will hang on "updating flags".

Since switching off disk cache (lite compression) for particle simulations I have been able to render though not reliably. The main machine for this (In my description) struggles to continue rendering and fails due problems with optix, however a much less powerful machine (Intel 8-core, RTX 2060, Windows 10) renders in command line a similar file without issue (ie with disk cache turned off). The big machine did final render everything but only after having to be restarted several times.

Unfortunately, I can't be sure that that is definitely the problem, because I have only started to use disk cache recently (great for keeping file sizes down, though unfortunately Blender does not retain the link between when using the simulation in another file) and I have had the problem with Blender not rendering in UI mode since the beginning of the year. One issue with long bake times and problematic renders also appears to be Particle System -> Physics -> Multiply Mass with Size. If that is switched on, and then if you try to Bake All Dynamics, the bake will either go extremely slowly or fail or both.

I am not a power user, but no longer a newb - it would be pretty amazing if I am the only person to be running into this issue.

I appreciate it would be very helpful to have a perfectly replicable bug, but this is not possible in this case. Once my file is no longer able to render, it will not render on any machine I try, in any configuration. So I need to submit THAT file in THAT state.

Hi thanks for the response. I'm afraid this problem requires the full blend file - I cannot replicate from a fresh blend file. In fact the workaround for this problem continually occurring is to reconstruct the blend file - effectively what I would be doing by trying to slim it down to 100mbs. I seem to have made some progress pinning down the culprit though. The reason why reconstructing the file does not result in the problem being reproduced is because I think it has to do with the disk cache for particles. 1. Updating flags issue blocks rendering either in UI mode or both UI and command line 2. reconstruct file 3. rendering is ok but the reconstructed file loses its reference to the disk cache for the particle simulation 4. Re-bake particles to disk 5. 90% of the time rendering will hang on "updating flags". Since switching off disk cache (lite compression) for particle simulations I have been able to render though not reliably. The main machine for this (In my description) struggles to continue rendering and fails due problems with optix, however a much less powerful machine (Intel 8-core, RTX 2060, Windows 10) renders in command line a similar file without issue (ie with disk cache turned off). The big machine did final render everything but only after having to be restarted several times. Unfortunately, I can't be sure that that is definitely the problem, because I have only started to use disk cache recently (great for keeping file sizes down, though unfortunately Blender does not retain the link between when using the simulation in another file) and I have had the problem with Blender not rendering in UI mode since the beginning of the year. One issue with long bake times and problematic renders also appears to be Particle System -> Physics -> Multiply Mass with Size. If that is switched on, and then if you try to Bake All Dynamics, the bake will either go extremely slowly or fail or both. I am not a power user, but no longer a newb - it would be pretty amazing if I am the only person to be running into this issue. I appreciate it would be very helpful to have a perfectly replicable bug, but this is not possible in this case. Once my file is no longer able to render, it will not render on any machine I try, in any configuration. So I need to submit THAT file in THAT state.

Philipp Oeser commented

2021-05-26 17:24:08 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-05-26 17:24:08 +02:00

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

Philipp Oeser commented

2021-05-26 17:24:08 +02:00

So I need to submit THAT file in THAT state.

That would be good, yes, otherwise the only chance to reproduce is reliable repro steps [which afaics are not provided in this report].
Will set to "Needs Information from User" for the time being.

> So I need to submit THAT file in THAT state. That would be good, yes, otherwise the only chance to reproduce is reliable repro steps [which afaics are not provided in this report]. Will set to "Needs Information from User" for the time being.

Philipp Oeser commented

2021-06-04 13:53:31 +02:00

@rohan.stevenson: any news?

rohan stevenson commented

2021-06-04 13:57:01 +02:00

Hey there Peter,

Sorry for the radio silence...but fear not! I will be able to look into this more deeply afternoon and tomorrow. I have encountered the problem since on a simple test file with just procedural textures that would be more practical to send in...so hopefully I'll have something reproducible.

It takes a long time to trouble shoot - all time I don't really have.

Hey there Peter, Sorry for the radio silence...but fear not! I will be able to look into this more deeply afternoon and tomorrow. I have encountered the problem since on a simple test file with just procedural textures that would be more practical to send in...so hopefully I'll have something reproducible. It takes a long time to trouble shoot - all time I don't really have.

Pratik Borhade commented

2021-06-07 07:23:25 +02:00

I have encountered the problem since on a simple test file with just procedural textures that would be more practical to send in...so hopefully I'll have something reproducible.

Hi @rohan.stevenson , can you please update the information?
simple .blend file with definite steps will help to decide the status of the report.

> I have encountered the problem since on a simple test file with just procedural textures that would be more practical to send in...so hopefully I'll have something reproducible. Hi @rohan.stevenson , can you please update the information? simple .blend file with definite steps will help to decide the status of the report.

rohan stevenson commented

2021-06-07 11:09:02 +02:00

Hi Philip I am still investigating this, but I have limited time.

In the past when bug-reporting for applications, it was useful to send a project that could reliably produce the bug. It's terribly time consuming to narrow down what the exact conditions are, and often they are never the same. Usually developers have debugging techniques that help them figure out what is going wrong. Obviously it's much easier if you can pinpoint 100% the exact conditions, and I am trying to do that.

What can help is if you can give ME information regarding past reports of similar problems. I doubt very much I am alone in encountering this problem - that would be remarkable.

I have resolved not being able to render at all by turning off disk cache for particles. When I get a chance I will do some trouble shooting to see if I can get a file to switch between not being able to render, and being able to render. Then we can narrow down what the potential problem is.

In the meantime, while I am able to render - I am not able to render reliably. I am trying to render an animation at the moment which will render about 10 frames at a time before blender crashes - this is in command line mode. Find attached the crash text if that helps at all.25 Minisub Chases Nautilus.crash.txt.zip

Hi Philip I am still investigating this, but I have limited time. In the past when bug-reporting for applications, it was useful to send a project that could reliably produce the bug. It's terribly time consuming to narrow down what the exact conditions are, and often they are never the same. Usually developers have debugging techniques that help them figure out what is going wrong. Obviously it's much easier if you can pinpoint 100% the exact conditions, and I am trying to do that. What can help is if you can give ME information regarding past reports of similar problems. I doubt very much I am alone in encountering this problem - that would be remarkable. I have resolved not being able to render at all by turning off disk cache for particles. When I get a chance I will do some trouble shooting to see if I can get a file to switch between not being able to render, and being able to render. Then we can narrow down what the potential problem is. In the meantime, while I am able to render - I am not able to render reliably. I am trying to render an animation at the moment which will render about 10 frames at a time before blender crashes - this is in command line mode. Find attached the crash text if that helps at all.[25 Minisub Chases Nautilus.crash.txt.zip](https://archive.blender.org/developer/F10160695/25_Minisub_Chases_Nautilus.crash.txt.zip)

rohan stevenson commented

2021-06-11 11:34:13 +02:00

I have more information regarding these rendering issues, though I have yet to set up a simple file to test - I do have one that was glitching badly but I need to do more tests.

I have been finding that rendering on Windows is having less problems. I am having an issue with rendering on the above machine on Ubuntu where the rendering crashes - I can render up to about 10 frames and the blender will crash (command line mode) with a segmentation fault. But this isn't happening on Windows systems.

I upgraded the linux NVIDIA driver to the latest version and this has made no difference.

Rendering the same file on weaker systems (W10 i7 8-core, RTX 2060) the renders are not crashing.

I also reported a hang on baking particles in certain circumstances: https://developer.blender.org/T88965

When the file is in this state it won't render, so my suspicion is that the problem with "updating flags", blender crashing when rendering, and blender hanging when baking particles is related to the particle system. The file I mentioned that I could send in that is glitching (very simple scene testing a dirigible crashing) has particles as well.

I have more information regarding these rendering issues, though I have yet to set up a simple file to test - I do have one that was glitching badly but I need to do more tests. I have been finding that rendering on Windows is having less problems. I am having an issue with rendering on the above machine on Ubuntu where the rendering crashes - I can render up to about 10 frames and the blender will crash (command line mode) with a segmentation fault. But this isn't happening on Windows systems. I upgraded the linux NVIDIA driver to the latest version and this has made no difference. Rendering the same file on weaker systems (W10 i7 8-core, RTX 2060) the renders are not crashing. I also reported a hang on baking particles in certain circumstances: https://developer.blender.org/T88965 When the file is in this state it won't render, so my suspicion is that the problem with "updating flags", blender crashing when rendering, and blender hanging when baking particles is related to the particle system. The file I mentioned that I could send in that is glitching (very simple scene testing a dirigible crashing) has particles as well.

Philipp Oeser commented

2021-07-02 12:38:21 +02:00

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

rohan stevenson commented

2021-07-04 15:55:36 +02:00

Anyone who is having the same problem, the only workaround for this issue is to delete the particle systems from everything in your scene and rebuild. Name each system so that you can relink and re-bake more easily. The problem appears to be related to the particle system.

Luca Rood commented

2021-12-03 13:05:32 +01:00

Added subscriber: @LucaRood-3

Luca Rood commented

2021-12-03 13:05:32 +01:00

I ran into this issue as well, and can provide more details.

The issue happens when having lots of objects with volume shaders in the scene (such as when instancing them with particle systems or geometry nodes).
This is not a deadlock, so the render does proceed eventually, but after a long delay. In the current state, the way to avoid this issue is simply not to use volume shaders on instanced objects.

A quick look at the code revealed the likely source of the problem (I haven't profiled it, but this is almost certainly the culprit).
In intern/cycles/scene/object.cpp, the object flag SD_OBJECT_INTERSECTS_VOLUME is being assigned to the relevant objects.
This is done by looping over all objects with volume shaders for each object in the scene, and checking if they intersect, thus resulting in a time efficiency worse than quadratic, relative to the number of volume objects (O(n*m); n: objects in scene; m: objects with volume shader).

The solution is probably to use a hierarchical acceleration structure, such as a BVH, for the object intersection checks.

I ran into this issue as well, and can provide more details. The issue happens when having lots of objects with volume shaders in the scene (such as when instancing them with particle systems or geometry nodes). This is not a deadlock, so the render does proceed eventually, but after a long delay. In the current state, the way to avoid this issue is simply not to use volume shaders on instanced objects. A quick look at the code revealed the likely source of the problem (I haven't profiled it, but this is almost certainly the culprit). In `intern/cycles/scene/object.cpp`, the object flag `SD_OBJECT_INTERSECTS_VOLUME` is being assigned to the relevant objects. This is done by looping over all objects with volume shaders for each object in the scene, and checking if they intersect, thus resulting in a time efficiency worse than quadratic, relative to the number of volume objects (`O(n*m)`; n: objects in scene; m: objects with volume shader). The solution is probably to use a hierarchical acceleration structure, such as a BVH, for the object intersection checks.

Omar Emara commented

2022-02-24 15:59:02 +01:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-02-24 15:59:02 +01:00

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

Omar Emara commented

2022-02-24 15:59:02 +01:00

Luca's assessment seems to be correct. Most of the time will be spent intersecting volume objects. Tagging the module for an informed decision by a developer.

Luca's assessment seems to be correct. Most of the time will be spent intersecting volume objects. Tagging the module for an informed decision by a developer. ![20220224-165627.png](https://archive.blender.org/developer/F12885644/20220224-165627.png)

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

"Updating Objects Flags" Stalling Blender #88435