🪰 Viewer Bug Reports

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.

Upon each startup of the viewer, I'm prompted to install (update) the viewer, with no opportunity to bypass this dialog. Upon clicking OK, I get a warning the viewer is already installed, and to repair it or cancel the procedure. If I click Repair, the install appears to go through normally, and once completed the viewer opens with the Release Notes popup, as normally happens after an update. However, the next time I start the viewer, I get the install prompt all over again.

Log in on a Velopack viewer. Go to Windows "Add / Remove Programs" Uninstall the Velopack viewer. Observed Behaviour You are able to uninstall the viewer while logged in on it The viewer instantly crashes Any settings changed that session are lost Expected Behaviour You should not be allowed to uninstall the viewer while it is running Velopack should check if another application with the same window class is running

On launch of viewer I get the attached screenshot which does not interfere with subsequent login or anything

I don't know how to install SL Viewer 26.1.1.23806384790 - 26.1.1 to a custom locations, using command line parameter. I am having trouble opening the 26.1.0.22641522367 version, after the notification about the newer version pops up. Please implement the option for custom location, before the installation starts.

Please leave your comments, criticisms, screenshots and reviews of the SLV "Visual Polish Viewer" project viewer here. The viewer may be downloaded below. Geenz update - March 6: New SLVP build is here: https://github.com/secondlife/viewer/releases/tag/Second_Life_Project%2314b74c9a-VisualPolishAlpha Some notes: Much faster SSR - if it slowed your machine down previously, it should be much faster now. Much smoother "glossy" SSR - should generally look much nicer on glossy surfaces and water New "Ultra" reflection quality - enables realtime reflections on water. Some things are still a little glitchy here, but should be generally closer to 6.6.17's "realtime" reflections Planar mirrors should now be much faster. Geenz update - Feb 26: New SLVP build is here: https://github.com/secondlife/viewer/releases/tag/Second_Life_Project%2374474388-VisualPolishAlpha Some goodies: Drastically reduced striations as you move the camera around Some VRAM wins with selective texture streaming. We now downrez textures more aggressively based upon what they're used for (diffuse, normal, emissive, specular, etc.) New EEP settings for tweaking post processing.

Unable to detach item (any item) after teleport. Cleared cache, re-installed viewer. This has NOT been fixed and it's affecting my shopping experience.

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.

This has been an issue that comes up for since at least version 7.1.9 where sometimes reflection probes will only render when the camera is inside of them then derender when the camera leave like it's getting culled. Most of the time I've run into it is from attaching probes to other items, take them then rerez then out but it wasnt always consist repro. Testing out the latest version 7.2.1 I've seen this is still an issue and now I've found a location where a probe doesnt appear to be attached to anything else and its just a normal inworld object and so far is consistent in repro this problem. Video showing issue. https://drive.google.com/file/d/1GE3ZVVpG86qGXx01u0gW0LnEg_wtMt7Y/view?usp=sharing The location is not my house but another users house so out of respect the location is in the Viewer Info section only. UPDATE: Did more testing and wiped out cache and settings. On High preset for graphics I am able to reliably repro this even in the LL roads at the new Ridgewood exclave sims at the car rez parcels. http://maps.secondlife.com/secondlife/Tequila%20Rosa/103/154/26 Rez a prim Set to reflection probe Notice will derender when camera leave probe. A few times I noticed setting max reflection probes to Ultra would cause probes to render as expected how ever as soon as I change the draw distance from 128 to 192 the same problem started happening again even when I reduced the draw distance back to the original value. In this area there is only about 2-3 reflection probes in a 1-2 region distance. Note that this issue has seen since before Max Reflection probe was implemented just not consistently repro.

The last Second Life Develop 26.1.0.23882237989 (64bit) have a Problem with loading the blocklist. The normal SLV showing the blocklist but in the Second Life Develop it is empty