🪰 Viewer Bug Reports

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

FIX EEP, Mainland environment cycle are way too dark, see my forum post https://community.secondlife.com/forums/topic/428374-environmental-enhancement-project-aka-eep-feedback-thread/page/41/#findComment-2861867

It is great to be able to have separate settings for sky, water, day cycles along with the option to load tracks while creating day cycles. The problem is that we are able to apply just sky or water settings to a parcel and region, and after teleporting, if a region/parcel is missing either water or sky, the viewer keeps whatever it had loaded before which is confusing, EEP's are already complicated in itself. Easy repro (Please see screenshots attached): Login to http://maps.secondlife.com/secondlife/Main%20Channel%20Sandbox%20A/178/234/23 Switch to Midday. TP to http://maps.secondlife.com/secondlife/LunaMare/249/171/23 Observe water normal. Switch to "Use Shared Environment." Switch to "Midday". (Normal stuck using the last EEP) TP back to http://maps.secondlife.com/secondlife/Main%20Channel%20Sandbox%20A/178/234/23 Same problem happens with the current "Midday" default setting on the viewer, that setting is a Sky only, and produces different results everywhere depending on the water setting you had rendered before. I sent 3 settings to Atlas Linden to make easier to replicate it: SL Midday (Sky only) SL Default Water (Water only) SL Midday (Day cycle with Sky and Water) This is confusing, an easy fix would be: 1) Viewers to always render a full set after a teleport or login (Sky "and" Water, "or" a Day Cycle), using default to complement anything missing. 2) Limit the use of Sky and Water to edit, or preview eep setting, or if "applied" to a parcel or region, a full set would be created using defaults for sky or water if missing. 3) Make sure all default eep settings on viewers have both Sky and Water, even if its just one track. This is probably what is happening with the other ticket: https://feedback.secondlife.com/bug-reports/p/water-normal-now-stuck-between-eeps-midday-vs-custom

Reflection Probes are not isolating me from the Environment like they used to. Tested in both newest SL and Firestorm Beta viewers. WENT TO THE BETA GRID (SLURL below) and a Probe I planted works fine in BOTH viewers! (I am not sure when this started; it has been a week or two since I tried this with a probe but I only discovered it today, [REDACTED 1].)

I believe the hover issue at log-in, recently solved, inadvertently changed how wearing system shoes affect the sitting height. This change makes all previously sitting z-axis adjustments (AVsitter) on countless furniture etc, completely useless ! I have a set of system shoes of varying heights, and I pick one that works for different mesh shoes. Think of it like a set of custom hover adjustments. This is desirable because system shoes gets saved with the outfit. As long as i have avatar hover at zero, all my outfits have a 'custom hover' for each of my mesh shoes. To test this, sit on something and wear system shoes, you'll see the z-axis heigh change (assuming the system shoes have suitable height saved) - take them off and the sitting height reverts. This change was inadvertent i believe, and should be rolled back/fixed.

Apply BOTH Blinn-Phong AND PBR materials to object* Set alpha to somewhere between 0 and 1 in blend mode Animate texture using llSetTextureAnim * This requires a custom texture and object to allow the animation to show alternating parts of the object (see link to example picture below) https://i.imgur.com/5RnPqnI.gif

ExtraFPS performance does not change when using menu Advanced -> Set Window Size to a lower resolution. Older versions 7.1.8 and 6.6.17 do. Attached 4 screenshots showing the behavior on 7.1.8 and 7.1.11. This only happens when we start noticing the bug described @ https://feedback.secondlife.com/bug-reports/p/deltafps-extrafps-viewer-slowdown-coming-back-to-focus . ( Maybe this ticket should be attached to the other one, I have no idea if they are related) In fact, another interesting observation.... when we notice that bug... the viewer when out of focus, FPS goes down to 17, 18 fps instead of the usual 22 fps. There is something holding back ExtraFPS within the rendering engine, being just weird when it comes to performance, the viewer has a will of its own (ExtraFPS gets "pissed off" too easy! Needs some coaching! heheheh ). Along with the "bug" described @ https://feedback.secondlife.com/bug-reports/p/deltafps-extrafps-viewer-slowdown-coming-back-to-focus it seems to be worst on ExtraFPS with long sessions... that same 100 fps shown in the screenshots, after a 10/15 minute session with normal use, comes down to 65 at that same location, same rendering (landing point), its worst when coming from a login from 6.6.17 with the official viewers if you dont clear cache between sessions. ( I have no idea how it affects Firestorm, but I assume its relevant, since a lot of people is trying the new PBR viewer ). This contributes to that "bad" taste using the PBR viewer when it comes to performance, even on a machine that in theory supposed to push it really well, I assume it is much worse on low end machine, even though is harder to compare or notice (100 to 65 vs 35 to 25)... [EDIT: Added 2 snapshots showing that bug related (hijacked my own post), one with viewer "upset" showing the related bug above, another with the viewer in a good mood! @ http://maps.secondlife.com/secondlife/Lost%20Unicorn%20Gallery/125/111/22 , which is a very detailed region showcased at the destination guide, 6.6.17 shows 45 fps for that same region, same machine... basically that is what we are asking other users... switch to PBR, your fps can go from 45 fps at a region that you like down up to 19 depending on the viewer mood at the time! Not going to happen!] PS.: Its really easy to like the final rendering for PBR content and all the effects (I do), but even easier to hate performance compared to the old engine, which was not as fancy, not even close... but still very enjoyable.

For personal reasons (i wanted a audio/video stream where all are in a real sync) i have setup a server for can stream in SL webM videos (as explained at https://slmusiclab.wordpress.com/2024/04/24/vjing-live-and-in-sync-in-second-life/ . The system work well, all can see and listen the stream with pre v.7 viewer, but viewer 7 don't show the video. Connection with video source is made with a simple URL, nothing strange or difficult. What expected: same behavior on all viewers What happen: V. 7 viewers don't show the video. They make connection with server but screen remain black (i tried LL viewer, Firestorm and Alchemy). BUT If i apply the media URL to the dedicated face of a MOAP with v. 7 viewer, then also the v.7 viewer work.