Region crossings: keep avatar assets (ours always, others within network draw distance) instead of unloading and reloading them #607

New issue

Closed

opened 2026-10-09 22:59:07 +00:00 by sky_line · 1 comment

sky_line commented

2026-10-09 22:59:07 +00:00

Owner

Wanted

Own avatar: nothing it uses is torn down or re-ingested on a region crossing or a teleport. That covers the body and its rigged and static attachments, mesh and skin data, textures (including baked textures), GPU skin and palette slots, animation state, rig weld state, and RT BLAS entries for its attachments.
Other avatars still within network draw distance after the crossing: same treatment. If an avatar was visible before and is still inside our horizontal network draw distance afterwards, its assets and GPU state carry over and only its region association changes. Avatars that end up outside network draw distance follow the normal unload path (with the usual grace period).
Covered both ways: avatars that move between regions while we stay, and us crossing while they stay.

Investigate (verify what actually happens today)

What the crossing path tears down per avatar: object kill/re-create, attachment re-rez, mesh/skin re-capture into the clean stores, texture discard resets, GPU rigged buffer slots, animation (GPU anim store), and the region teardown / VOCache paths (#568).
Whether region-keyed caches (mesh store, instance ids, texture residency) treat a re-created object with the same asset ids as new, and re-upload.
Measure: log per-crossing counts of avatar asset re-fetches, re-decodes, and re-ingests (mesh, texture, skin) for our avatar and nearby ones, before and after.

Notes

Must not leak: anything carried over must still be released once the avatar actually leaves (logout, out of range, region gone) -- bounded and with live/peak stats, like the other stores.
Pairs with #568 (smoother crossings) and the network draw distance work (the keep/unload decision should use the same horizontal network draw distance gate).

Region crossings and teleports should not unload and reload avatar assets that are still needed. Our own avatar is always still needed, and other avatars often are (they cross with us or stay in view across the border). Unloading and re-fetching or re-decoding them is wasted work: CPU and GPU time, network traffic, and visible pop-in right when the crossing is already the most expensive moment. ## Wanted - **Own avatar:** nothing it uses is torn down or re-ingested on a region crossing or a teleport. That covers the body and its rigged and static attachments, mesh and skin data, textures (including baked textures), GPU skin and palette slots, animation state, rig weld state, and RT BLAS entries for its attachments. - **Other avatars still within network draw distance after the crossing:** same treatment. If an avatar was visible before and is still inside our horizontal network draw distance afterwards, its assets and GPU state carry over and only its region association changes. Avatars that end up outside network draw distance follow the normal unload path (with the usual grace period). - Covered both ways: avatars that move between regions while we stay, and us crossing while they stay. ## Investigate (verify what actually happens today) - What the crossing path tears down per avatar: object kill/re-create, attachment re-rez, mesh/skin re-capture into the clean stores, texture discard resets, GPU rigged buffer slots, animation (GPU anim store), and the region teardown / VOCache paths (#568). - Whether region-keyed caches (mesh store, instance ids, texture residency) treat a re-created object with the same asset ids as new, and re-upload. - Measure: log per-crossing counts of avatar asset re-fetches, re-decodes, and re-ingests (mesh, texture, skin) for our avatar and nearby ones, before and after. ## Notes - Must not leak: anything carried over must still be released once the avatar actually leaves (logout, out of range, region gone) -- bounded and with live/peak stats, like the other stores. - Pairs with #568 (smoother crossings) and the network draw distance work (the keep/unload decision should use the same horizontal network draw distance gate).

sky_line added the

labels

2026-10-09 22:59:07 +00:00

sky_line added this to the Slipstream project

2026-10-09 22:59:07 +00:00

sky_line added the

status