🪰 Viewer Bug Reports

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.

In the latest build, 7.1.12.13550888671 (64bit), enabling FXAA or SMAA divides the performance by 2 on my macbook Pro M2 (it used to have a negligible impact).

Login into SL Move around Quit by clicking the X button on top-right Wait ... and wait ... and wait ... for the shutting down box to disappear (See attached screenshot) _Sometimes_ Windows will even say "Application has stopped responding", but if you don't force close, SLV will, _eventually_ , close on its own. Just need to be ... patient ... patient ... patient ... Note : I've seen this behavior in 7.1.11 but it seems it's getting worse (with 7.1.11 Windows never complain about "Application has stopped responding", and the wait is not as long.)

Reflection probes trigger an update every time you cross a parcel connected even when both parcels are using the same EEP setting and same large probe, that is disrupting, it should not trigger an update if both parcels are using the same EEP within the same region, same owner. It's very common in regions like Bay City, Nautilus (not limited to it... ), where we cannot merge parcels, that was not problem before PBR, and reflection probes are quite slow to update ( 1 to 3 seconds ) noticeably "brightening" the scene while its updating. In my case I have several in Bay City, and 3 scenes share two or more parcels connected. Left an example here: http://maps.secondlife.com/secondlife/Bay%20City%20-%20Moloch/162/227/26 2 parcels, same owner, same region, same EEP... 1 probe, 1 scene... can be observed by walking the concrete walkway. That only happens with "Use Shared Environment", does not happen if you select Midday (the new one) on the viewer as a fixed environment.

Noticed the odd water reflection rendered behind my fishing line on the 7Seas rod. The texture does not include glow but is full bright. I noticed the full bright flexible prim did not show the same effect. I tested with another similar object and found an odd line where the water plane intersects it. The time of day is a bit different, and it seems to have more expected underwater distortions, aside from the weird line. I left my test object over here: http://maps.secondlife.com/secondlife/Livingtree/16/48/21 See attached pic, and thanks! :-)

The effect of this seems to be easiest to reproduce by having a larger inventory, mine is 155K+. For me it reproduces on two different computers, running either Firestorm or the SL Viewer. Log in, open an inventory window (Ctrl + I) Open Windows' Task Manager, monitor your RAM usage Open a bunch of extra inventory windows, a few at a time (5, 10, 15, 20) (Ctrl + Shift + I) See how RAM usage increase, and if you just let it be, the RAM usage continues to go up for some time... I don't know how common it is to have a bunch of inventory windows open at once, but it would seem to me that there might be room for optimization here, with all the windows not having unique data but are views into the same data I think that it shouldn't be duplicating the data in RAM for each window like it seems to do???

I do have a premium plus annual, We are supposed to have the mesh upload fees but I'm still charged.

The moon texture clips with skydome geometry, regardless of what the sky detail is set to in graphics preferences. If the sun is given the same texture, it does not clip. Steps to reproduce: 1) Inventory->new settings->new sky. Edit the new sky. 1b) optional: set cloud density and coverage to maximum to see it easier, but it is noticeable as long as there are any clouds at all. 2) Move the sun and moon to the same azimuth and nearby elevations, I used 270 azimuth and 33 elevation for testing. The effect is worse at higher elevations. 3) Set the sun and moon to the same texture, for instance "moon" from the library. 4) Set sun scale to 10, moon scale to minimum. Move the camera around while viewing the sun; it does not flicker. 5) Set the moon scale to 10, sun scale to minimum, do the above; the moon flickers and clips against the skydome geometry. Changing the sky detail level in preferences changes the granularity of the flicker, but doesn't avoid it. In the attached screenshot, top is the sun, bottom is the moon, moon has been set to 0 brightness. Elevations 45 and 30 respectively.

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.

Original issue: BUG-134040 Reproduction steps: Given: You have a working SOCKS5 proxy which is prepared to proxy Second Life traffic. Attempt to configure a SOCKS5 proxy via Preferences -> Setup -> Adjust proxy settings . Attempt to use Second Life Expected: The viewer is able to proxy UDP traffic through SOCKS5 Actual: Proxy does not work Note, this problem appears to be from a race condition when performing a handshake between the proxy and viewer. This may succeed on some machines and fail on others.