🪰 Viewer Bug Reports

The eyedropper tool for PBR materials in the Build Floater (Materials tab) does not correctly apply the selected material. If a user creates a PBR material and applies it to an object (for example, a cube), then creates another object and attempts to use the eyedropper tool to sample the material from the first object, the tool does not apply the material to the selected object. The eyedropper appears to select nothing and no material is applied. ## Steps to Reproduce Create or upload a PBR material. Rez a cube and apply the material to it. Rez a second cube. Open the Build Floater and go to the Materials tab (with PBR materials selected). Use the eyedropper tool to sample the material from the first cube. ## Expected Result The sampled material should be applied to the currently selected object. ## Actual Result Nothing happens. The material is not applied to the selected object. ## Additional Information This issue has existed since the initial release of PBR materials and has been mentioned multiple times during the Content Creation User Group (CCUG) meetings. A previous report describing this same issue exists in the archived JIRA system: https://github.com/secondlife/jira-archive/issues/11664

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

A few days ago I started experiencing an issue with SL not "seeing" the .tga image I saved after creation in PhotoShop. When I try to upload the image, it is visible in the list, but ghosted and not able to be uploaded. I also reproduced this issue trying to upload it as a .png, same thing. It seems someone made SL more picky about images and now there's lots of fails. It's so disappointing to try to work on a texture to perfection and then can't get it to upload. It works sporadically, I am able to upload about 20 - 40% of the attempts. It was especially bad yesterday (Feb 3).

Scenario: you have UDIMs 1001, 1011, 1012 in Substance Painter, but you tick only 1001 for exporting to GLTF. You then choose to upload all materials in the GLB/GLTF file in the SL Viewer. The file still has information about the other tiles, so the viewer creates Material assets for all of the UDIM tiles, even though only 1001 has textures to go along with it. It shouldn't have created these empty assets. What needs fixing: The Material uploader need to check for texture data for each material, if there is none it should not create Material assets for it in the inventory. Ideally, it should not offer to upload them even.

Create folder in inventory root (for example) and name it Right-click that folder > Upload To Folder > Material... Find and complete the upload Observe that the uploaded assets does not land in said folder, not only does not the Material asset land in there, it's also separated from the texture assets belonging to it I have tested this with mesh uploads too, that seems to work. Image uploads and audio does NOT seem to work, they land in the Textures or Sounds system folders instead, bulk uploads as well as singles. I have not tested with animations.

I used the latest SL viewer to upload a mesh containing three materials and deleted the place holders from the lowest LODs in blender. This would have usually thrown an error but it's been reported that meshes can now be uploaded this way. I applied the materials to my mesh faces and logged out. I logged back in and the faces were all showing one of the materials rather than those alocated. They also look this way with the latest firestorm viewer. I tried again today thinking it may have been lag, but it happened again, the meshes looked fine at first and when I teleported out and in again, they were showing incorrrect materials.

i have a rigged t-shirt, with duplicated faces for decal textures. these decals are separate object (link) from the t-shirt, a microscopic distance away from the surface. when i put an alpha texture on the decal, while the shirt is on the ground, all is well. but when i wear it, some blotches appear in the transparent areas of the texture. this is while in alpha blending mode ! additionally, there is a halo around the edge of the opaque part of the texture. in the example image, the purple (and black) edges around the bottom of the butterfly wings are actually my skin showing through the underlying shirt. (which has NO alpha. and i set it to none, too.) also: i'm wearing a rigged mesh avatar, using BOM skin, with an alpha layer 'tattoo' on the universal layer. it is using BAKED_UPPER. this may be related to this issue: https://feedback.secondlife.com/bug-reports/p/unwanted-edge-transparency-in-bom-universal-aux-channel-layers

There's a visual glitch when using more than one BOM texture layer on a Universal Aux channel if there's partial transparency in the texture using Blinn-Phong textures. I've made BOM textures with partial transparency for rigged fairy wings, so that customers could layer a stripey texture on top of the main wing texture. However, it's as if there's an outline of 100% transparency around the edges of the upper stripey texture that punches a hole straight through the underlying wing texture as well. It shows up the most when in front of a bright background. I tried making the stripe texture completely black with a 100% transparent background by converting it to a vector and then converting it back into a raster image in Photoshop, and this minimizes the issue so that it's only visible if you're very zoomed in, but this means there can't be layered BOM textures with blended edges at all on the Aux channels. I had envisioned being able to make add-ons like colorful peacock 'eye' spots, faded edges, etc so people could really customize their wings' look, but this doesn't seem to be possible right now.It happens whether the files are PNG or TGA, with or without an alpha channel.Since the main wing textures have partial transparency, changing the blend mode to alpha mask would not solve the issue. Hopefully you can see the problem in the screenshots. You might at first think it's the white outline 'halo' issue but no, it's actually that the edges have an outline that are completely clear so the background shows through.

Whenever I tick the "align planar faces" box I get this message: We are sorry, Linden Lab has discovered degraded performance on your connection to the region you are on. You will need to restart Second Life and log into a new region for the next 30 minutes to an hour. We apologize for the inconvenience. After that, I am unable to edit any objects or textures. I mainly use Firestorm, so that was what I was using when it first happened. But it also happens on the SL Viewer. I have also tested on different sims and in a sandbox with the same results

Description: When importing a Collada (.dae) file from Blender into Second Life, one or more objects within the mesh linkset frequently get renamed incorrectly, even though all object names are clearly and uniquely set in Blender prior to export. This issue occurs systematically: All objects are properly named in Blender. The .dae file is verified to contain the correct object names. However, upon import into Second Life, at least one object's name is arbitrarily replaced by the name of another object in the linkset. This results in duplicate names in the final imported mesh, despite no such duplication existing in the original .blend or .dae. This bug makes it extremely difficult to manage and script mesh components reliably, especially when using scripts that rely on precise object names via llGetLinkName(). Steps to Reproduce: Create a multi-object mesh in Blender with uniquely named objects. Export to Collada (.dae) using SL-compatible settings. Import into Second Life using the Mesh Uploader. Observe that one or more objects are renamed incorrectly during or after import. Expected Behavior: Each object should retain its unique name exactly as defined in Blender. Actual Behavior: At least one object name is replaced by another object's name, leading to incorrect duplication. Notes: This happens regardless of naming conventions (e.g., simple vs. complex names, underscores, numbers, etc.). It's not caused by Blender's export; inspecting the .dae shows correct names. The issue seems to originate during SL’s import processing stage. Please investigate and correct this persistent and highly disruptive behavior. Just a final note: it's been this way for years. It's annoying having to check each object name one by one just to find the one that's not named properly.