Octree removal 6: move octree-entry data onto LLDrawable / LLVOCacheEntry, then delete llvieweroctree / LLSpatialGroup #480
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#480
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.
Many systems read the per-entry data rather than the tree:
getSpatialExtents,getPositionGroup,getBinRadius;mDistanceWRTCamera;setVisible/sCurVisible).Readers include the clean renderer (avatar extents), texture streaming (
vkTextureStreamVisible), LOD (calcLOD),LLDrawable::updateDistanceand the VOCache.Do: move these fields onto
LLDrawable/LLVOCacheEntry. Then deletellvieweroctree.*,LLSpatialGroup/LLSpatialPartition, andlloctree.husage in newview.Keep the per-mesh triangle octrees (llvolumeoctree.h, the glTF primitive octree). They are the narrow-phase for picking.
Done: merged in
58c9cfef0d(2026-10-07), shipped in 1.2.0 Beta 6. The viewer octree is replaced by a shared spatial entry (8042249519), octree settings and debug displays removed (116adb9fa5); llspatialpartition is gone from the tree.