Large number of instance render wont start, stuck at 1sample, repeating BVH Building #84899

New Issue

Colin Marmond · 2021-01-20T14:42:55+01:00

Colin Marmond commented

2021-01-20 14:42:55 +01:00

System Information
Operating system: Linux 5.4.0-62-generic #70-Ubuntu SMP 2021 x86_64 x86_64 x86_64 GNU/Linux
Graphics card: GTX 2070

Blender Version
Broken: 2.93 master 2pm CET update
Worked: Do not know, never tried that much instances

Short description of error
When rendering with cycles, the viewport render stays at 1 sample :bug_rendering.mp4

When hitting render F12, working fine.

Exact steps for others to reproduce the error

Add a large plane, 200m by 200m.
Add another small plane.
Do the simple geo node setup on the large plane to scatter the small one all over the plane.
Blend file attached /

untitled.blend

**System Information** Operating system: Linux 5.4.0-62-generic #70-Ubuntu SMP 2021 x86_64 x86_64 x86_64 GNU/Linux Graphics card: GTX 2070 **Blender Version** Broken: 2.93 master 2pm CET update Worked: Do not know, never tried that much instances **Short description of error** When rendering with cycles, the viewport render stays at 1 sample :[bug_rendering.mp4](https://archive.blender.org/developer/F9589529/bug_rendering.mp4) When hitting render F12, working fine. **Exact steps for others to reproduce the error** Add a large plane, 200m by 200m. Add another small plane. Do the simple geo node setup on the large plane to scatter the small one all over the plane. Blend file attached \/ [untitled.blend](https://archive.blender.org/developer/F9589536/untitled.blend)

Colin Marmond commented

2021-01-20 14:42:55 +01:00

Added subscriber: @Kdaf

Falk David commented

2021-01-20 14:49:15 +01:00

Added subscriber: @filedescriptor

Falk David commented

2021-01-20 14:49:15 +01:00

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

Falk David commented

2021-01-20 14:49:15 +01:00

I can confirm this issue. It seems that the renderer is stuck in a loop building the bvh tree and path tracing.

Jacques Lucke commented

2021-01-20 15:38:54 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-01-20 15:38:54 +01:00

Interestingly, I can reproduce it in a release build, but not in a debug build.
I didn't track it down to the root cause yet, but applying the patch below shows interesting behavior:

diff --git a/intern/cycles/blender/blender_session.cpp b/intern/cycles/blender/blender_session.cpp
index 8566d0e7ed5..e2738e56ec5 100644
--- a/intern/cycles/blender/blender_session.cpp
+++ b/intern/cycles/blender/blender_session.cpp
@@ -812,10 +812,17 @@ void BlenderSession::synchronize(BL::Depsgraph &b_depsgraph_)
   }
 
   /* try to acquire mutex. if we don't want to or can't, come back later */
-  if (!session->ready_to_reset() || !session->scene->mutex.try_lock()) {
+  if (!session->ready_to_reset()) {
+    std::cout << "Not ready to reset.\n";
     tag_update();
     return;
   }
+  if (!session->scene->mutex.try_lock()) {
+    std::cout << "Couldn't lock mutex.\n";
+    tag_update();
+    return;
+  }
+  std::cout << "Success.\n";
 
   /* data and camera synchronize */
   b_depsgraph = b_depsgraph_;
diff --git a/source/blender/modifiers/intern/MOD_nodes.cc b/source/blender/modifiers/intern/MOD_nodes.cc
index 6da2ecba6a7..de9b1a5b348 100644
--- a/source/blender/modifiers/intern/MOD_nodes.cc
+++ b/source/blender/modifiers/intern/MOD_nodes.cc
@@ -1049,6 +1049,7 @@ static void modifyGeometrySet(ModifierData *md,
                               const ModifierEvalContext *ctx,
                               GeometrySet *geometry_set)
 {
+  std::cout << "Execute geometry nodes.\n";
   modifyGeometry(md, ctx, *geometry_set);
 }

Once viewport rendering starts, this prints the following:

Not ready to reset.
Couldn't lock mutex.
Success.
Not ready to reset.
Couldn't lock mutex.
Success.
Not ready to reset.
Couldn't lock mutex.
Success.
Not ready to reset.
Couldn't lock mutex.
Success.
...

Not sure why that is exactly. Seems to be some timing issue.

Interestingly, I can reproduce it in a release build, but not in a debug build. I didn't track it down to the root cause yet, but applying the patch below shows interesting behavior: ``` diff --git a/intern/cycles/blender/blender_session.cpp b/intern/cycles/blender/blender_session.cpp index 8566d0e7ed5..e2738e56ec5 100644 --- a/intern/cycles/blender/blender_session.cpp +++ b/intern/cycles/blender/blender_session.cpp @@ -812,10 +812,17 @@ void BlenderSession::synchronize(BL::Depsgraph &b_depsgraph_) } /* try to acquire mutex. if we don't want to or can't, come back later */ - if (!session->ready_to_reset() || !session->scene->mutex.try_lock()) { + if (!session->ready_to_reset()) { + std::cout << "Not ready to reset.\n"; tag_update(); return; } + if (!session->scene->mutex.try_lock()) { + std::cout << "Couldn't lock mutex.\n"; + tag_update(); + return; + } + std::cout << "Success.\n"; /* data and camera synchronize */ b_depsgraph = b_depsgraph_; diff --git a/source/blender/modifiers/intern/MOD_nodes.cc b/source/blender/modifiers/intern/MOD_nodes.cc index 6da2ecba6a7..de9b1a5b348 100644 --- a/source/blender/modifiers/intern/MOD_nodes.cc +++ b/source/blender/modifiers/intern/MOD_nodes.cc @@ -1049,6 +1049,7 @@ static void modifyGeometrySet(ModifierData *md, const ModifierEvalContext *ctx, GeometrySet *geometry_set) { + std::cout << "Execute geometry nodes.\n"; modifyGeometry(md, ctx, *geometry_set); } ``` Once viewport rendering starts, this prints the following: ``` Not ready to reset. Couldn't lock mutex. Success. Not ready to reset. Couldn't lock mutex. Success. Not ready to reset. Couldn't lock mutex. Success. Not ready to reset. Couldn't lock mutex. Success. ... ``` Not sure why that is exactly. Seems to be some timing issue.

Jacques Lucke commented

2021-02-11 12:58:04 +01:00

Added subscriber: @kevindietrich

Jacques Lucke commented

2021-02-11 12:58:04 +01:00

@kevindietrich do you have an idea of what might be causing this update issue? I think it's not related to your device update refactor, but maybe your knowledge from that helps you here.

Kévin Dietrich commented

2021-02-11 14:37:46 +01:00

Typically infinite update loops are caused by some property always being modified. Cycles detects this at the high level through Scene.need_data_update and Scene.need_reset. Those will check the managers which could have been tagged for an update after some object, geometry, etc., was modified. The synchronization routine between Blender and Cycles is always called after some time to account for user edits or viewport camera changes.

This infinite loop appears to be caused by some instances having their transformation always modified. Out of all the objects in the scene, only 6 of them have a modified transformation for some reason. Since they are instances, they all have the same name in Cycles:

Node : Plane.001
-- socket modified : tfm
Tagging manager with flag : 32
Node : Plane.001
-- socket modified : tfm
Tagging manager with flag : 32
Node : Plane.001
-- socket modified : tfm
Tagging manager with flag : 32
...

(Flag value of 32 is OBJECT_MODIFIED.)

So the issue seems to occur when synchronizing the objects. It could be some weird data corruption, as far as Cycles is concerned the objects are moving, yet nothing is animated. Printing the transformation changes does not seem to indicate that some objects are switched, but it could be values from other objects (following pointers between Blender and Cycles is a bit tricky and misleading because of copy on write and ID reuse):

Synchronizing 160003 objects
updating transform on Plane.001, ptr 0x7f46ca907a10
old tfm (-1, 1.50996e-07, 0, 119.47), (-1.50996e-07, -1, 0, -94.4945), (0, 0, 1, 0)
new tfm (-1, 1.50996e-07, 0, -129.386), (-1.50996e-07, -1, 0, -188.414), (0, 0, 1, 0)
updating transform on Plane.001, ptr 0x7f46ca907a10
old tfm (1, 0, 0, -173.964), (0, 1, 0, 23.5224), (0, 0, 1, 0)
new tfm (-1, 1.50996e-07, 0, -34.0009), (-1.50996e-07, -1, 0, -71.9833), (0, 0, 1, 0)
updating transform on Plane.001, ptr 0x7f46ca908580
old tfm (-1, 1.50996e-07, 0, 41.8654), (-1.50996e-07, -1, 0, -28.0075), (0, 0, 1, 0)
new tfm (-1, 1.50996e-07, 0, 198.416), (-1.50996e-07, -1, 0, 142.688), (0, 0, 1, 0)
updating transform on Plane.001, ptr 0x7f46ca908580
old tfm (1, 0, 0, -161.82), (0, 1, 0, -32.3885), (0, 0, 1, 0)
new tfm (-1, 1.50996e-07, 0, 40.056), (-1.50996e-07, -1, 0, 1.94313), (0, 0, 1, 0)
updating transform on Plane.001, ptr 0x7f46ca907a10
old tfm (1, 0, 0, -62.2047), (0, 1, 0, -58.2654), (0, 0, 1, 0)
new tfm (1, 0, 0, -105.774), (0, 1, 0, 8.17557), (0, 0, 1, 0)
updating transform on Plane.001, ptr 0x7f46ca908580
old tfm (1, 0, 0, 132.056), (0, 1, 0, 175.049), (0, 0, 1, 0)
new tfm (1, 0, 0, 17.021), (0, 1, 0, 43.9476), (0, 0, 1, 0)

Typically infinite update loops are caused by some property always being modified. Cycles detects this at the high level through `Scene.need_data_update` and `Scene.need_reset`. Those will check the managers which could have been tagged for an update after some object, geometry, etc., was modified. The synchronization routine between Blender and Cycles is always called after some time to account for user edits or viewport camera changes. This infinite loop appears to be caused by some instances having their transformation always modified. Out of all the objects in the scene, only 6 of them have a modified transformation for some reason. Since they are instances, they all have the same name in Cycles: ``` Node : Plane.001 -- socket modified : tfm Tagging manager with flag : 32 Node : Plane.001 -- socket modified : tfm Tagging manager with flag : 32 Node : Plane.001 -- socket modified : tfm Tagging manager with flag : 32 ... ``` (Flag value of 32 is OBJECT_MODIFIED.) So the issue seems to occur when synchronizing the objects. It could be some weird data corruption, as far as Cycles is concerned the objects are moving, yet nothing is animated. Printing the transformation changes does not seem to indicate that some objects are switched, but it could be values from other objects (following pointers between Blender and Cycles is a bit tricky and misleading because of copy on write and ID reuse): ``` Synchronizing 160003 objects updating transform on Plane.001, ptr 0x7f46ca907a10 old tfm (-1, 1.50996e-07, 0, 119.47), (-1.50996e-07, -1, 0, -94.4945), (0, 0, 1, 0) new tfm (-1, 1.50996e-07, 0, -129.386), (-1.50996e-07, -1, 0, -188.414), (0, 0, 1, 0) updating transform on Plane.001, ptr 0x7f46ca907a10 old tfm (1, 0, 0, -173.964), (0, 1, 0, 23.5224), (0, 0, 1, 0) new tfm (-1, 1.50996e-07, 0, -34.0009), (-1.50996e-07, -1, 0, -71.9833), (0, 0, 1, 0) updating transform on Plane.001, ptr 0x7f46ca908580 old tfm (-1, 1.50996e-07, 0, 41.8654), (-1.50996e-07, -1, 0, -28.0075), (0, 0, 1, 0) new tfm (-1, 1.50996e-07, 0, 198.416), (-1.50996e-07, -1, 0, 142.688), (0, 0, 1, 0) updating transform on Plane.001, ptr 0x7f46ca908580 old tfm (1, 0, 0, -161.82), (0, 1, 0, -32.3885), (0, 0, 1, 0) new tfm (-1, 1.50996e-07, 0, 40.056), (-1.50996e-07, -1, 0, 1.94313), (0, 0, 1, 0) updating transform on Plane.001, ptr 0x7f46ca907a10 old tfm (1, 0, 0, -62.2047), (0, 1, 0, -58.2654), (0, 0, 1, 0) new tfm (1, 0, 0, -105.774), (0, 1, 0, 8.17557), (0, 0, 1, 0) updating transform on Plane.001, ptr 0x7f46ca908580 old tfm (1, 0, 0, 132.056), (0, 1, 0, 175.049), (0, 0, 1, 0) new tfm (1, 0, 0, 17.021), (0, 1, 0, 43.9476), (0, 0, 1, 0) ```

Jacques Lucke commented

2021-02-11 15:23:05 +01:00

@kevindietrich thanks! That helped me already.

The issue seems to be that the dupli ids are not fully unique in some cases. In fact, there are 6 id collisions, which explains your result. This simple patch fixes the issue for me:

diff --git a/source/blender/blenkernel/intern/object_dupli.c b/source/blender/blenkernel/intern/object_dupli.c
index 6c8a57f8599..7885e5e9e7b 100644
--- a/source/blender/blenkernel/intern/object_dupli.c
+++ b/source/blender/blenkernel/intern/object_dupli.c
@@ -822,7 +822,7 @@ static void make_duplis_instances_component(const DupliContext *ctx)
   for (int i = 0; i < amount; i++) {
     InstancedData *data = &instanced_data[i];
 
-    const int id = ids[i] != -1 ? ids[i] : i;
+    const int id = i;
 
     if (data->type == INSTANCE_DATA_TYPE_OBJECT) {
       Object *object = data->data.object;

I have to think a bit more how to properly fix this. Ids are not really expected to be unique by construction currently, they are only used to keep random effects stable when instances are added/removed.

@kevindietrich thanks! That helped me already. The issue seems to be that the dupli ids are not fully unique in some cases. In fact, there are 6 id collisions, which explains your result. This simple patch fixes the issue for me: ``` diff --git a/source/blender/blenkernel/intern/object_dupli.c b/source/blender/blenkernel/intern/object_dupli.c index 6c8a57f8599..7885e5e9e7b 100644 --- a/source/blender/blenkernel/intern/object_dupli.c +++ b/source/blender/blenkernel/intern/object_dupli.c @@ -822,7 +822,7 @@ static void make_duplis_instances_component(const DupliContext *ctx) for (int i = 0; i < amount; i++) { InstancedData *data = &instanced_data[i]; - const int id = ids[i] != -1 ? ids[i] : i; + const int id = i; if (data->type == INSTANCE_DATA_TYPE_OBJECT) { Object *object = data->data.object; ``` I have to think a bit more how to properly fix this. Ids are not really expected to be unique by construction currently, they are only used to keep random effects stable when instances are added/removed.

Jacques Lucke self-assigned this 2021-02-11 16:12:17 +01:00

blender-admin commented

2021-02-12 17:41:28 +01:00

This issue was referenced by 98db4cc639

This issue was referenced by 98db4cc6391df8c8b21516bbdbc0af8f493a15b3

Jacques Lucke commented

2021-02-12 17:49:00 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2021-02-12 17:49:00 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Large number of instance render wont start, stuck at 1sample, repeating BVH Building #84899