🪰 Viewer Bug Reports

I spent days trying to find the bug in my flight physics code that was causing this, only to discover that it was the viewer camera all along. The problem is that sometimes the aircraft flies "visually" smoothly at any speed up to 100 meters/sec; and other times it's visibly jerky, appearing to "vibrate" (change in apparent size many times/sec) as though the camera was acting like a spring instead of being fixed in place behind the vehicle. I'm using the eye/offset calls: llSetCameraEyeOffset(eye); llSetCameraAtOffset(offset); This is because the "newer" (21 years old instead of 23) follow cam is missing features that would be necessary to produce the same behavior, and I find it unsatisfying and confusing to use for aircraft. I instrumented my vehicle with code that captures llGetVel() and llGetOmega() 20 times/sec (rotated into the local reference frame), then uses llSetText() to display mean, standard deviation, and range once per second. What I discovered: Sigma (standard deviation) for local X can be very low (0.0 to 0.02) in level, unaccelerated flight regardless of whether the visual apperance is jerky or not. There is no difference. When it's visually smooth, sigma can actually be quite a lot higher, closer to 1, and it still looks totally smooth. This happens during accelerating and turning. Local Y's sigma is typically very close to 0 in either case. Local Z's sigma is typically very close to 0 in either case. All three axes of llGetOmega() are always zero unless the aircraft is turning, climbing, descending, or yawing. If the statistical analysis is not enough of a smoking gun, here's another: When the aircraft is flying smooth, and I refocus the camera on my avatar, it starts getting jerky, like the camera is damping at some wild speed. Single-frame jumps of tens to hundreds of pixels along the axis of motion. The attached screenshot is the llSetText() stats output when the camera was jerky. Zero standard deviation in this regime + jerky visuals, vs. standard deviation WAY higher during maneuvers when the camera is smooth, provides strong evidence that this is a viewer bug. My code is invariant either way. My stats are invariant either way. When flying smoothly, refocusing the camera makes it do the jerky rendering thing. And sometimes it does the jerky rendering thing whether I do that or not.

Requires AMD GPU, Adrenalin 25.10.2 or later. See attachment for a visual of the issue. Toggling AO makes no difference. Please note that there is a risk of this issue being prevalent for many months to come if Linden does not exert pressure on AMD to work together on a solution to this rendering issue. I'm speaking from experience with other software. The workaround is to revert back to 25.9.1 driver. Others complained here: https://reddit.com/r/secondlife/comments/1olf72w/skinclothes_glitching/

It disappears or gets dimming when I change the shadows from sun/moon + projector to None. It keeps the light level and the vision when I change the shadows from sun/moon (NO PROJECTOR) to None. It seems the ambient occlusion and depth of fields are affected, because when both are on, this didn't happen. I took a video because it's easier to show than screenshots. I couldn't upload video here, so I made a link: https://drive.google.com/file/d/1r3FSMm61b3bdQvqt93HNth47A9E4oIde/view?usp=drive_link

I simply have to look around my properties (SL home and also rental).

When taking a snapshot with Screen Space Reflections (SSR) enabled in the viewer, reflections visible on reflective surfaces in the viewer window are not captured in the resulting snapshot. This results in a discrepancy between what the user sees in the viewer and the final saved image. Steps to Reproduce: Enable Screen Space Reflections in the viewer settings (Graphics -> Advanced Lighting Model -> Reflections -> Screen Space Reflections). Position your avatar in a location with reflective surfaces (e.g., near water, mirrors, or shiny objects). Ensure that reflections are clearly visible in the viewer window on those surfaces. Take a snapshot using the in-viewer snapshot functionality. Observe that the saved snapshot does not include the reflections that were visible in the viewer. Expected Result: The saved snapshot should accurately capture all visual elements present in the viewer window, including screen space reflections. Actual Result: The saved snapshot is missing the screen space reflections, resulting in a visually inconsistent image. Workaround: None known. Affected Versions: [Specify affected viewer versions] Attachments: Snapshot_001.png - Result of the snapshot showing the missing reflections. Viewer_Screen_Snip_Capture.JPG - Screenshot of the scene as seen from the viewer in-world, with reflections clearly visible.

These two screenshots demonstrate the issue. The first is with highlight transparent turned on, some of the red transparent objects are reflection probes. However, when show reflection probe volumes is turned on, I cannot see the volumes – only bright yellow. A note: the yellow gets brighter over time. When first loading the area, it is a pale transparent yellow. After a while of sitting in the same space, the whole screen is eventually just opaque yellow. Altitude and which region I'm in does not matter. You can reproduce this in a sandbox with a single probe. Toggle "show reflection probe volumes" on and you'll see its uselessness. I'm on an apple silicon mac and have seen this happen on every viewer. I just found out some of my windows-user friends are able to use this option just fine, so it seems like this is a bug.

Repro: 1) Go to: http://maps.secondlife.com/secondlife/Fenfarg/4/124/36 2) Wait for things to fully rezz around you 3) Rotate camera around your avatar, to make sure everything around you is rezzed 4) Change environment setting to Midday (the new PBR version) 5) Stand around, and rotate the camera around for 30s or so. 6) Things will go weird black and white, (See Attached Image) 7) Change to any other environment setting like Midday Legacy 8) Change back to Midday 9) After 30s or so, everything will go dark again. Issue seems to be limited to this specific area. But I have seen similar things happen once in a while in other places around SL, this one however seems to be 100% reproducible. Reproduced on both Official viewer and Latest Firestorm.

I've become aware of a texture rendering issue that impacts textures when on a face. It's not so much an issue that only impacts PBR textures, but it is exponentially worse and makes certain designs as mastered in Substance unusable as PBR. I'm not enough of a rendering brain to understand what is going on here, but it's my belief this is not correct and is a bug. I hope that this will get in front of the right people to be evaluated and hopefully fixed. This is being demonstrated with a 0-25% gray bi-linear gradient, however anything that uses color and gradients near this will exhibit the same obvious defects. A single example using real-world art is included for reference. Texture UUIDs Dark gradient lossy: cac83520-08b2-500f-b683-1ede13d4e052 Dark gradient lossless: bd66f42c-6b56-780e-c183-3307151f8292 Raw files, non-anotated screenshots, and sample items shown are available upon request but I don't think they will be necessary. As I was sharing this around with creator friends moments before submitting this I was made aware this may be or have been a known bug, and can be alleviated entirely on the material side by setting the alpha mode selector to blended. Masked and opaque do still exhibit the shown issues. This made me frown. There is no alpha channel on the textures shown.

Today I installed a new version of the Firestorm viewer. When I logged in with the updated viewer I was confronted with horrible looking light (darkness, shadow, who turned the sun off?). To check if this was not a Firestorm viewer bug I did install the normal Second Life viewer but the issue remained. This forced me to uninstall the new viewer and return back to the one I used before. I opened a thread of the forums with documentation including screenshots to compare etc... https://community.secondlife.com/forums/topic/530821-i-have-to-find-this-normal-what-took-place-am-i-missing-anything/ I do not understand when Linden Lab developers break things like the render quality of EEP or PBR they are allowed to put their broken code results in the viewer and get it approved for normal release. Is this good enough? No it obviously isn't. Linden Lab lost all these users related to the introduction of PBR so it is really annoying to see how careless developers are with code updates that trash the visual aspect of Second Life like this. I rent land to people in Second Life, when Linden Lab provides such a meager result because of broken code and poor rendering quality updates residents will not be very eager to invest in land or their landscape. I see more people here filing bug reports about this so I hope this will get priority to fix. After the release of PBR the visuals were horrible, then it got fixed but now it is horrible again and you put that code in the viewer again. Also trying to tweak the exposure slider did not impact the light at all under the new viewer, in the old viewer version exposure is set at 1.0 and everything looks fine. Looking forward to see this fixed in the very near future.

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