Loading several streamed models can exhaust the default 262,144-slot culling registry. Pieces that fail adoption remain rendered but are absent from the element-to-piece index used by highlight operations, causing only part of an already resident element to change color.
Versions: fragments-beta 3.5.9, components-beta 3.5.18, components-front-beta 3.5.16, three 0.185.0. Hardware WebGPU (AMD RDNA 3).
Reproduction:
- Load several detailed streamed models into one world and move the camera so that enough pieces become resident.
- Inspect
occlusion.registry and occlusion.attached.
- Highlight a multi-part element with both adopted and unadopted resident pieces.
Measured with 10 models:
- registry capacity and used: 262,144 / 262,144;
- target: 40 resident pieces, only 14 adopted and indexed;
- highlight changed exactly those 14 pieces; 26 resident pieces retained their original colors.
core/sieve/sieving.mjs → Sifting.adopt returns false immediately when registry.allocate(count) returns -1, incrementing rotatedOffParts. The piece continues rendering, but adoption/indexing never happens.
A/B experiment with settings.streaming.query = "slots=1048576": about 805,000 active element occurrences, zero rejected adoptions, all 40 target pieces adopted, and all 40 colored by highlight. These slots count element occurrences across pieces, not just unique IFC elements.
A larger fixed capacity is a temporary mitigation, not a general fix. Ideally the registry grows safely or the residency policy handles exhaustion explicitly, so visible resident geometry cannot silently fall outside the selection/visibility bookkeeping.
Separate from #47: the missing pieces in this case were already resident before highlight. Reapplying the highlight cannot fix pieces that remain unindexed. I have not established that this also causes GPU ID-picking misses; that is a separate investigation.
Loading several streamed models can exhaust the default 262,144-slot culling registry. Pieces that fail adoption remain rendered but are absent from the element-to-piece index used by highlight operations, causing only part of an already resident element to change color.
Versions: fragments-beta 3.5.9, components-beta 3.5.18, components-front-beta 3.5.16, three 0.185.0. Hardware WebGPU (AMD RDNA 3).
Reproduction:
occlusion.registryandocclusion.attached.Measured with 10 models:
core/sieve/sieving.mjs→Sifting.adoptreturns false immediately whenregistry.allocate(count)returns -1, incrementingrotatedOffParts. The piece continues rendering, but adoption/indexing never happens.A/B experiment with
settings.streaming.query = "slots=1048576": about 805,000 active element occurrences, zero rejected adoptions, all 40 target pieces adopted, and all 40 colored by highlight. These slots count element occurrences across pieces, not just unique IFC elements.A larger fixed capacity is a temporary mitigation, not a general fix. Ideally the registry grows safely or the residency policy handles exhaustion explicitly, so visible resident geometry cannot silently fall outside the selection/visibility bookkeeping.
Separate from #47: the missing pieces in this case were already resident before highlight. Reapplying the highlight cannot fix pieces that remain unindexed. I have not established that this also causes GPU ID-picking misses; that is a separate investigation.