Avatars sometimes stuck half-loaded after unload/reload (textures or full mesh); survives their relog #105

New issue

Open

opened 2026-09-27 13:21:51 +00:00 by backspace119 · 1 comment

backspace119 commented

2026-09-27 13:21:51 +00:00

Owner

Some avatars sometimes don't load properly and stay broken: missing or wrong textures in some cases, the full mesh body or attachments missing in others. It seems to follow an unload/reload of that avatar (they leave view or range and come back, or re-rez). Having the affected user relog doesn't fix it: they come back in the same broken state.

Why that matters

When the other user relogs, their avatar and attachments come back as new objects (new local IDs) but reference the same asset UUIDs (meshes, textures, bakes, skins). The broken state surviving that points to our viewer's per-asset state keyed by UUID, not per-object state: it is set during the unload, never cleared, and reused when the same assets return.

Suspects (per-asset caches in the clean pipeline)

Mesh capture latch: LLCleanMeshAsset latches each captured (mesh, LOD) so capture early-returns. If the geometry GC or an invalidation frees the slots but leaves the latch set (or the decode/fail bookkeeping mCaptureFail / decode gave_up), the returning mesh is never re-captured and draws nothing: the "full mesh missing" case.
Texture residency / VK texture slots: an evicted or downscaled texture whose slot or generation isn't re-requested on return, or LLCleanTexture map entries that are never removed (known to grow for the session). That would give the "textures wrong/missing" case.
Skin store (keyed by mesh_id since the hash collision fix): a stale skin/joint entry reused by the returning attachment.
Animesh control avatar: vkEnsureControlAvatar readiness gates.
Bakes: now that GL-A2 drains sGLQ, updateMeshTextures runs; check a late bake after reload.

To capture on the next occurrence

Does our relog fix it? If yes, it's viewer-side session state (confirms the above). If no, it's a disk cache (Help > purge cache, or ~/.alchemyviewer/cache).
Select the broken attachment (or the avatar) with RenderVKIngestDiag on: the VKIngestDiag block shows per-face ingest state (captured / latched / not-ready / refused / missing instance).
Note textures vs. mesh, own avatar vs. others, animesh or not, and whether moving far away and back changes anything.

Candidate fix direction: on object/avatar kill, and on GC slot free, clear every per-asset latch that gates re-ingest (mesh latch + fail/decode state, texture want/resident state), so a returning asset always takes the cold path; plus a self-heal pass (like the sweep's full visit) that re-ingests faces whose instance or slot is missing.

Some avatars sometimes don't load properly and **stay** broken: missing or wrong textures in some cases, the full mesh body or attachments missing in others. It seems to follow an unload/reload of that avatar (they leave view or range and come back, or re-rez). **Having the affected user relog doesn't fix it**: they come back in the same broken state. ### Why that matters When the other user relogs, their avatar and attachments come back as new objects (new local IDs) but reference the **same asset UUIDs** (meshes, textures, bakes, skins). The broken state surviving that points to **our viewer's per-asset state keyed by UUID**, not per-object state: it is set during the unload, never cleared, and reused when the same assets return. ### Suspects (per-asset caches in the clean pipeline) - **Mesh capture latch:** `LLCleanMeshAsset` latches each captured (mesh, LOD) so capture early-returns. If the geometry GC or an invalidation frees the slots but leaves the latch set (or the decode/fail bookkeeping `mCaptureFail` / decode `gave_up`), the returning mesh is never re-captured and draws nothing: the "full mesh missing" case. - **Texture residency / VK texture slots:** an evicted or downscaled texture whose slot or generation isn't re-requested on return, or `LLCleanTexture` map entries that are never removed (known to grow for the session). That would give the "textures wrong/missing" case. - **Skin store** (keyed by mesh_id since the hash collision fix): a stale skin/joint entry reused by the returning attachment. - **Animesh control avatar:** `vkEnsureControlAvatar` readiness gates. - **Bakes:** now that GL-A2 drains `sGLQ`, `updateMeshTextures` runs; check a late bake after reload. ### To capture on the next occurrence 1. Does **our** relog fix it? If yes, it's viewer-side session state (confirms the above). If no, it's a disk cache (Help > purge cache, or `~/.alchemyviewer/cache`). 2. Select the broken attachment (or the avatar) with `RenderVKIngestDiag` on: the `VKIngestDiag` block shows per-face ingest state (captured / latched / not-ready / refused / missing instance). 3. Note textures vs. mesh, own avatar vs. others, animesh or not, and whether moving far away and back changes anything. Candidate fix direction: on object/avatar kill, and on GC slot free, clear **every** per-asset latch that gates re-ingest (mesh latch + fail/decode state, texture want/resident state), so a returning asset always takes the cold path; plus a self-heal pass (like the sweep's full visit) that re-ingests faces whose instance or slot is missing.

backspace119 added the

avatars

bug

labels

2026-09-27 13:21:51 +00:00

backspace119 referenced this issue

2026-09-27 16:02:13 +00:00

Windows: abrupt exit with no dump or log error (fail-fast?) — tracking #107

backspace119 commented

2026-09-27 16:02:19 +00:00

Author

Owner