Improve Avatar Load Speed
in progress
Signal Linden
Agent appearance load times bad. In a scene with a handful of agents, it may take over five minutes for all avatar's to load. To make this worse, after 60 seconds we decloud avatars, exposing their gnomelike, often nude, base bodies to the user.
_(See attached image) Oh my god, it's full of clouds!_
As a deceitfully alluring prompt: Let's make avatars load at least twice as fast. What would it take?
- [ ] Identify existing metrics
- [ ] Profile avatar load behavior
- [ ] Identify causes of long appearance loading
- [ ] Identify and prioritize solutions
- [ ] Implement high priority solutions
- [ ] Ensure analytics are in please to measure project success (Avatar decloud time)
Log In
Isobel DeSantis
What amazes me is that if the affected avatars switch groups, they immediately load correctly to people already present. I've now got into the habit of doing that myself when landing in a crowded place but I'd love to know why it has that effect.
Shadow Siamendes
Isobel DeSantis Yep, that's something that always puzzled me. It's something I do and usually recommend for these issues. Then go like "Why so? Because 'it just works'
shrugs
"primerib1 Resident
Technical questions from me:
* Are the avatars loaded using one single HTTP pipeline per thread?
* Could it be possible that the ISP purposefully throttle multiple HTTP pipelines to the same destination?
* Would switching over to, say, SCTP (either natively or using SCTP-over-UDP) help?
(SCTP is the underlying tech used by WebRTC, so it's quite mature, and especially SCTP-over-UDP probably will not be throttled by ISPs as more and more multimedia services rely on WebRTC.)
Andrey Kleshchev
We improved following areas:
- Avatar prioritization, viewer now tries to prioritize meshes by avatars instead of spreading itself thin. Skinning data and meshes now share priority instead of skins holding ready avatars while other, incomplete avatars load. End result should help loading avatars one at a time instead of all at once and late.
- Better threading. Meshes now spread work over 3 threads instead of overloading a single thread. Should help on PCs with numerous, but weaker cores.
- Cache adjustments. Mesh thread should do less reading due to better accounting of what's on disk and what isn't.
- Network fixes. Viewer couldn't handle some packets in time and they were dropped then resent, thus delaying load process.
Test Build at the bottom of this page, note that it still needs testing by QA:
Oriella Charik
I have horrible loading speed presently, but it's texture rather than just avatar related. At start up the disk that has the cache starts churning at 100%. Textures load in batches and can take five minutes if I logged in in a high detail location. If I TP I am once again frozen. Worst ever, since 2008!
otip: if mesh avatars look weird, reset graphics.
primerib1 Resident
Oriella Charik This is why I now use a RAM Disk to act as texture cache. There are drawbacks, of course, but I can live with those.
Bavid Dailey
I used to get this a lot, but on latest FS beta 77449 and earlier betas for a while, i have not seen what your picture shows, or the text describes
M2 mini Pro, Ultra , dd 128 or higher, no mirrors. I do see a small time delay when people are tped in, for example and they look as you describe. But I have not seen clouds for a long time.
Just saying (and maybe jinxing myself :-))
I also run Megapahit viewer from time to time, and I don't see it there either , although my tests are not as stringent.
Signal Linden
in progress