🪰 Viewer Bug Reports

In the texture/material properties of an item, the scale, offsets and rotations are set in the edit window. However, when any PBR material is applied, it resets to the default values of 1.0x1.0, 0u/0v, 0 degrees, cancelling any previous settings. This makes it very tedious to switch between different PBR materials. This is a request to make the scale/offset/rotation of an item PERSIST after they are set in the edit window when a PBR material is switched, instead of defaulting to 1x1, etc. with the new material, as is the case when any blinn-phong texture maps are changed.

In Pony Play we have something called "Quick Jump" this is where you put a tick in the setting "Preferences > Move & View > Movement > Disable waiting for pre-jump and landing". As a ponygirl this is absolutely banned. However, I see the quick jump motion from time to time even though I don't have this option ticked. It usually happens if I'm doing a series of jumps in a row. This occasional missing of the prejump and landing animations can be seen in SL Viewer, FireStorm viewer Kokua viewer and Alchemy viewer. I see it least often when using the SL official viewer, however the fact that this occurrs in all viewers suggests it is a bug in the under lying code. Observations in the Pony community suggests that this has got much more worse since the PBR update. The time when it is seen is when you hold the jump key to do a series of jumps. This bug has also been reported in Firestorm: https://jira.firestormviewer.org/browse/FIRE-34049 Videos have been made of the motion: Not working as expected https://youtu.be/1r5fyyj847g Now working as expected https://youtu.be/5noQgxkKM7Q No change in preference were made during this test. Video recorded using Firestorm 7.1.9.74746 I repeat the same motion can be seeing using SL Viewer, Alchemy Viewer and Kokua Viewer.

"If the 2D don't work, the 3D don't work". I was at Sci Fi Con 17. All day long, no matter how many or how few avatars were on a region, textures took ruddy ages to load. Now one might say "There are so many textures at a big event it just takes a long time." But I'd walk into an enclosed room... where textures should be limited, yet the vendors on the wall just sat there and sat there and sat there. Textures RIGHT NEXT TO ME fail to load. One can stand there and stand there and stand there... and they still don't rez. I would click on a texture and tell it TEXTURE REFRESH... and it would ignore that instruction. I first reported texture issues and bottlenecks back in 2005. Now my computer and graphics card is hundreds of times more powerful... and textures still load at a snail pace. I will say the same thing I said back then: There is a texture bottleneck on SL. (Or, several texture bottlenecks, and it affects EVERYTHING.) With respect, I'm not asking for an explanation, nor excuses. I'm making a simple observation: After 22+ years online, Second Life should be able to very quickly load 2D textures in an enclosed room. Is this not correct? I suspect there will be people all too ready to give reasons why textures load slowly. To any and all such reasoning, I have one answer: Second Life needs to make textures load quickly. There's no argument, debate, discussion or excuse to that simple statement. Users need textures to load quickly enough that we don't get bored standing in a store (waiting for vendor textures to load)... and decide to go do something else. Like Netflix. ;D Because that's what it is: Second Life vs Netflix. Users have options on how to spend their time. When Netflix can stream entire videos realtime, surely Linden Lab should be able to send 2D textures across the Internet... yes? As a note: I'm not going to debate nor discuss or argue with those who are always ready to argue on these feedbacks. The feedback is posted, I've said what I came to say... and I have to believe the vast majority of SL users will agree with this: textures on SL need to load faster.

Noticed on a Firestorm 7.1.13 test version but the same thing happens on the latest SL Viewer release as well. When editing a day cycle and adding new key frames, apparently everything works correctly. After saving the day cycle, however, all the newly added key frames are lost. This is very inconvenient after spending quite some time adding new key frames and setting them up, only to have them vanish. Steps to reproduce: 1: Create a new day cycle or copy or edit an existing one 2: Add new key frames anywhere 3: Save the day cycle 4: Open it again 5: Newly added key frames won't be there

The current midday eep is GRAY.

Log in, many of not most of the objects on my mainland estate fail to rez, requiring me to continually clear cache and relog to have an acceptable virtual experience

As per https://wiki.secondlife.com/wiki/PBR_Materials#Unsupported_use-cases reflection probes are not supposed to work as attachments or on physics objects. > Wear a reflection probe. This intentionally does not work. Except, it does work - you just have to make the probe be a linked part, rather than a root object. This should be fixed so it doesn't become a feature due to people exploiting it.

After login or teleport, it often happens that some objects (usually large props like parts of buildings, landscaping stuff) are not displayed until I (accidently) rightclick on them. In older viewer-versions you could toggle wireframe off/on to force all objects to be shown and there are other tricks to 'unhide' those objects. That issue is well known for many years, for example, look here: https://community.secondlife.com/forums/topic/459592-problem-larger-mesh-props-remain-invisible/ and its a mystery to me why it gets no attention from the devs. Its extremely annoying, almost a showstopper for me. It just happens a lot to me, no matter what viewer I'm using (FS and LL), what PC I'm using and how fast my connection is. I'm not using any exotic hardware or settings. After almost every teleport I'm standing on invisible floors, bouncing against invisible walls and looking at party rezzed buildings.

I have many products that spin, and they are randomly stop spinning unless right clicking them. This is a very old issue, but i would like this to be solved. To say things clearly, they are set to spin by script, (using lltargetomega, but it's like the information that they are spinning doesn't reach the viewer .. randomly.. (as some of them will be spinning and some others not, and if i tp back that would be some other stoping spinning). And it would be spinning for some people, and not spinning for other present at the same moment.

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