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

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.

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

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.

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!