🪰 Viewer Bug Reports

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.

Made the switch yesterday to the Firestorm PBR . The water, eesh. Everything I have under the water is visible whereas before it just blended under. Like one of those teal colors to make the water look tropical, it just is so prominent from above. I can turn off translucent water but then I dont see them at all. Is there a setting im missing that can blend the stuff underwater like the older versions? Its blotchy and in your face and from a distance the water looks very glitchy. The loading screen is PBR (I know it says to download the latest version, but this was after I re-installed the older version, with the PBR still in the cache. The other screen is prior to the PBR install.

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

(this might be a refresh of https://feedback.secondlife.com/bug-reports/p/202503-viewer-intense-stutter-on-a-nvidia-windows-laptop ) in certain places like this : http://maps.secondlife.com/secondlife/Itame/51/46/84 The viewer can show important stutter on Windows and NVidia gpus, specially after spinning around. The issue doesn't seem to occur on the integrated AMD graphics. I also have the issue in megapahit, which i could try on Linux, and on Linux it's perfectly smooth. So it seems to be specific NVidia + Windows. The issue happens in my both PC laptops (gtx 1660ti / rtx 3080m both with an AMD cpu). (in my setting i have reflection coverage to manual only, hdr & emissive on, only show friends to avoid avatars interferences). Also the issue doesn't seem to be related to avatars, because i tested crowded sims and it wasn't too bad.

As an effort to chase down opengl errors while working on megapahit, i found this one among others that i could fix, but this one, i am not sure what to do with it : so this is in lldrawpoolwater.cpp, lines 209 and 210. shader->bindTexture(LLViewerShaderMgr::BUMP_MAP, tex_a); this line is binding the texture it calls a bindfast()), then the next line will set its filtering options: tex_a->setFilteringOption(filter_mode); Problem is, when transparent water is turned OFF, this call will generate an invalid_enum error in llrender.cpp : void LLTexUnit::setTextureFilteringOption(....) The reason why is, when it's called and the transparent water options is OFF, the mCurrTexType is equal to TT_NONE, which indicates the texture unit isn't active. subsequent calls to glTexParameteri(...) generate an invalid_enum error, since the target is invalid (sGLTextureType[mCurrTexType]). So it appears, for some reason shader->bindTexture(LLViewerShaderMgr::BUMP_MAP, tex_a); doesn't succeed at enabling the texture. I saw this on Mac, i can't say if it happens on other platforms. Also i didn't "explicitly" see this error in SLv, but it's most certainly present as the relative code in megapahit is identical and based on 7.1.15. This has been around for several updates ( at least 7.1.13 ), i couldn't say if older. In some cases it leads to performance drop when water transparency is OFF, but .. not always ... might depend on a combination of settings. I thought i would share this as the engineers who worked on this would certainly know better than me.

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).

By observing the fast timers console, i noticed big regular frametime spikes (those frames have a double duration compared to other frames approximately). The spikes happen with a shorter period when reflection coverage is set to manual vs none (with the option set to none, this is the sim general probe that is updated, so it happens less often). This doesn't happen on Windows, or Linux. I joined a couple screenshots, one with reflection coverage set to none, one set to manual only. note 1: the frametime in ms indicated in the fast timers window isn't correct on macs with Apple silicon. But it's not very important here, what matters is the shape of the frames over time. note 2: you might notice my disk cache is set to a low value. This is intended, and has no impact in this current test.

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.