🪰 Viewer Bug Reports

I've become aware of a texture rendering issue that impacts textures when on a face. It's not so much an issue that only impacts PBR textures, but it is exponentially worse and makes certain designs as mastered in Substance unusable as PBR. I'm not enough of a rendering brain to understand what is going on here, but it's my belief this is not correct and is a bug. I hope that this will get in front of the right people to be evaluated and hopefully fixed. This is being demonstrated with a 0-25% gray bi-linear gradient, however anything that uses color and gradients near this will exhibit the same obvious defects. A single example using real-world art is included for reference. Texture UUIDs Dark gradient lossy: cac83520-08b2-500f-b683-1ede13d4e052 Dark gradient lossless: bd66f42c-6b56-780e-c183-3307151f8292 Raw files, non-anotated screenshots, and sample items shown are available upon request but I don't think they will be necessary. As I was sharing this around with creator friends moments before submitting this I was made aware this may be or have been a known bug, and can be alleviated entirely on the material side by setting the alpha mode selector to blended. Masked and opaque do still exhibit the shown issues. This made me frown. There is no alpha channel on the textures shown.

Sometimes when rezzing on a mesh object, not only does the item fail to rez, we get a false error message which states "The object failed to rez because the owner of the land does not permit..." etc etc. This gives the false impression it is a land setting issue, when in reality it is a rez-on-mesh problem. When the item is rezzed on bare ground or a standard prim, it rezzes first time every time, with no error message.

This should be easy to reproduce, just enter flycam mode (left button on the space navigator) while on a vehicle that is moving to another region, e.g. a boat. Observe, as the vehicle (and thus the avatar) crosses regions, the flycam jumps by 256m, presumably because the origin switches to the new region but the offset stays the same. What should happen is that the camera stays in the same location (modulo potential rounding errors), presumably someone just needs to add/subtract 256m from the relevant axis of the camera position on crossing depending on the direction of the crossing in the spot where the origin is moved to the new region.

Been testing this and its a SEVERE bug you need to handle. To reproduce 1 - Create a material. Put a ANY BAKED BOM TEXTURE (i.e. UPPER) on the BASE color slot. 2 - Create a box. Apply material to it. 3 - Pick up the box. Give it to other avatars. 4 - Avatars wear it. Result The attachment on AGENT A shows baked texture on AGENT B and vice versa. Keeps changing when zooming in and out, or if any of the agents rebakes his maps or reattaches anything. Found this happening on my avatars after updating them to BoM. But after a simple test the bug is super easy to reproduce.

I open a group notice by clicking the envelope icon, then a notice. There is an image attached to it. I click the image attachment and it does not open. I check my inventory and it is not there either. I have to go to the group popup, go to the notices tab, and click the image there, and then it opens. Years ago, this used to work correctly, and I remember it was supposed to be fixed, but i cannot get it to work. I tried this in both the LL viewer and Firestorm.

Try to rez a mesh object, or a mesh avatar. Takes ruddy ages during which time the item is totally invisible and gives no indication the rezzing is in process. Prim objects rez almost instantly and even if the textures aren't visible... the shape is.

This is a problem specific to the old system avatars like Ruth. The Facial Definition and Body Definition layers should apply white highlights. The Rosy Complexion and Lip Pinkness layers should apply red and pink colors to the face and lips. Instead, these layers are being rendered with their colors replaced with black. Steps to reproduce: Wear the Ruth avatar from the system library (Library/Clothing/More Outfits/Ruth) Crank up Facial Definition, Body Definition, Rosy Complexion, and Lip Pinkness on Ruth's skin Ruth's skin is shaded black in spots where highlights should be, and on her lips and cheeks Additional information: These layers use grayscale TGAs as a layer mask, which are being promoted internally to four-channel textures with black fill. When the layer colors are multiplied against black, the result is black. If you replace the grayscale TGAs with four-channel versions that have a white fill color, you'll be able to see the colors render correctly on your own avatar.

Upload a non SL Skeleton riged model via the uploader. (A model was sent to gltf@lindenlab.com ) .... then once in the world, click on the Animesh checkbox in the edit window. Watch as you mesh turns invisible... uncheck to see the mesh again. SEE included pictures. I expected the viewer to not allow me to upload the riged mesh as it had bones that where not named like the SL bones. however it did let me and it did show the mesh but when the animesh check box is checked then it goes invisible... and now I can not delete the mesh from the sim .... should have went to a sandbox.

Create PBR a material Set mode to "Mask" or "Opaque" Preview texture on any object you will see texture depth loss. Change mode to "blend", color depth issue will be resolved but alpha issues will occur so this is not a viable alternative, mask is required to fully resolve the issue. The above issue happens on every object I have tested it on and greatly impacts and limits creativity for all users wishing to use PBR. I've tried this with numerous textures and all have the same outcome, Will add more detail if needed but I think this covers it enough.

Blinn-Phong textures with alpha channels appear excessively transparent in the PBR client, with thinner alpha edges. Adjusting the exposure to the lowest setting or changing environment settings doesn't help. This issue affects many products, and the only solutions are to double the layer or make textures more opaque and have two versions of the same product included with the purchase. However, this causes inconsistency for users who don't use PBR, as they will see the items differently than PBR users.