🪰 Viewer Bug Reports

Rezzing of no-copy items need a change in logic / action.

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.

I have been working with a Firestorm dev on this issue, he has pretty much sorted out the repeats per meter not working at all, but... Now he has the ui working, there is a disconnect from the Blinn-phong in that with BP textures the repeats per meter uses the texture aspect ratio for repeating, as you would expect. The PBR repeats per meter is using the objects aspect ratio and changes the texture to match that and repeat. Not only is this for the majority of cases not the expected behaviour given most textures are 1:1 ratio and designed to be repeated AT that ratio, it is also a complete disconnect from the BP and PBR workflows where the same UI elements will produce different repeats.

This reproeduces to some extent in most locations but certain locations are particularly terrible for it. Teleport to http://maps.secondlife.com/secondlife/Syndicate/180/134/32 - there is a landing point so you need to walk to this location. Just stand at that location or cam around or walk around and observe the ligfhting in the scene. Observed Behaviour After a few minutes in that location, observe that the lighting in the scene starts to constantly change, certain random areas will change from lighter to darker every few seconds. Also observe that sometimes the lighting changes over the whole scene so quickly it's like the viewer scene is flashing. I'm not 100% sure but I think it's caused by the reflection probes reloading because the bug seems to reproduce the worst in areas with a lot of probes. Setting the "Max reflection probes" setting to None stops the bug reproducing. If the "Max Reflection Probes" setting is set to Low or above, the bug reproduces. The bug also reproduces on default release 7.1.12.13550888671 - ForeverFPS Videos showing the bug https://gyazo.com/9d2b870b0107d8deb619cebc7f2181ab https://gyazo.com/94eae3c6b3ffe47153a5af8d93546c5c https://gyazo.com/27154dd060f3c4a23a4937217eca6363 This bug looks very similar to https://github.com/secondlife/viewer/issues/3738

First noticed this with Firestorm 7.1.12 (77610), there is a relatively quiet, murmuring wind noise looping constantly as long as the avatar is hovering but not moving. Not as loud as the wind noise when flying, so it is a different sound which is not supposed to be playing at all while stationary. This sound is also attached to the camera and not the avatar, so when zooming or moving the camera around the sound keeps playing, coming from the camera position. Upon stopping flying, the sound stops instantly, it seems to be consistent with the avatar hovering in one spot. According to others this has already been present in Second Life Viewer 7.1.11. When I first tested it with Second Life Viewer 7.1.12 I couldn't hear this noise even though master and ambient volume settings were at maximum. Since others could hear it though I checked again and now I could hear the noise in this viewer as well, even though it wasn't as loud as in Firestorm. The expected behavior of the avatar flight wind noise is to only play when moving up, down, forward, back, left or right, when simply hovering no noise should occur. Steps to verify: 1: Stand still (no flying) - no wind noise 2: Fly up - after a brief wind noise that is supposed to be there while flying up, a quiet murmuring wind noise will loop constantly 3: Fly in any or all directions for a while - normal wind noise will play while moving 4: Stop moving - the quiet murmuring noise will keep looping again while hovering 5: Stop flying - the noise will stop immediately

I am not sure if this is the right place to post this so if it's not please somebody recommend a more specific form recently we had both of our regions converted over to web RTC. We did this understanding that this is the future and we might as well get used to it now and avoid the rush when the world converts. However there are a few things that I have noticed that are concerning. There are times when you're in world and ones voice can sound quite robotic almost like it's dropping packets. The temporary fix seems to be unclick your voice key scroll way out from the distance hit the escape key to return to normal view and then re toggle on your voice. I have no idea why this works but it seems to fix it temporarily. Web RTC also seems to use a very different calibration of voice levels whereas when you can hardly hear somebody their voice brackets are in bright red in in a regular SIM would be over modulated. I am not sure are these things that LL knows about or who to talk to regarding these concerns. The individual individual volume control for other specific users do not function. The Voice waves are not correct

On Mac laptops, when using the WASD keys for movement, using the A and D keys (to turn your avatar, etc) will cause a small character accent menu bubble to appear near chat menus or the cursor. This does happen in Firestorm as well, but does not happen on Mac desktops so I suspect some sort of keybinding conflict unique to an Apple laptop default. I can recall this going back a few years, on older Intel macbooks and persists on modern M4 MacBook Pros. This may be a repeat of another feedback post but thought I'd bump it with this posting.

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.

keywords_lsl_default.xml and keywords_lua_default.xml are missing some keywords from the relatively recent LSL additions, such as: NAK - https://wiki.secondlife.com/wiki/NAK Damage Types from https://wiki.secondlife.com/wiki/LlDamage And probably some more. Having this XML be up to date is useful for creating VS Code or other text editor extensions for syntax highlighting and similar.