Octree removal 3: stop moving attachment and HUD bridges through the octree #477
Labels
No labels
amd
avatars
bug
builder
cannot-reproduce
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
priority
critical
priority
high
priority
low
priority
medium
provenance
rendering
rt
status
in-progress
status
testing
status
up-next
triage
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sky_line/Slipstream#477
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of #474. From the 2026-10-06 audit: the octrees are still built and maintained every frame, but almost nothing reads them. Rendering, culling, world picking, LOD, texture priority and lights all run on our own systems.
Every attachment root of every avatar still goes through
markMoved(mSpatialBridge)(lldrawable.cpp ~716-719) →mMovedBridge→LLSpatialBridge::updateMove(balance +part->move) every frame.RenderVKSkipAttachOctreedoes not cover this path. It's the largest remaining octree cost in crowds; themoved_bridgecounter is in the RenderVKSectionLog GL-residue line.Do: skip the bridge move for attachments and HUDs, or don't create
LLAvatarBridge/LLHUDBridgeat all (lldrawable.cpp ~1205-1220). Make sureLLCleanIngest::noteObjectMovedstill fires where the clean pipeline needs it (pipeline.cpp ~843-844 currently piggybacks on bridge moves).Measure: frame time in a crowded club before and after.