🪰 Viewer Bug Reports

When I zoom out far from my own avatar at a club or other texture-heavy areas, say to simply look around, when I return the camera to my own avatar a lot of the textures on my avatar - including materials - are lowered drastically in resolution and it takes the viewer upwards of 20-30 seconds before they go back to full. A resident's own avatar should never have the textures lowered in resolution unless it's specifically set in graphics > advanced, and should always take priority in staying at max quality according to graphics settings. Go to a club that is avatar heavy, so lots of textures are around - shopping events will probably work here too Wait for the viewer to load everything it can do - draw distance was 128 with textures at 2k maximum for this When your own avatar has loaded fully, alt+cam onto yourself and zoom out about half way to the clip plane - just looking around the area for a few seconds will work here too Return the camera to your avatar Lots of your avatar's textures, excluding BoM, are now super blurry, and will take ages to load back again Image 1 shows how my avatar is supposed to look > image 2 is how far I zoomed out (just across the room at this club) > image 3 shows how blurry my avatar's textures become after zooming back in, which stay like this for 20-30 seconds.

Two new notifications have invaded the SL viewer for reasons that baffle me as they are distracting, unnecessary, disruptive of work flow, and potentially privacy-busting. The notification that you have typed an invalid character now pops up in the precious upper-right hand corner of the screen usually reserved for far more important notifications such as payments and announcements from the region owners or Lindens. It does not appear as a hover or toast or message at the workspace itself while editing. You can already tell you have an invalid character as you look at the object window or other type of editing window you are working with because your work STOPS. You already know it is invalid because your prompt STOPPED. You don't need your eye dragged up to the upper right-hand space for an invasive, duplicatory message. The notification that you have taken a screenshot that saved to your computer's inventory folders now also invades the upper right-hand corner. You already know that you took a screenshot because...you set up the location of where screenshots go when you selected the settings in Preferences. You do not need a distracting constantly repeating notice of this event happening each time when...you selected this option permanently -- and could change that location at will. The notice displays to the owner of the browser only, but if you copy room chat to make transcripts of office meetings, other various community and public resident meetings, you will see the notice then included -- outing the name you have used to label your system folders on your own computer, which might even be your full real name -- that you have to painstakingly edit out. These are features no one among the general user base asked for to my knowledge. They have the feel of technologists' perfectionism in systems like CAPSLOCK notices which you already can see because you already have capital letters. The "invalid notifications" proposal was suggested here and simply immediately passed through without debate -- but does not have some mass community demand: https://github.com/secondlife/viewer/issues/961 (I will provide a screenshot of "invalid characters" when I can catch the next one) If these intrusive notifications cannot simply be removed, then provide the user with the option to mute them in Preferences. Currently they DO NOT APPEAR in Preferences as an option to mute.

The animation uploader currently allows animations to include additional Bento body bones that are not part of the supported body animation skeleton for standard human avatars, such as Spine1–Spine4. Because these bones are not reset by Second Life's default animation system, they remain in their last animated state after the animation ends. As a result, subsequent, perfectly valid animations can appear broken, even though the problem actually originates from a previous animation. This makes the issue extremely difficult to diagnose and causes creators of correct animations to receive support requests for problems they did not create. Because the animation uploader accepts these unsupported body animation bones without any warning, creators may not even realize they are exporting animation data that can affect subsequent animations. This is not just an issue for individual animations. Full-perm animation packs are widely reused by furniture creators throughout Second Life. A single incompatible animation pack can therefore affect a large number of products created by different people, while the resulting support requests are often directed at the wrong creator. Possible solutions Reject unsupported body animation bones during upload. Warn creators when unsupported body animation bones are detected during upload. Automatically reset unsupported body animation bones when an animation ends. Addressing this would significantly improve compatibility between animations from different creators.

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.

Using the Firestorm viewer 7.2.4 (80712) I created a New Skirt from the dropdown menu New Clothes. I wear the skirt, then when I go to edit the skirt, I immediately crash. I've tried the FS viewer and the SL viewer, and other people have not had an issue. What is causing my viewer to crash when I try to edit the skirt? I tried to upload the logs, but it says its too big.

It is possible for a vehicle to be in a state where it "settles" in a way that sends no more viewer updates. When that happens, the viewer will try to interpolate the last tiny omega value forever. To reproduce this, you need a vehicle that does not resend llSetMotorParams on a forever loop. (Some vehicles will spam a speed of 0 while stopped, which will make them slide in slopes and effectively prevents this bug from happening). The 777 2PM freebie from a previous shop n hop is one of the vehicles that can reproduce this bug. (I also have an old version of a vehicle Ive worked on that can suffer from this, if you want, I can provide a trimmed version for testing purposes) Then the repro steps is: Stop in a slope at an angle That's it! You will notice a stutter happen (this is the movement interpolation fighting the real state of the object), it corrects itself when the object refreshes, but sometimes it will forever interpolate until you right click or refresh in some other way: https://gyazo.com/3c3670b25577d23a168e74b4de890a09 Side note, to prove this is interpolation-related: altering the InterpolationPhaseOut setting affects that stutter, a value of 0s will guarantee you have a spinning moment, the default of 1s makes it stutter, having it at something like 0.001s completely kills the stutter and feels as it should, you dont get a bunch of micro stutters: https://gyazo.com/de896f5d97fa8eb2e249aa30385a0953 Multiple people on multiple viewer may see a different spinning state based on when they last got an object update. Ive had cases where I see it spinning and a friend doesn't, and vice-versa. This bug happens both on the LL viewer and Firestorm and Alchemy. Another case here: https://gyazo.com/a23fde28fb036c85bb5c066946261cd2 now 3 minutes later: https://gyazo.com/0bf78e44ad27ec2892de41ced7babb3e right clicking, or otherwise interacting with the vehicle in some ways makes it reset upright as you would expect: https://gyazo.com/2288c60146f75541bedf4c2a6f3e6801 From my troubleshooting with my own vehicles scripts & some viewer tinkering, the engine/scripts sees the car in its "true" orientation. I've managed to "fix" this quirk by forcing object updates in my lsl script. (Like by changing some invisible hovertext), but the real fix would be to adjust viewer interpolation for vehicles to prevent them from spinning endlessly.

Crashed. Rebooting PC and trying 3 different viewers did nothing. Cleared cache. Got back for a minute but touching objects did not work and crashed again

i needed to export my project, and noticed that since a week now some scripts simply refuse to export, it does not appear to effect all scripts however the more lines, the more likely a fail, there is no error either, not in the viewer or windows error logging, tried error tracing as well, the server doesn't appear t answer back with a file to save. attempted to reproduce with multiple viewers and 2 different pc's.

I present the same model (a small avatar accessory) with 2 different sets of LOD models. In each case the lowest LOD model has been 'zeroed out' to 18 tris as is typical in this use case. Triangle counts are as follows. * Model 1 - High 63040 (36k virts), Med 15760, Low 3940 * Model 2 - High 15760 (10k virts), Med 3940, Low 3940 Both of these models are visually indistinguishable in use. The DAE files prior to upload are sized as follows. * 63040 tris - 9.2mb * 15760 tris - 2.2mb * 3940 tris - 500kb Working on the dae sizes alone ... * Model 1 - 11.9mb * Model 2 - 4.9mb However .... * Model 1 - Download weight 0.7 * Model 2 - Download weight 3.1 When worn ARC is equally broken (as reported in firestorm) * Model 1 - ARC 319 * Model 2 - ARC 672 Objectively Model 2 is better for performance. Duplicating the mesh for 2 detail levels is punished to the point that using a sub division surface modifier to generate an insane 63k tris high model results in 'better consumer numbers' at intended object scale (it's also cheaper to upload). In addition to model duplication being unnecessarily punished, the scale component of Li accounting is fundamentally flawed and pushes creators into a situation where large items need to be low poly and tiny (often worn) items are best high poly! No wonder everyone's avatar is solid in wire-frame. This model is a small avatar accessory. Obviously the example mesh is over detailed, 'unoptimized' and created using techniques best suited to slow rendered content rather than real time. The point is why should anyone bother with 'low poly' when this gets the-job-done and is predictably rewarded.

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