🪰 Viewer Bug Reports

I've been testing the 2025.03 beta on different machines, and on this particular machine equipped with a Ryzen cpu, a 3080m gpu and 32gb of ram, i observed intense frame inconsistency, that gets worse the more i wander around. It seems worse when getting inside and outside of a pbr probe. A side note: I also played with the max number of probes slider, i observed that if set to lower values, the rendering is completely messed up, looks a disco psychedelic show :) So i set this value back to 256. Note 1 : After i observed this frametime inconsistency, i hard reset the laptop internal power settings, i reset the bios, i re-installed the nvidia driver (this time i used the studio driver ..) and the problem persists. This doesn't occur on latest FS beta, and didn't occur in the previous SLV version. Note 2 : I also tested the viewer on an older windows laptop with a 1660ti gpu (Ryzen cpu, 16gb of ram), and on this one, the viewer does marvels. It's perfectly smooth and performance is impressive, as it's actually much better than the last time i tested it on the previous viewer. So i'm not sure what's going on, but i thought i would share :)

In the latest build, 7.1.12.13550888671 (64bit), enabling FXAA or SMAA divides the performance by 2 on my macbook Pro M2 (it used to have a negligible impact).

The effect of this seems to be easiest to reproduce by having a larger inventory, mine is 155K+. For me it reproduces on two different computers, running either Firestorm or the SL Viewer. Log in, open an inventory window (Ctrl + I) Open Windows' Task Manager, monitor your RAM usage Open a bunch of extra inventory windows, a few at a time (5, 10, 15, 20) (Ctrl + Shift + I) See how RAM usage increase, and if you just let it be, the RAM usage continues to go up for some time... I don't know how common it is to have a bunch of inventory windows open at once, but it would seem to me that there might be room for optimization here, with all the windows not having unique data but are views into the same data I think that it shouldn't be duplicating the data in RAM for each window like it seems to do???

Viewer VRAM usage spikes dramatically, exceeding physical memory capacity, and does not seem to drop as expected as objects go out of view, or for any reason except teleporting to another sim. Memory use far exceeds what makes sense. I have seen up to 25GB of VRAM allocated on a 16GB GPU. The viewer continues to run without issues, suggesting it is not actively using most of this memory and causing swap thrashing between physical and shared video memory. Other games and tools that use video memory in meaningful amounts are incapable of running at the same time due to all physical memory being taken up; the viewer seems to have priority of some kind. I have also seen this happen on the latest alchemy viewer release, presumably it happens in all PBR viewers. Some users with similar hardware have reported it not happening. The viewer does not crash at any point. Current video driver is AMD 24.7.1, OS is Windows 10 Enterprise LTS 2021. No unusual software that would interfere with video memory behavior in any way is running.

Bug copied from https://jira.secondlife.com/browse/BUG-234859 ---- What just happened? Using Second Life on Bellisseria as sun set. I had the Statistics bar up for PBR viewer testing. As the sun finally went down there was a visual change and a big drop in FPS, which did not recover afterwards. FPS while sun was still up was approx 85fps, with a frame of around 11ms. Immediately the sun finally set the FPS dropped to around 40FPs and the frame time jumped up to around 25ms. It stayed like that for some minutes. Looking at the statistics bar about 5 minutes later the FPS was round 70 FS and frame time around 15ms. What were you doing when it happened? Watching the sun set on Bellisseria with Statistics bar open. Using Release candidate 7.1.2.7215179142. What were you expecting to happen instead? Frame rate to stay similar in all sun/moon conditions. Other information A relog after 5 minutes or so appears to allow the FPS to go back to around 85fps (frame time 11ms or so) rather than the limited FPS it had settled on ahead of the relog. I had noticed during previous testing related to the NVidia GPU/8 core CPU systems on Firestorm and LL viewers that there could be a big an sudden change in FPS at times when sun was out and not. But the report as shown above was my clearest indication the frame rate drop was exactly as the sun finally left the sky and the sky turned a sudden deeper blue with no sun colour in it.

My FPS are super low with the new update of the offcial SL viewer and also FS viewer update. They used to be 64 FPS and now is 8 FPS and with low graphics!

Textures in every viewer since the PBR update have now been unloading and reloading, often times failing to do so, and remaining blurry. I have tried everything suggested such as whitelisting viewers and their features, but I know I'm not the only one experiencing this. This is completely game breaking and as a texture artist it's near impossible to have a consistent workflow when half the time my textures aren't loading in. I have a new GPU and plenty of RAM to spare and then some so it's not my computer. I have been able to go into the EDIT menu and have it load in, but it does this for the diffuse texture only, and when exiting the menu it will go back to attempt its reloading cycle with multiple failures. PLEASE FIX THIS.

Viewers Tested: Alchemy Beta 7.1.9.2501 (64bit) Second Life Release 7.1.10.10800445603 (64bit) Firestorm 7.1.11 (76720) Nov 9 2024 02:03:12 (64bit / AVX2) All 3 of these viewers all exhibit the same issue where, if anything even a little graphically intensive starts to occur (busy sims, a second viewer is opened, this sort of thing), the viewers quickly start to flicker black across the entire viewers window, minus the windows surround and titlebar. I am currently using Firestorm 6.6.17 (70368) Dec 10 2023 18:36:33 (64bit / SSE2) as it is the latest pre-PBR viewer as my daily driver because it and any other pre-PBR viewers I try do not exhibit this issue. I don't exhibit any issues with other programs/games that I've been able to determine and you can see from the specs below I should have no problem with the requirements for PBR viewers. This issue seems to be exclusively the domain of the PBR renderer for SL as it is viewer agnostic. I have completely re-installed Windows twice both on Windows 11 23H2 and 24H2 updates, I have run memtest86 for hours with zero errors and I have borrowed my partners GPU and PSU all to no effect. I have taken videos of the issues in each browser and obtained the logs for each, however I'm unable to upload them to the ticket as the videos are too big and the logs are zipped up and that filetype is apparently unsupported so I've put them in my onedrive and attached the links below, if you'd like be to upload them elsewhere, just say where and I'll re-upload them. SL Logs: https://1drv.ms/u/s!Argy6Q-UWl9BpqdxVEIqu2sud0QkFA?e=FnChfU SL Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdubODgMVIK4RqS4w?e=hemGAv Firestorm Logs: https://1drv.ms/u/s!Argy6Q-UWl9Bpqdw0-q0kaa1AuAdvw?e=IrV7OQ Firestorm Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdsUNzCSdoVTKEh6w?e=mJDdli Alchemy Logs: https://1drv.ms/u/s!Argy6Q-UWl9BpqdvQa589QIX9y9NIw?e=a0xGcG Alchemy Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdtJcjY_gITIV70ow?e=lpmwn3

hi, i have a weird issue. At crowded places the viewer is using 12GB RAM sometimes higher and then i end up crashing with Out of memory message. and i dont know what to do at this point because i visit few corwded place then i crash. lowering graphic settings doesnt help. it keeps using 12GB + I tried on Firestorm viewer too and on Firestorm Beta too and same result. i would be so thankful if someone could tell anything that could help

I present the same model (a small avatar accessory) with 2 different sets of LOD models. In each case the lowest LOD model has been 'zeroed out' to 18 tris as is typical in this use case. Triangle counts are as follows. * Model 1 - High 63040 (36k virts), Med 15760, Low 3940 * Model 2 - High 15760 (10k virts), Med 3940, Low 3940 Both of these models are visually indistinguishable in use. The DAE files prior to upload are sized as follows. * 63040 tris - 9.2mb * 15760 tris - 2.2mb * 3940 tris - 500kb Working on the dae sizes alone ... * Model 1 - 11.9mb * Model 2 - 4.9mb However .... * Model 1 - Download weight 0.7 * Model 2 - Download weight 3.1 When worn ARC is equally broken (as reported in firestorm) * Model 1 - ARC 319 * Model 2 - ARC 672 Objectively Model 2 is better for performance. Duplicating the mesh for 2 detail levels is punished to the point that using a sub division surface modifier to generate an insane 63k tris high model results in 'better consumer numbers' at intended object scale (it's also cheaper to upload). In addition to model duplication being unnecessarily punished, the scale component of Li accounting is fundamentally flawed and pushes creators into a situation where large items need to be low poly and tiny (often worn) items are best high poly! No wonder everyone's avatar is solid in wire-frame. This model is a small avatar accessory. Obviously the example mesh is over detailed, 'unoptimized' and created using techniques best suited to slow rendered content rather than real time. The point is why should anyone bother with 'low poly' when this gets the-job-done and is predictably rewarded.