🪰 Viewer Bug Reports

Full bright faces are getting influenced by the environment (EEP) settings when it shouldn't be affected. Specifically from the Brightness/HDR Scale slider and sort of from the Reflection Probe Ambiance. As for how much does the Reflection Probe Ambiance affect Full Bright, the effect is minimal regardless if inside or outside of a Reflection Probe and I wouldn't worry about it too much. Though it does in a way do something "helpful" with Full Bright, which I'll mention later. As a side note for any reader that might not know, any of the following URL links below that mentions Windlight or URLs about it from your own research - EEP is what "replaced" Windlight. Same with how from what I understand and found out in terminology that Scene Gamma "replaced" Gamma. After that the Brightness/HDR Scale replaced Scene Gamma. Though the only way I've seen the Brightness slider turn into HDR Scale is when Reflection Probe Ambiance at a minimum is 0.01 or higher. https://jira.secondlife.com/BUG/107935.xml https://media.invisioncic.com/Mseclife/monthly_2019_04/image.png.91b5e5f276502b7a23be6c48e8cf19fa.png https://media.invisioncic.com/Mseclife/monthly_2026_08/Environment-PersonalLighting.jpg.e05e90ebd229e199fe01096710360e1d.jpg The 1st image URL is a Windlight XML example. The 2nd image is the EEP Personal Lighting menu before PBR. While the last is after PBR was introduced. The following is an example video of going through the different sky options that have different Brightness/HDR Scale settings. The default is 1.0, but could range above or below that number such as 0.91 or 1.5 and etc. Though you could test with your own Brightness slider levels to see the effect yourself in any sky option. - https://gyazo.com/d496db80fc20f4c77ae0960db3355ea1 The "original" Full Bright - https://wiki.secondlife.com/wiki/PRIM_MATERIAL_LIGHT How Full Bright is supposed to and expected to work - https://wiki.secondlife.com/wiki/Deferred_Rendering_Test Now back to the part about the Reflection Probe Ambiance (RPA). From what I tested, the overexposure from Brightness is "mostly" countered when RPA is active (0.01 or higher). Which brings me to an idea of two solutions, that is if possible to do either one. The first idea would be to either give users a checkmark next to Full Bright to set the face Brightness to always 1.0 regardless of whatever the "Sky - Brightness" is set to or to just have Full Bright always set to 1.0 Brightness. The second idea/solution would be to have something similar to RPA applied to the Full Bright face to counter Brightness, but with this you could do what I mentioned earlier and have a checkmark option for it next to Full Bright or when Full Bright is on just have it always applied. Though for either solution, maybe best to just give people a checkmark option to allow a natural transition for those that want it or don't want it. As for those that might say, well you could just change the Sky EEP or manually set that Sky EEP Brightness down to 1.0 but the problem with that is that it wouldn't exactly be a solution since that would ruin the look of those specific EEPs or parcels/sims in the first place. At least with my maybe possible solutions it gives creators or parcel/sim owners a choice for the creative look they're going for. Lastly, is it fully possible to do this? I don't know and also depends on how things were scripted. Though with how RPA interacts with Full Bright regardless of a Reflection Probe being there or not, seems to suggest that it might be possible to add something like this to Full Bright to counter Brightness/HDR Scale and it wouldn't hurt to give it a try because of this.

Alt-click camera motion when combined with CameraMotionSmoothing > 0.0 results in violent lunging and rebounding of the camera position. CameraMotionSmoothing defaults to 1.0 and I have been using it set to 30.0 for years.

We are comparing rigged mesh export from Blender to Second Life via both .dae and .glb. We can export both formats so that they behave identically in SL, but only when deformation is limited to the standard m* bones. As soon as SL volume bones are also marked deform, the .glb result differs slightly from the .dae result after the mesh is worn on the avatar. The imported static meshes are identical. The difference appears only after wearing, when the SL rig actually deforms the mesh. A few details: -same source rig and mesh same visible export mesh in Blender before writing the file same result in SL when volume bones are not deforming mismatch appears only when volume bones participate note that volume bones have the known non-neutral/rest-scale oddities Does anyone know how SL’s .glb importer handles volume bones internally, especially their rest/bind transforms or scaling? We are trying to determine whether the difference comes from Blender glTF export, Avastar/Collada export assumptions, or SL’s handling of volume-bone skinning.

Every time I log in, while its says Loading world, the music stream for whichever land I am in kicks on FULL VOLUME, even if I have the sounds muted in-world, if we use headphones it blasts full volume hurting our ears

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.

The audio quality is poor with a Bluetooth headset, when the voice chat is active, even if I don't say anything, the viewer is activating the microphone all the time. It only gets better if I turn off the voice. My operating system is a Windows 11. This is also happening in the beta versions of Firestorm, but it doesn't occur in release 7.2.4

Got a notecard from Dench Designs, and opened one of the textures embedded therein. Instead of the old "Copy to Inventory", it says "Copy to Inventor". Looks like somebody accidentally chopped off the Y? (Very minor bug, but should be an easy fix.)

From my Windows Event Viewer the error is... Faulting application name: SLPlugin.exe, version: 0.0.0.0, time stamp: 0x6a1d6e23 Faulting module name: libcef.dll_unloaded, version: 139.0.40.0, time stamp: 0x68a38762 Exception code: 0xc0000005 Fault offset: 0x0000000003a84b9e Faulting process id: 0x63A4 Faulting application start time: 0x1DD52E2C39864E5 Faulting application path: C:\Program Files\Firestorm-Release\SLPlugin.exe Faulting module path: libcef.dll Report Id: 7d394f76-ca61-4886-9032-33aa4ac68ca5 Faulting package full name: Faulting package-relative application ID: This is non-stop, it happens sometimes on teleport, sim crossings, and the MOST annoying is it happens frequently when I'm standing still or just moving within a sim. I've tried everything under the sun, clean installs, cache clears, usin' different versions of firestorm and second life viewer, clean install of my 4090 drivers, rolling back those drives, swapping out my modem through xfinity, used AI, and nothing works! It's to the point I can barely log in and do anything, please if there are any fixes or if this is a known issue bein' worked on let me know!

See https://jira.firestormviewer.org/browse/FIRE-36985 . Official sl, firestorm and other sl viewers have multiple instances in the dock and at activity monitor. It happen when i startup a viewer and i can quit them but they appear sometimes when i teleport again. It is only with sl viewers for me, not with other apps.

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.