🪰 Viewer Bug Reports

Summary: When left-clicking a media-on-a-prim (MOAP) surface outside Build/Edit mode, the viewer displays selection-highlighted geometry, including face/vertex/mesh outlines. On some mesh media surfaces, this creates dense visible lines over the media itself, making the media interface difficult to see or use. This appears to be tied to the general selection highlighting behaviour. Disabling RenderHighlightSelections / “Enable highlighting” hides the outlines, but that also removes useful selection highlighting while building, so it is not a practical workaround. Steps to reproduce: Log into Second Life Viewer 7.2.3. (Currently using Firestorm in parity with Second Life Viewer: 7.2.3) Make sure selection highlighting is enabled: Preferences search: “Enable highlighting” or debug setting: RenderHighlightSelections = TRUE Rez or find an object with media-on-a-prim / shared media applied to a face. Preferably test with a mesh object or a non-flat / multi-face mesh surface using media, as the issue is much more visible there. Make sure Build/Edit tools are not open and that the object is not being edited. Left-click the media surface to interact with the media. Observe the visible selection outlines / face or vertex-like lines drawn over or around the media surface. Expected result: When interacting with a MOAP/media surface outside Build/Edit mode, the viewer should allow interaction with the media without rendering intrusive build-style face/vertex/mesh selection outlines over the media. Selection highlighting should remain available while actually building/editing, but media interaction during normal use should not obscure the media UI. Actual result: Clicking a MOAP/media surface automatically selects or highlights the object/face, causing visible selection outlines to appear. On mesh media surfaces, this can show dense geometry/vertices/face lines over the surface. This makes some media menus or media UIs hard to navigate. Disabling “Enable highlighting” or setting RenderHighlightSelections to FALSE removes the visual problem, but also removes useful selection highlighting while building/editing. Impact: This affects the usability of media-on-a-prim / shared media interfaces, especially mesh-based media menus and HUD-like media panels. The media can become visually cluttered or difficult to read after clicking on it. Notes / suspected cause: Residents discussing the issue noted that MOAP interaction appears to automatically select the surface/object, which may be expected for media interaction. The bug is not necessarily that selection happens, but that the viewer renders intrusive selection geometry outside Build/Edit mode. A possible fix would be to suppress rendering of face/vertex/mesh selection highlights for MOAP/media interaction when the user is not in Build/Edit mode, while preserving normal highlighting during building/editing. Workaround: Set RenderHighlightSelections to FALSE or disable “Enable highlighting” in Preferences. This is only partial, because it also disables useful highlighting while building. Evidence: The issue was reproduced by multiple residents. One resident confirmed the same visual effect after deliberately putting media on a non-flat surface. Another resident reproduced it by testing media on a random mesh, where left-clicking made the lines appear. The issue occurs for me on media surfaces and is especially common on mesh surfaces. Screenshots: https://cdn.discordapp.com/attachments/1185613623721205871/1502494688173752384/FirestormOS-Releasex64_8CQyTIrGcx.png?ex=69ffeab8&is=69fe9938&hm=2c0fea8450952be4c0813eb11ec40a761f711ff834a0f5c08e6de2fd4ccd81ba& https://gyazo.com/61aed53abbea909953c40a313bafe68f

All textures, when they haven't loaded yet, default to grey. For the emmissive channel of PBR, a grey texture means the whole object glows quite brightly. Normally, emmisive textures are mostly black. So, when a pbr emmissive texture is present but not downloaded, the viewer should replace it with a solid black texture

I tick this to prevent IM chaos and well for quiet some time it worked perfectly but now it's reverting back to default on each new login.

llDialog(llGetOwner(),"text\ntext\ntextabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz\ntext\ntext\ntext\ntext\ntext\ntext\ntext\ntext\ntext\ntext\ntext\ntext\ntext",["B1","B2","B3","B4"],-1); This should probably wrap just after the 's', however the line continues as far as 'u' with t on the inner edge of the panel and the u overhanging Note: this is not resolved by the fix for #5755 (confirmed in a local build of Kokua)

Testing PR for align planar faces for PBR materials https://github.com/secondlife/viewer/pull/5347 in viewer 26.2 it appears to only align the base color textures and not the other textures normal/ORM. Also side note reviewing the github notes it looks like it was only ever tested with a base color texture so it might be needed to add a full material (Basecolor/ORM/Emissive/Normal) to QA testing.

when receiving a teleport notification, the superior part of the text is going out of the window.

This has been an issue that comes up for since at least version 7.1.9 where sometimes reflection probes will only render when the camera is inside of them then derender when the camera leave like it's getting culled. Most of the time I've run into it is from attaching probes to other items, take them then rerez then out but it wasnt always consist repro. Testing out the latest version 7.2.1 I've seen this is still an issue and now I've found a location where a probe doesnt appear to be attached to anything else and its just a normal inworld object and so far is consistent in repro this problem. Video showing issue. https://drive.google.com/file/d/1GE3ZVVpG86qGXx01u0gW0LnEg_wtMt7Y/view?usp=sharing The location is not my house but another users house so out of respect the location is in the Viewer Info section only. UPDATE: Did more testing and wiped out cache and settings. On High preset for graphics I am able to reliably repro this even in the LL roads at the new Ridgewood exclave sims at the car rez parcels. http://maps.secondlife.com/secondlife/Tequila%20Rosa/103/154/26 Rez a prim Set to reflection probe Notice will derender when camera leave probe. A few times I noticed setting max reflection probes to Ultra would cause probes to render as expected how ever as soon as I change the draw distance from 128 to 192 the same problem started happening again even when I reduced the draw distance back to the original value. In this area there is only about 2-3 reflection probes in a 1-2 region distance. Note that this issue has seen since before Max Reflection probe was implemented just not consistently repro.

upon initial log in after installing the block list is fine block list is empty upon a new log in every log in after that the block list remains empty even after adding avatars to the block list again after clearing cache block list comes back but empties once relogging and letting inventory load completely also happens on the latest firestorm release edit: cannot update to add photo of empty block list

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.

Install a space navigator device; enable it in Joystick configuration. If the latest drivers from 3D Connexion are installed, it will not function at all. If the drivers are de-installed , it will function in Second Life viewers in a crippled way.