🪰 Viewer Bug Reports

The flyout button control still uses the old 3D-style textures and did not yet get updated with the flat design update. The button is currently used in panel_snapshot_local.xml - see attached screenshot.

I am experiencing ongoing spam from the account ChristophNaumova33, which appears to be a bot. The account is already blocked on my end, however I am still receiving approximately 40 daily spam attempts. While the block prevents messages from being displayed, the system still logs each attempt (including ad-hoc conference/group invite attempts). This is flooding my chat history and impacting my ability to use chat logs for Second Life business purposes. Key issues: Account is blocked but spam attempts continue daily Block does not prevent conference/group invite attempts being logged Chat logs are being heavily spammed despite no visible messages Ongoing impact on usability of chat history due to volume of entries The bot was originally encountered within the Fifty Linden Friday group. After continued spam, I asked in the group whether others were experiencing the same issue, and several users confirmed they were also being targeted but had successfully blocked the account. I am unsure why blocking is not fully preventing the same behaviour in my case. I have reported this issue daily, but the account remains active and the behaviour continues. Reference evidence: https://gyazo.com/66369e0ddd647ef2c7f6300df406d63f https://gyazo.com/400f8b9cb56b2acf4950a19e149adfcc Requesting investigation and mitigation of blocked-user invite/logging behaviour.

## 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.

With the Flat UI viewer, the llDialog window is smaller than before, so the string "————————————————————————————" doesn't fit in anymore (see attached screenshot). I would need to cut 4 characters for it to fit in basically all my scripts I am selling (3 would not be enough because of the line break). It would be good if the dialog window was wide enough for it to fit. This also happens on 4K with a UI scaling of 130% and a font DPI of 104, but the test below was done with default settings on Full HD, as you can see from Viewer Info.

While Edit window is open, right/left click on an avatar and it will often select through them. This often includes your own avatar, especially if it's the base body (like BoM). Right click out of Edit will pretty consistently bring up the correct item for inspection. This is a typical way I check to see what another person is wearing, and it's especially useful if I need to check links for particular names or features. More often than not, this is for moderation or when a friend is asking for help.

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 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.

See attached picture. This appears next to the SLURL Bar on a fresh account

Textures are extremely slow to render. This is happening to about myself and a dozen friends of mine. For some reason over the last two weeks textures in SL irregardless of if they are 1k or 2k are taking forever to render a great amount of the time. It also seems to be affecting performance of each viewer as well. I can provide images and video recordings if requested. Clean installing, clearing cache, increasing cache size limits, etc. all do not change the issue.

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/