🪰 Viewer Bug Reports

I know some unofficial viewers have the ability to block ad-hoc/temporary/conference group chats entirely but that is not what I am proposing. What I am suggesting is that no one should be able to add anyone to an ad-hoc group chat by a person that has them blocked. Doing so would leave ad-hoc group chat functionality enabled for everyone else you know but disable blocked individuals from initially adding you to theirs. If you have someone blocked right now they can add you to one of these temporary groups and instead of the group IM opening from their initial text the next person to speak forces it open for you. People have exploited this to make tons of these groups just adding or removing a few people and starting a new one which essentially they can open infinite group chats for someone as a means of harassment and using others reactions to troll a person even if they themselves are blocked. This can range from being a bit of a nuisance to the level of entirely flooding someone with these. There is a lot of things someone who is blocked can do to the person that blocked them still that surprisingly have been allowed to persist for over a decade and this is one of them I think should not be possible. This isn't a proposal to get rid of the feature entirely, just disable the ability for a blocked person to add you to one of those.

Apply a rotation in Blender for a mesh, so that it is at zero rotation. Upload this mesh to SL using glb. Upload the SAME EXACT mesh using Collada. The Collada will be correct. The glb will have a 90 degree offset on the X-axis (rendering it useless if part of a scripted object)

Title. I've blocked this event owner who has absolutely SPAMMED me with invites over the past few weeks. It was ridiculous it was something like 3 or 4 notecard invites per day, every time I'd log on I'd have multiples. I blocked the owner and I blocked the object they were being sent from. They've apparently since created a new object and SL isn't giving me the object name this time for some reason so I can't block it. Why on earth are users we've blocked still able to send us things via object? Why aren't all of their objects blocked by default too? Blocking is supposed to block all interaction with them not just direct messages. Please fix this, it's really really irritating and I keep having to delete tons of notecards from this person. They're already blocked, I should see absolutely zero items from them in my inventory.

The teleport notification isn't removed when you receive a teleport in the top-right corner, even if you cancel it. There's also no way to remove it yourself. at Second Life Develop 26.5.0.40439849016 (64bit) There doesn't seem to be an “X” to click to close the message. I have to log out and log back in every time https://gyazo.com/d6e41b069f13972e66076e48ac3d7286

Snapshot Depth layer exports wrong distances ## Summary LLViewerWindow::rawSnapshot converts the depth buffer to linear distance with the wrong far plane, and passes window depth where the formula needs NDC depth. Depth snapshots keep the correct near-to-far order, but their values are not proportional to distance. Near the camera they read about 2 x the true distance, so a map decoded as near to draw distance gives wrong meters. Rendering is not affected, only the exported Snapshot depth layers. ## Affected source Found by reading the source. Stock viewers were not run. Second Life viewer , develop at 373addb1cbdb , Depth layer: factors , conversion , projection Firestorm , master at 2c534084d2aa , Depth and Depth (24 bit) layers (FIRE-15667): factors , conversion, 24 bit , conversion, 8 bit , projection ## Cause Wrong far plane. The factors use LLViewerCamera::getFar() , the draw distance. LLViewerWindow::setup3DRender() builds the projection with MAX_FAR_CLIP*2.f , which is 1024 m at any draw distance. Window depth used as NDC. The factors come from 1/z = (f+n)/(2fn) - ndc * (f-n)/(2fn) , where ndc runs from -1 to 1. The code passes the glReadPixels value d , which runs from 0 to 1. The correct input is ndc = 2d - 1 . ## Effect Computed with near = 0.1 m. "8 bit" is the Depth layer's gray value (0 to 255) over near to draw distance. | True distance (m) | Draw 256: exported (m) | 8 bit now | 8 bit correct | Draw 1024: exported (m) | 8 bit now | 8 bit correct | |---|---|---|---|---|---|---| | 1 | 1.99 | 1 | 0 | 2.00 | 0 | 0 | | 5 | 9.67 | 9 | 4 | 9.95 | 2 | 1 | | 10 | 18.73 | 18 | 9 | 19.81 | 4 | 2 | | 20 | 35.20 | 34 | 19 | 39.23 | 9 | 4 | | 100 | 118.81 | 118 | 99 | 182.20 | 45 | 24 | | 256 | 186.20 | 185 | 255 | 409.60 | 101 | 63 | At draw distance 256, geometry at the draw limit exports as 186 m, not 256 m. Only depth 1.0, such as sky, reaches white. ## Steps to reproduce Set draw distance to 256 m. Rez a large flat panel about 10 m in front of the camera, facing it. Without moving the camera, take a Snapshot with the Depth layer, saved as PNG at the current window size. Note the gray value at the panel. With the Edit tool, move the panel exactly 10 m straight away from the camera. Take a second snapshot and note the gray value. ## Expected The Depth layer is linear from near to draw distance, about 1 gray level per meter at draw 256. The value rises by 10 levels, give or take 1, from any starting distance. ## Actual From the formula, the value should rise by about 16 levels (18 to 34 from a true 10 m start) and the step should depend on the starting distance. This is computed from the source, not measured on a stock viewer. ## Proposed fix Replace the two factors. The conversion and encoding lines stay as they are. This form takes window depth directly: 1/z = 1/n - d * (f-n)/(f*n) . ```diff F32 depth_conversion_factor_1 = (LLViewerCamera::getInstance()->getFar() + LLViewerCamera::getInstance()->getNear()) / (2.f LLViewerCamera::getInstance()->getFar() LLViewerCamera::getInstance()->getNear()); F32 depth_conversion_factor_2 = (LLViewerCamera::getInstance()->getFar() - LLViewerCamera::getInstance()->getNear()) / (2.f LLViewerCamera::getInstance()->getFar() LLViewerCamera::getInstance()->getNear()); + // Depth comes from setup3DRender()'s projection, whose far plane is MAX_FAR_CLIP * 2 at any + // draw distance, and the conversion below takes window depth d (0 to 1), not NDC (-1 to 1). + const F32 depth_near = LLViewerCamera::getInstance()->getNear(); + const F32 depth_far = MAX_FAR_CLIP * 2.f; + F32 depth_conversion_factor_1 = 1.f / depth_near; + F32 depth_conversion_factor_2 = (depth_far - depth_near) / (depth_far * depth_near); ``` Behavior changes with the fix: Maps get darker up close, because near distances stop reading double. Geometry at or past draw distance becomes white, the same as sky, so the two can't be told apart. The value is distance along the view axis, not radial distance from the camera. ## Verification Tested on a viewer based on Firestorm, with this fix applied. Depth (24 bit), PNG, draw distance 256, camera held still, panel moved exactly 10 m: | Snapshot | Packed value at center | Decoded distance | |---|---|---| | Panel at start | 641389 | 9.883 m | | Panel moved 10 m | 1296988 | 19.883 m | | Difference | | 10.000 m | Sky read 16777215 (white) in both snapshots. Not tested in the viewer: the 8-bit Depth layer, draw distance 1024 and upscaled captures. A numeric simulation of the path from true distance to export, using 24-bit depth and F32 math, matched true distance to within 5 mm up to 200 m and within about one depth-buffer step (0.6 m) near 1 km, at both draw distances 256 and 1024.

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.

As per https://wiki.secondlife.com/wiki/PBR_Materials#Unsupported_use-cases reflection probes are not supposed to work as attachments or on physics objects. > Wear a reflection probe. This intentionally does not work. Except, it does work - you just have to make the probe be a linked part, rather than a root object. This should be fixed so it doesn't become a feature due to people exploiting it.

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.

I am unable to get past the login in process. The world rezzes, i hear music, but my avatar and viewer is frozen behind the login banner. The screen flashed a lot, progressively down to my desktop flashing wildly. I logged in via terminal, I saw a few errors, starting with fonts not being recognised, the were more errors that passed past me quickly, and it did not identify my NVIDIA Graphics Card: NVIDIA GeForce GTX 1070/PCIe/SSE2 CORRECTLY, both viewers Kokua and LL 26.4 think I have a Mesa Graphics Card: llvmpipe (LLVM 20.1.2, 256 bits). I have been told that the SL Boffins are closing in on releasing 26.5 soon and then the good volunteer Devs at Kokua will follow with an update a couple weeks later. Will the issue be fixable, i have rarely had viewer issues in the past. I use linux as my only OS, I am not very skilled with it.

FIX EEP, Mainland environment cycle are way too dark, see my forum post https://community.secondlife.com/forums/topic/428374-environmental-enhancement-project-aka-eep-feedback-thread/page/41/#findComment-2861867