Viewer Bug Reports

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

When editing texture repeats, etc., pre-PBR, the surface showed each repetition of the texture map outlined (with a crosshair in the middle) rotated and sized according to the current settings for that map. In PBR that outline now seems to be static and correspond to the extent of the entire UV map on the object itself (or something? it's missing altogether when adjusting the Emissive or Normal maps' transforms). Is there some reason we shouldn't have the old, useful behavior?

Edit mesh - go to Blinn-Phong texturing and tint the color. The face that is being edited will turn white or nearly white till the mesh gets out of Edit Mode. Precise tinting is difficult as it's impossible to see the changes while working. SL Prims works fine, it's only mesh editing as far as I can see. Tested at Default lighting settings.

We are facing a texturing issue when needing to change a PBR face from alpha to opaque. Currently when we do this in world by editing the mesh object ... editing the texture, changing from alpha to opaque and saving, it seems to save but the next time we log in, it has reverted back to alpha. The current fix we have found to work is to edit the material while it is in inventory and then to apply it. Can this be investigated so that when editing the mesh object face itself, that the changes will hold. Thank you. Please reach out if this is not clear.

Rez a prim, change to sculpted, use the "plate" sculpt map from the library and the prim disappears. Friends on firestorm can see it, I cannot. I can take it to inventory if I"m lucky usually I cannot. I must relog to see the sculpt. I teach building classes so to avoid this downfall, I give them the sculpt. Sometimes it appears, sometimes it does not. Students have to relog to see what they are building. This happens on any sim, any time of day. I have more trouble with the plate sculpt than sculpts I make, but really either way it makes sculpts nearly impossible.

I'm on DeltaFPS on a Mac running Sonoma. Every time I go to save a texture from my inventory to my computer, if offers to save it inside there Second Life viewer app bundle, in Contents > Resources. It will not remember last location. This is saving it in the application bundle, which seems like it could cause issues with the viewer, and makes it very hard to get to. Surely this was an error when the app was being built?

I have not tried this on the SL viewer, and if asked to I will certainly do so, but with the current release of Firestorm I have found that the root object assignment upon uploading a DAE file with multiple objects the resulting linkset inworld will be random, where I would expect it to be either the last or the first object listed in the DAE file, preferably the first one since in Blender that's the "Active" object. My testing as follows: Select to upload a DAE file that contains multiple objects, in my case where the object "Cube.nnnn" is the first listed one. Set LOD settings and pick one of the LODs to serve as Physics too. Complete the upload, and rez the object. Find out the root of the linkset. Repeat the steps a bunch of times with the same DAE file. Whenever the cube is not the root, the object that becomes the root gets the name of the cube, losing its actual object name. The cube itself keeps its name, resulting in two objects in the linkset with the same name. Attached is an image showing three of my attempts (out of maybe ten uploads of the same DAE). So, why is this important? Well, my case is that I am building a full region terrain with my wife, which requires splitting the mesh up into 64x64x64 chunks (or less). It also requires fitting them together exactly inworld. We found that the way to do this properly, we'd enclose the component meshes in 64x64x64 cubes, which can easily be aligned to each other, and in relation to the region of 256x256, a total of 32 cubes for one layer covering the whole region, it's easy to place them on the grid by way of calculated offsets. We can also automate the placement of the cubes using scripts, by having the script look at the name of the root object and then move the cube to a predetermined position based on that name. None of this works however, if the cube isn't the root object. It's easy to change it to be the root object, if one has one or two linksets, but dealing with a multitude of them it's quite a lot of extra work, especially during testing (on the beta grid). If it's needed for testing, I'd gladly send the DAE file, and I can send the already uploaded cubes (displayed in the attached screenshot), they are on the beta grid not on the main grid. Thank you!

Rez a prim Set material to PBR Metallic Click Texture Picker and set material to Blank Edit Selected material and Base Color, ORM or anything else Attempt to remove material using Texture Picker and Selecting None Any edits are removed, but the Blank material remains on the object If you select a saved material from Texture Picker, the material can be removed by using Texture Picker and Selecting None. This is the expected behavior.

Now, I'm making a presumption here that sounds, like other assets, should be checking for existing duplicates based on some kind of hashing and not create copies, much like it works for textures. The encoding used in sound upload is nondeterministic and prevents this: it uses a random value for the Vorbis stream serial number, which results in binary differences as the metadata is different even if the audio data itself may not be. Steps to reproduce: Prepare any SL-acceptable .wav file for upload. Upload the same file to Second Life twice. Copy and write down the asset UUID for the first file, then the second. Confirm they do not match. Browse to temp files directory and guesstimate which files are the .ogg files based on size and date. Rename the .tmp to .ogg to test audio playback. Perform a binary file compare: there will be a couple mismatches, often the same byte patterns, suggesting the metadata is the only thing that has changed. Curtailed results from Windows FC: fc /b 3b53c3a9-c301-b9d3-9318-47383d0b2488.ogg 79705d70-6488-60bc-5c6c-03e5882598f0.ogg Comparing files 3b53c3a9-c301-b9d3-9318-47383d0b2488.ogg and 79705D70-6488-60BC-5C6C-03E5882598F0.OGG 0000000E: E3 97 0000000F: 4F 6D ... 00000DDC: E3 97 00000DDD: 4F 6D ... 00002F38: E3 97 00002F39: 4F 6D ... The code in question is in llaudio\llvorbisencode.cpp, encode_vorbis_file() function: ogg_stream_init(&os, ll_rand());. Maybe it should be computing a hash of the .wav file to use as a serial instead, if asset duplication is not intentional for sounds.

Create some PBR content in one viewer (say the Linden viewer) Adjust some Materials properties (scales, offsets, metallic-roughness maps) of that content using another viewer with a different cache (I used Firestorm's PBR beta but could have been a Linden viewer using a different cache location), then go do other stuff at a different location and eventually logout for a few hours Switch back to the creating viewer, fly and teleport around, edit other stuff for hours, then return to the content created in Step 1. Behold that all the changes made in Step 2 have reverted, including in the editor. Logout and switch back to the viewer used to make the Step 2 changes, noting they're restored. Clear cache in the original viewer, login, and find the changes restored in this viewer, too. If this is expected behavior, it surely wasn't expected by me! Knowing nothing about how the viewer cache is actually implemented, I'd naively hypothesize that something about how PBR Material override properties are stored on the region or in cache make them invisible when determining whether cached instances are valid.