🪰 Viewer Bug Reports

## Summary GLB/GLTF uploads can produce different rigged mesh deformation than DAE uploads from the same source model when the model uses a bind pose that differs from the viewer skeleton rest pose. ## Context Bind pose support is not directly exposed by Blender itself, although other tools such as Maya support this workflow. Both Collada/DAE and GLB/GLTF can represent bind-posed models through inverse bind matrices. The Avastar Blender add-on explicitly adds bind pose support and collada support to Blender-5, so this issue can be reproduced and tested using Blender-5 with Avastar. ## Steps to Reproduce in Blender In Blender, create or open a rigged mesh that uses a bind pose different from the default viewer skeleton rest pose. typical use case: A-posed models with A-Pose as restpose. Export the same model from Blender as DAE. Export the same model from Blender as GLB/GLTF. Upload/import both files into the viewer. Compare the imported results at the vertex/deformation level. ## Actual Result The GLB/GLTF import can deform differently from the DAE import, even though both files were exported from the same source model. Visible differences can include child joint twists. ## Expected Result DAE and GLB/GLTF exports from the same bind-posed source model should import with equivalent vertex-level deformation. Mesh edges may differ depending on exporter triangulation, but the rigged vertex positions and deformation should match. ## Test Notes This was tested with Blender using Avastar bind pose support by exporting the same bind-posed model as both DAE and GLB/GLTF, then comparing the uploaded viewer results.

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

In Second Life Develop 26.1.1.25711647555 (64-bit), the program crashes when opening the profile. In Second Life Release 26.2.0.25386466510 (64-bit), everything works perfectly. The crash only occurs in Second Life Develop.

Dear Team LL, I am Getting crashed at this region http://maps.secondlife.com/secondlife/Alicorns%20Hold/22/47/24 (Shakti Garden) from the past few weeks, i tried to enter the region and i was able to enter and i sarted my routine like normal again and tht lasted for only 4 days from 27th of April to 30th of April 2026 only, again today i have crashed. Before 27th of April when i was crashing i have done all the below listed trials to check if there is anything wrong on my side This region has a club in a sky box at 3000 Meters high and i was not crashing at that place before till 30th April 2026 and i was doing my Djing on tht sky box. But, today on 1st May 2026 i have crashed from that sky box too.. Entered the sim with a basic av and crashed Used different Viewers ( Firestorm , SL viewer) and crashed Did a clean install of the viewers and did a clear cache on both the viewer and my laptop still crashed Logged in with my mobile data as wifi and i didnt crashed which means my wifi network IP is got stuck with something and that is what crashing me but i am not sure what it is but i understood that the IP is connected with this issue . And our friend who did the research on this issue as said something like "checking" and "not clearing" yet the region reboot worked" i dont understand what it means may be this is got to do something with my issue i am not sure. we have installed few security Objects and Avatar trackers tht can eject below 10 days old av's to save the region from attackers who comes in with alts. and the security object is to eject the people who are not a member of the group and we insist every one to Join the group to make this place more safer and secured. I was not sure if me crashing is happening from any one of this and that too we have checked with the the owner of the sim Rosa by switching them off and entering the region when these are OFF and i still crashed which made it clear there is no issue with this objects. Today the owner of the Sim, did a Sim reset coz of my issue and i tried to enter the region again after the reset and still i crashed. I have attached a image of the window appeared after the crash as the crash shuts down my viewer and sends me this error reporting window, and i have reported few times using that window too. I have no clue what is happening and why its happening only at this region. I almost live there in SL every single day and i spend atleast 12 to 16 hours in SL every single day being online and no ever else i have crashed ever in my life and i have been on SL for the past 15 years and never came accross a issue like this before ever. This is the first time i facing issue like this. ( Below listed are the Handles of my account and alts for your refernece) Ayurvaidhya. Sushanthrockstar Resident iifygirl1 Resident ( Model Av for my MP) I have done everything mentioned by Proton Linden in the ticket replies as the points given below by you when i had the crash on the first time. (First, please restart your modem and router (Unplug for about twenty seconds before plugging back in). Next, if you are attempting to connect over a WI-Fi connection, please try connecting directly to your modem with an Ethernet cable. If this doesn't resolve your connection issues, please then disable any anti-virus programs you may have running. Next, please restart your computer, modem, and router at the same time.) this is done multiple times as exactly as told by you in the past two weeks and nothing helped and i was still crashing. I am Crashing only at the Location region i have mentioned in the earlier report and i spend like 12 to 15 hrs every single day till today and i never crash in any other sims except shakti garden ever not even a single time. And when i crash my viewer just shuts down and i get the Bugsplat window to report the crash and no other crash messages. i am attaching the support documents like the viewer version details, netwrork speed test details, IP address details and my system information. its not letting me attach the log report of my FS viewer tht i saved and kept after the last carsh. pls let me know how to share it or its already shared to Proton Linden in the tickets number #2500495 which is linked with this issue. My over all issues is i am crashing only at this region and all my alts also crashing only in this region. when i use my mobile data as wifi, i am not crashing. pls do the needful at the earliest. Many thanks , Ayur

Wrote notecard. Clicked 'save'. Notecard went black, with message in white: You are not authorized to view this notecard. The only choice was delete. This happened twice while I was writing poems for Tiny Poetry Slam. Very frustrating!

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

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.