🪰 Viewer Bug Reports

"If the 2D don't work, the 3D don't work". I was at Sci Fi Con 17. All day long, no matter how many or how few avatars were on a region, textures took ruddy ages to load. Now one might say "There are so many textures at a big event it just takes a long time." But I'd walk into an enclosed room... where textures should be limited, yet the vendors on the wall just sat there and sat there and sat there. Textures RIGHT NEXT TO ME fail to load. One can stand there and stand there and stand there... and they still don't rez. I would click on a texture and tell it TEXTURE REFRESH... and it would ignore that instruction. I first reported texture issues and bottlenecks back in 2005. Now my computer and graphics card is hundreds of times more powerful... and textures still load at a snail pace. I will say the same thing I said back then: There is a texture bottleneck on SL. (Or, several texture bottlenecks, and it affects EVERYTHING.) With respect, I'm not asking for an explanation, nor excuses. I'm making a simple observation: After 22+ years online, Second Life should be able to very quickly load 2D textures in an enclosed room. Is this not correct? I suspect there will be people all too ready to give reasons why textures load slowly. To any and all such reasoning, I have one answer: Second Life needs to make textures load quickly. There's no argument, debate, discussion or excuse to that simple statement. Users need textures to load quickly enough that we don't get bored standing in a store (waiting for vendor textures to load)... and decide to go do something else. Like Netflix. ;D Because that's what it is: Second Life vs Netflix. Users have options on how to spend their time. When Netflix can stream entire videos realtime, surely Linden Lab should be able to send 2D textures across the Internet... yes? As a note: I'm not going to debate nor discuss or argue with those who are always ready to argue on these feedbacks. The feedback is posted, I've said what I came to say... and I have to believe the vast majority of SL users will agree with this: textures on SL need to load faster.

In the texture/material properties of an item, the scale, offsets and rotations are set in the edit window. However, when any PBR material is applied, it resets to the default values of 1.0x1.0, 0u/0v, 0 degrees, cancelling any previous settings. This makes it very tedious to switch between different PBR materials. This is a request to make the scale/offset/rotation of an item PERSIST after they are set in the edit window when a PBR material is switched, instead of defaulting to 1x1, etc. with the new material, as is the case when any blinn-phong texture maps are changed.

The orientation of a prim is affecting its bump-map shadow effect (relief). An upside down prim seemingly inverts the effect, turning an emboss into an engrave. This is showing in Firestorm and LL viewer, which was updated moments ago. The effect is shown in the images below -First is a single prim 1m square -Second section is a 4x4 grid of 0.25m prims, rotated differently but textures aligned -Third and Fourth are the same things using Materials rather than Blinn-Phong, which do not have the issue The bug is the Second section showing differing relief amounts even though they are co-planar and same orientation. The difference here is the orientation of the prims themselves.

PARTICLE RENDERING: Please fix the system default particle rendering. Specifically, the white dot default particle in version 6 (pre-PBR) is perfect, but now in version 7 it shows up as a white center with a visible square outline. An alpha issue I believe. This is the system particle which is called by default when no texture is added to the emitter. It is the basis for so many generic particle generators. So it would be great if LL could just tweak this little one for us please and smooth away the edges :) ! https://gyazo.com/97e97aeb4f68771c3c0c9791d444da9c

I have cleared cache 5 times, submit a ticket to LL 5 days ago without a reply or advice, and it won't let me add, delete, or even chat. This has been going on for a whole week on every single sim I teleport. I even had to change into a LL avatar and see if it resolve the problem, but now, I can't change into my usual avatar. I logged with my alt to see if the problem had to do with connection/network problem, but it was doing well and everything was normal. Can some one please help me. Thank you. [17:40] Second Life: Your inventory is experiencing issues. Please contact support of your grid. [17:40] Second Life: Your inventory is experiencing issues. Please contact support of your grid. [17:40] Second Life: Your inventory is experiencing issues. Please contact support of your grid. [17:41] Second Life: Your inventory is experiencing issues. Please contact support of your grid.

Description: When placing a scripted object inside a mesh prim, even after disabling all other scripts, the object refuses to move despite having full permissions (including "take control"). The same script works perfectly when placed inside a regular prim (box). This behavior strongly suggests that residual effects from previously running scripts (such as lingering llSitTarget or similar calls) persist within the mesh prim and prevent proper control, even if those scripts are disabled or removed. Steps to Reproduce: Place the scripted object inside a mesh prim. Disable or remove all other scripts in the prim except the movement control script. Attempt to move or control the object — it fails to respond despite correct permissions and input. Replace the mesh root prim or rezz a new prim and the same script works correctly. The issue does not occur if the object is placed in a regular prim (box). Debug confirms physical presence, permissions, and input detection are correct; however, the object does not move. Expected Behavior: Disabling or removing scripts should fully stop any lingering script effects such as llSitTarget or control overrides, allowing the object to move normally under script control. Actual Behavior: Residual script effects remain active even after disabling/removing scripts, causing the object to become immobile inside mesh prims unless the root prim is replaced or a new prim is rezzed. Impact: This is a critical bug affecting scripted object control and physics within mesh prims, disrupting expected behavior and causing significant development and usage issues. Additional Notes: The bug seems specific to mesh prims and does not appear in regular prims. Replacing the mesh root prim clears the issue temporarily, indicating state persistence at the prim level. Suspected causes include improper cleanup of llSitTarget or similar functions.

This weekend (particularly Sunday 6/22), I experienced disconnects every handful of teleports using SL Viewer, Firestorm, and Alchemy viewers alternately. While that's an immediate inconvenience and concern, it's not the root of the problem: The problem is that I don't even know there's a problem. As is always the case with networking issues, "everything else" was working fine; video streaming in web browsers, connections to SL and other websites, Discord servers etc so I was not having an overall internet outage... but then, I can't really do anything here. If there's a problem on my end, I can't tell; if the grid is struggling, I can't send you anything to determine what might have been bottle-necking. When I have a viewer crash, at least I get a bugsplat thing, right? But what happens when I go to teleport to a new region, and 20% of the time, I get a progress bar just sitting still at "Requesting region capabilities" or region handshake? What's really happening under there? I know that after 60 seconds, it'll time out and "Quit" the viewer, but that leaves me with nothing to tell you about what has happened. Nothing crashed and yet, something's wrong~ I've heard many (including Lindens) refer to region changing as an indecipherable and scary mess of spaghetti code, but this is the lifeblood of the platform, and it seems to have phases where error rates go through the roof (anecdotally, during the half-day I had these issues, various group chats indicated I was not alone). A thousand little cuts in silence, and it's hard to know what to report and how. The request here is a bit nebulous, I apologize, but that's because I don't even know what LL needs, but please add something to the viewer to log region changes in some way that is meaningful to you, and that presents itself when the viewer times out and disconnects. You know that screen where I can choose to view IMs offline or Quit, when I have a timeout? Add something there, please, to open the region change log folder. (And pls make a region change log, even just to track the most recent change; it sounds as though this one area of SL activity could use better investigation). That way, when things are acting up, there's something to send to support that hyper-focuses on the specific region-change that caused the problem. I could attach that here, or send it to customer support etc.

http://maps.secondlife.com/secondlife/Pattaya/229/218/21

Differing shadow issues on every viewer I have tried. Not even sure how to put into words everything going on. Pixelated shadows, shadows only sharp at certain angles, some shadows disappear at other angles. See videos attached for examples. Viewers where you can fine-tune shadows (like firestorm) seem to have the same issue, sometimes more exaggerated by certain settings. There is no constant though, one issue could happen on a lower setting and also a higher setting- or not at all. It is incredibly random. Also possibly related is a texture issue- seeing a seam between heads/bodies. I cannot see the seam on my PC, but I see it on my Mac. Other people on PCs and other versions of Mac chips cannot see it. To recreate: 1.) Be on a Macbook Pro M4, current version Sequoia 15.4.1 2.) Simply cast shadows anywhere and move your camera Album with a few videos showcasing issue on both LL Viewer and Firestorm: https://imgur.com/a/sl-shadow-issues-j0QtjoQ

Clip Demonstrating Behavior: https://youtu.be/LuTbgsij74M Additionally, it appears that the texture alignment overlay is always tied to the transforms of the Blinn-Phong material. To Reproduce: Rez two prims and place them next to each other. Place a glTF material on adjacent faces on prims. Set texture mode to Planar Ensure both texture transforms of both faces do not match. Click Align Planar Faces Checkbox