🪰 Viewer Bug Reports

• Use concise, precise descriptions• Do not include sensitive information. • Create a support ticket at https://support.secondlife.com for individual account issues or sensitive information.
Viewer Hangs and Crashes in Firestorm and Second Life Viewer
I'm experiencing intermittent hangs and crashes in both Firestorm and the official Second Life Viewer on Windows 11. Firestorm has generally been more troublesome, but switching to the official Viewer has not eliminated the problem. The issues are not limited to busy regions, logging in, or teleporting. Even after adjusting the official Second Life Viewer's preferences conservatively, problems have also occurred at home and during ordinary activities, including unpacking and managing inventory, viewing images, changing outfits, and changing group tags. Busy shopping regions can also become extremely laggy. I've seen mixed results when changing group tags: some changes completed without a problem, while another caused the Viewer to freeze and crash. I also had one Windows Reliability Monitor incident report that SLPlugin.exe had stopped working, although I don't know whether it is related to the wider issue. The problems became worse around the September 2026 Windows update, but I cannot confirm that the update caused them. Lowering the Viewer's graphics settings and trying other troubleshooting steps have helped reduce the problems, but they have not eliminated them. I cannot reliably reproduce the crashes on demand. I've experienced Bugsplats, freezes, an avatar continuing to walk while the Viewer is unresponsive, gray screens, and most times I'm offered the chance to look at my IMs before crashing. System information Laptop: MSI Raider GE68 HX 14V CPU: Intel Core i9-14900HX RAM: 32 GB GPU: NVIDIA RTX 4070 Laptop GPU Operating system: Windows 11 I previously contacted Linden Lab Support about Viewer performance and provided diagnostic logs privately when requested. I was subsequently directed to use this feedback portal. I'm reporting this because the intermittent hangs and crashes affect everyday use across both Viewers, not just performance in busy regions. I don't know whether the incidents share a common cause. Related report: Crash Problem — reports crashes in both Viewers on busy regions.
4
Ā·
SL Viewer
Ā·
needsĀ info
Li/ARC accounting systemically rewards insane poly counts
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.
4
Ā·
SL Viewer
Ā·
tracked
Unwanted edge transparency in BOM Universal Aux channel layers
There's a visual glitch when using more than one BOM texture layer on a Universal Aux channel if there's partial transparency in the texture using Blinn-Phong textures. I've made BOM textures with partial transparency for rigged fairy wings, so that customers could layer a stripey texture on top of the main wing texture. However, it's as if there's an outline of 100% transparency around the edges of the upper stripey texture that punches a hole straight through the underlying wing texture as well. It shows up the most when in front of a bright background. I tried making the stripe texture completely black with a 100% transparent background by converting it to a vector and then converting it back into a raster image in Photoshop, and this minimizes the issue so that it's only visible if you're very zoomed in, but this means there can't be layered BOM textures with blended edges at all on the Aux channels. I had envisioned being able to make add-ons like colorful peacock 'eye' spots, faded edges, etc so people could really customize their wings' look, but this doesn't seem to be possible right now.It happens whether the files are PNG or TGA, with or without an alpha channel.Since the main wing textures have partial transparency, changing the blend mode to alpha mask would not solve the issue. Hopefully you can see the problem in the screenshots. You might at first think it's the white outline 'halo' issue but no, it's actually that the edges have an outline that are completely clear so the background shows through.
11
Ā·
SL Viewer
Ā·
tracked
Load More
→