Heavy sim: PBR shirt flipped to alpha blend; edit window material swatch shows wrong / transparent image #223

Open
opened 2026-10-01 07:18:08 +00:00 by sky_line · 0 comments
Owner

Seen in a heavy sim (thousands of objects, 1000+ flexis, lots of alpha-blend foliage, heavy texture churn), Vulkan build:

  • A worn PBR shirt (user is ~99% sure its alpha mode was opaque) rendered as alpha blend: double-sided blend, so its inner faces drew over the outer ones (looked inside-out, view-dependent).
  • In the Edit window, the material swatch for that face showed the wrong image -- foliage, apparently from the sim. Re-opening edit later showed a completely transparent swatch.
  • Setting the alpha mode to opaque in the editor fixed the render.

The swatch is drawn by LL's UI from LL's own texture objects, and the alpha mode the editor shows comes from LL's material data -- so this isn't (only) the world renderer. Suspects:

  1. UI texture binding in the VK facade (LLRenderVK): if UI textures map to VkImages by a recyclable key (GL texture name / LLImageGL id / pointer), a stale mapping after texture deletion would show whatever image now owns that key -- random image, then transparent. Heavy texture churn makes this likelier.
  2. Material identity mixups: LLCleanMaterialStore / GLTF override plumbing aliasing two materials (cf. the skin-store hash collision we had before), so the editor and render read another material's data (blend mode, base texture).
  3. Asset service: the SL asset CDN was returning 403 for some material_id fetches that day -- may contribute to fallbacks, but doesn't explain a foliage image in the swatch.

Repro idea: heavy sim, wear PBR clothing, edit it repeatedly while textures stream; compare the editor swatch's texture UUID with what's displayed. Log the VK facade texture cache key -> VkImage on bind for the swatch.

Separate (real, not the cause here): double-sided alpha-blend meshes draw inner faces over outer ones -- fix is two-pass blend (back faces then front faces) via dynamic cull mode; held for now.

Seen in a heavy sim (thousands of objects, 1000+ flexis, lots of alpha-blend foliage, heavy texture churn), Vulkan build: - A worn **PBR** shirt (user is ~99% sure its alpha mode was **opaque**) rendered as **alpha blend**: double-sided blend, so its inner faces drew over the outer ones (looked inside-out, view-dependent). - In the Edit window, the material swatch for that face showed **the wrong image** -- foliage, apparently from the sim. Re-opening edit later showed a **completely transparent** swatch. - Setting the alpha mode to opaque in the editor fixed the render. The swatch is drawn by LL's UI from LL's own texture objects, and the alpha mode the editor shows comes from LL's material data -- so this isn't (only) the world renderer. Suspects: 1. **UI texture binding in the VK facade (LLRenderVK)**: if UI textures map to VkImages by a recyclable key (GL texture name / LLImageGL id / pointer), a stale mapping after texture deletion would show whatever image now owns that key -- random image, then transparent. Heavy texture churn makes this likelier. 2. **Material identity mixups**: LLCleanMaterialStore / GLTF override plumbing aliasing two materials (cf. the skin-store hash collision we had before), so the editor and render read another material's data (blend mode, base texture). 3. Asset service: the SL asset CDN was returning 403 for some `material_id` fetches that day -- may contribute to fallbacks, but doesn't explain a foliage image in the swatch. Repro idea: heavy sim, wear PBR clothing, edit it repeatedly while textures stream; compare the editor swatch's texture UUID with what's displayed. Log the VK facade texture cache key -> VkImage on bind for the swatch. Separate (real, not the cause here): double-sided alpha-blend meshes draw inner faces over outer ones -- fix is two-pass blend (back faces then front faces) via dynamic cull mode; held for now.
sky_line added this to the Slipstream project 2026-10-06 15:04:15 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
sky_line/Slipstream#223
No description provided.