Maniphest T89844

Nesting Collection instances cause first objects to disappear (restricted by MAX_DUPLI_RECUR)
Closed, Archived
Actions

Assigned To
None
Authored By
Jon (StraumliBlight)
Jul 13 2021, 10:30 PM
Tags
  • BF Blender
  • Core
Subscribers
Bastien Montagne (mont29)
Brecht Van Lommel (brecht)
Jon (StraumliBlight)
Philipp Oeser (lichtwerk)

Description

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 2.93.1, branch: master, commit date: 2021-06-22 05:57, hash: rB1b8d33b18c2f

Short description of error
Ten levels of collection instances cause the base object to become invisible. Steps to recreate the issue are:

1: Create a collection "Collection 1" and add a mesh object to it.
2: Create a collection "Collection 2" and add an instance of "Collection 1" to it.
3: Continue repeating step 2) of adding of adding nested collection instances, until collection "Collection 10" contains an instance of "Collection 9".
4: Create a collection instance of "Collection 10" and hide all other collections. The mesh object in "Collection 1" will no longer visible (or rendered).
5: If a mesh object is added to "Collection 2", it becomes visible in the "Collection 10" instance but disappears from a "Collection 11" instance, if created.

This bug has been in Blender since collections were first added and its unusual for a project to have 10 levels of collection instances, so it doesn't normally cause a problem. If this is 'correct' behaviour it would be nice if a warning message was displayed to users explaining that the base objects wont be rendered.

Exact steps for others to reproduce the error
Open the linked file and no mesh will be displayed for the "Collection 10" collection instance. If its "Object Properties → Instancing → Collection" field is edited to "Collection 9", then the mesh will become visible.

NestedCollectionBug.blend797 KBDownload

Related Objects

Mentioned Here
T48913: Viewport gets stuck when two group instances are emitted from one face using dupli-verts
rBc0161a1bab71: Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID.
rBbfc644dcfb52: Reduce `DupliObject::persistent_id` from 16 to 8 items
P2350 T89844_snippet

Event Timeline

Jon (StraumliBlight) created this task.Jul 13 2021, 10:30 PM
Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Information from Developers.Aug 30 2021, 1:55 PM
Philipp Oeser (lichtwerk) added a project: Core.
Philipp Oeser (lichtwerk) added subscribers: Bastien Montagne (mont29), Brecht Van Lommel (brecht), Philipp Oeser (lichtwerk).

Can confirm the behavior.

This seems to be restricted by MAX_DUPLI_RECUR.
Changing this might be possible (needs to be done in a couple of places, see the following patch), but I assume there will be issues with persistent_id then (that I cannot forsee).

P2350 T89844_snippet
1
2
3diff --git a/intern/cycles/blender/blender_id_map.h b/intern/cycles/blender/blender_id_map.h
4index 198cfb4b29a..aed18b44e21 100644
5--- a/intern/cycles/blender/blender_id_map.h
6+++ b/intern/cycles/blender/blender_id_map.h
7@@ -196,7 +196,7 @@ template<typename K, typename T> class id_map {
8 * To uniquely identify instances, we use the parent, object and persistent instance ID.
9 * We also export separate object for a mesh and its particle hair. */
10
11-enum { OBJECT_PERSISTENT_ID_SIZE = 8 /* MAX_DUPLI_RECUR in Blender. */ };
12+enum { OBJECT_PERSISTENT_ID_SIZE = 10 /* MAX_DUPLI_RECUR in Blender. */ };
13
14 struct ObjectKey {
15 void *parent;
16diff --git a/source/blender/blenkernel/BKE_duplilist.h b/source/blender/blenkernel/BKE_duplilist.h
17index c142d5338d1..d3e3ad9a0f1 100644
18--- a/source/blender/blenkernel/BKE_duplilist.h
19+++ b/source/blender/blenkernel/BKE_duplilist.h
20@@ -51,7 +51,7 @@ typedef struct DupliObject {
21
22 /* Persistent identifier for a dupli object, for inter-frame matching of
23 * objects with motion blur, or inter-update matching for syncing. */
24- int persistent_id[8]; /* MAX_DUPLI_RECUR */
25+ int persistent_id[10]; /* MAX_DUPLI_RECUR */
26
27 /* Particle this dupli was generated from. */
28 struct ParticleSystem *particle_system;
29diff --git a/source/blender/draw/engines/eevee/eevee_private.h b/source/blender/draw/engines/eevee/eevee_private.h
30index f51b4fa0127..fe719084a61 100644
31--- a/source/blender/draw/engines/eevee/eevee_private.h
32+++ b/source/blender/draw/engines/eevee/eevee_private.h
33@@ -649,7 +649,7 @@ typedef struct EEVEE_ObjectKey {
34 /** Parent object for duplis */
35 struct Object *parent;
36 /** Dupli objects recursive unique identifier */
37- int id[8]; /* MAX_DUPLI_RECUR */
38+ int id[10]; /* MAX_DUPLI_RECUR */
39 } EEVEE_ObjectKey;
40
41 typedef struct EEVEE_ObjectMotionData {
42diff --git a/source/blender/makesdna/DNA_object_types.h b/source/blender/makesdna/DNA_object_types.h
43index 0250d853898..a92327a65b5 100644
44--- a/source/blender/makesdna/DNA_object_types.h
45+++ b/source/blender/makesdna/DNA_object_types.h
46@@ -752,7 +752,7 @@ enum {
47 OB_EMPTY_IMAGE_USE_ALPHA_BLEND = 1 << 0,
48 };
49
50-#define MAX_DUPLI_RECUR 8
51+#define MAX_DUPLI_RECUR 10
52
53 #ifdef __cplusplus
54 }

This was touched before (but in another context:

A related issue came up before in T48913: Viewport gets stuck when two group instances are emitted from one face using dupli-verts
And it seems this was raised once in rBc0161a1bab71: Fix T48913: cycles viewport render stuck in loop due to non-unique dupli ID..
But then reduced again in rBbfc644dcfb52: Reduce `DupliObject::persistent_id` from 16 to 8 items.

@Bastien Montagne (mont29), @Brecht Van Lommel (brecht): I guess this can/should be closed as Known Issue (as in: wont be fixed)?

Philipp Oeser (lichtwerk) renamed this task from Nesting Collection instances cause first objects to disappear to Nesting Collection instances cause first objects to disappear (restricted by MAX_DUPLI_RECUR).Aug 30 2021, 1:56 PM
Bastien Montagne (mont29) closed this task as Archived.Aug 30 2021, 3:04 PM

Not sure about raising that level of nesting, to me it looks already fairly reasonable as it is, you can always build cases that will break any such limit anyway... Will let that decision to @Brecht Van Lommel (brecht)

In any case, definitely not a bug, not even a 'known issue', just an internal limitation (similar to max amount of materials, etc.).