Vehicles: some parts not rendering #88
Labels
No labels
amd
avatars
bug
builder
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
rendering
rt
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
backspace119/Slipstream#88
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?
Reported: vehicles have parts that don't render at all. Cause unknown.
Repro details still needed
Hypotheses (to check in order)
LLSpatialBridge(active drawable). If the VK ingest or instance-transform updates miss bridge children, those parts vanish or freeze. Related:mMovedBridge/mPartitionQnever drain under VK (GL-A3, #48); the GLResidue counters (#45) show if they grow.Debug aids
RenderVKSectionLogGLResidue line (partQ / movedBridge); select a missing part (Edit) to check it exists and get its type/material.Update from reporter: it does not affect all vehicles, only some.
That points away from a blanket moving-linkset/bridge failure (hypothesis 1 would hit every driven vehicle) and toward something content-specific: a particular prim/mesh type, material/alpha mode, flexi, sculpt type, texture animation, or linkset construction (e.g. very large link counts, child prims with scripted/local motion, llSetLinkPrimitiveParams-driven parts). Next step: compare an affected vs an unaffected vehicle - select a missing part in Edit and note its type (prim/sculpt/mesh), material (legacy/PBR, alpha mode), flexi, and whether it's animated by script.
More evidence: on the affected vehicle the doors were missing but eventually appeared; the front tires never appear (the wheels render). Selecting it in Edit draws no selection wireframe for the tires - the GPU outline is built from VK instance/slot data, so the tire mesh never reached the GPU scene: an ingest failure (missing/delayed/stuck), not culling/shading.
Log: the async mesh decoder shows
skipped[latched=102278]with the same meshes decoded repeatedly (decodes=8, latched=7). GLResidue showsmovedBridgegrowing (unprocessed moving linksets, GL-A3 #48).In progress: a select-to-diagnose log (
VKIngestDiag: per selected object/face - mesh+LOD, decode state, capture accepted/refused + reason, slot/instance) and investigation of latched decodes, allocator-ceiling refusals (GL-A10 #55) and the settled-skip signature not resetting when mesh data arrives late.Intermittent: on the next launch (no ingest changes) the same vehicle's front tires loaded and rendered correctly. So it's timing/ordering-dependent, not content-specific - points at an ingest race (data arriving later than the first ingest visit and never revisited), not at the mesh itself. Fix in progress targets the self-healing paths + a VKIngestDiag reason code to make the next occurrence conclusive.
Root cause found with VKIngestDiag (selected a partially loaded car: 101 objects, dozens of parts with missing faces).
Example, a 7-face mesh part:
Also confirmed: the face-list resync (placeholder face count frozen at creation) fired for 45+ objects - a second real cause, fixed.
Fix in progress: instance a face if it has geometry at any LOD; GPU LOD select skips empty levels; drive decode/capture from the GPU-desired LOD instead of LL's stale mLOD.