🪰 Viewer Bug Reports

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.

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

Since June 10th, I have been experiencing a significant increase in "Service Unreachable" warnings while uploading 2K PBR materials exported from Adobe Substance Painter using the glTF PBR Metal Roughness workflow. The problem seemed to be concentrated between June 10th and June 12th, then improved and became limited to just a few random errors. Today, June 25th, the problem is back on my end. I have checked my internet connection, restarted my fiber router, and confirmed that my connection is stable, yet the issue continues to occur. I can log out and back in, successfully upload one material, and then immediately receive the warning when trying to upload a second one. If I bulk upload an entire material set, some materials upload successfully while others fail. Sometimes the material upload window gets stuck trying to save, and I can't close it because it appears to still be processing one of the texture maps. At that point, I have to relog. This issue seems to happen much more frequently with 2K textures. Since my UVs are optimized for that resolution, switching to 1K is not a practical workaround. Normal maps seem to be affected the most and fail more often, but on days like today I'm also getting errors when uploading base color and metallic-roughness maps. I know there have been previous posts about this issue, but I believe it continues to resurface and may still require investigation.

https://gyazo.com/12f33ecc1f57d0fe8d60b7fa7fc590f3 last firestorm viewer that was working good was v6.6.17.70368 and blender version 3.6.0. i still use that old version because all new versions have this glitch. right after that version, i could not upload my heads, the left side of the makeup layers is ruined. i have tried many new viewers firestorm and official viewers. they all do the same glitch. i have also updated blender, same problem, i also used mac and windows, all the same. i have reported this glitch before. this is the second time i report it. thanks alot

We are comparing rigged mesh export from Blender to Second Life via both .dae and .glb. We can export both formats so that they behave identically in SL, but only when deformation is limited to the standard m* bones. As soon as SL volume bones are also marked deform, the .glb result differs slightly from the .dae result after the mesh is worn on the avatar. The imported static meshes are identical. The difference appears only after wearing, when the SL rig actually deforms the mesh. A few details: -same source rig and mesh same visible export mesh in Blender before writing the file same result in SL when volume bones are not deforming mismatch appears only when volume bones participate note that volume bones have the known non-neutral/rest-scale oddities Does anyone know how SL’s .glb importer handles volume bones internally, especially their rest/bind transforms or scaling? We are trying to determine whether the difference comes from Blender glTF export, Avastar/Collada export assumptions, or SL’s handling of volume-bone skinning.

Rez or create object/prim. Apply a PBR material. Attempt to apply any texture without both copy and transfer permissions to Base Color, Normal, etc. This action is forbidden Switch to Blinn-Phong Same texture can now be applied without issues Why would this security feature be enabled for PBR but not Blinn-Phong? In what way IS this a security feature? The creator of an old set of boots kindly provided me copy/mod/no transfer versions of the normal maps for their boots. I applied a new PBR material of my own but wanted to add the original normal maps for additional detail. It would be a major security concern if creators had to give out copy/transfer versions of their textures to allow more involved modding and customization.

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.

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.