Avatar stuck at reduced animation rate at close range (fixed by zooming the camera) #725
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#725
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?
Seen (owner, 1.3.0 Beta 7+): one avatar about 10-15 m from the camera animates at a visibly reduced rate (choppy) while two others nearby animate at full rate. Zooming the camera in or out fixes it.
Context: GPU-animated avatars get a screen-size based animation rate (
03d6fa21da"screen-size animation rate for GPU-animated avatars"): small on-screen avatars update less often, and their frames are held in between (held animation frames, #632; the renderer'svkAnimRateLimited()path). The reduced-tier controller (LLVOAvatar::cullAvatarsByPixelArea, VKAvLOD "reduced tier") is a separate cap on fully rendered avatars.Symptom points to stale classification: an avatar at a near distance stays in the slow group until something (a camera zoom) re-evaluates it. Suspects:
Wanted:
Being investigated.
Fix pushed to main: close or large avatars animate at full rate whatever their rank, and the reduced-tier latch is released. Confirmed working by the owner; closes when the next beta ships.
Fixed in 1.3.0 Beta 8 (
v1.3.0-beta.8). Thanks for the report!