🪰 Viewer Bug Reports

PARTICLE RENDERING: Please fix the system default particle rendering. Specifically, the white dot default particle in version 6 (pre-PBR) is perfect, but now in version 7 it shows up as a white center with a visible square outline. An alpha issue I believe. This is the system particle which is called by default when no texture is added to the emitter. It is the basis for so many generic particle generators. So it would be great if LL could just tweak this little one for us please and smooth away the edges :) ! https://gyazo.com/97e97aeb4f68771c3c0c9791d444da9c

this is a sometimes bug, no idea how to reproduce. what we experienced is, that the LL viewer (not yet seen in Firestorm) sometimes shows PBR opaque which was set to BLEND and 0.0 alpha with overrides by script. I report that on behalf of my business partner who said he has no hope for this being solved by LL. so the computer details may vary..

I see my dot - so I am connecting  too the server or it's a false connection ? I see no sound waves for myself - other avatars are in the RED; they can not hear me and I can't hear them. Was told to wait for a region restart-  I did nothing changed. Was sent the Wiki on sl voice trouble shooting - even though it did not apply too me, its trouble shoots the Vivox  system .     BUT humor them anyway and went through each step 1. by 1. too no avail Things I have tried on my own and with help from Tech friends Both Firestorm Viewer , current and Beta  The Current SLV viewer  tried them all . White listed the recommend files  in Windows Defender installed a different Anti virus , no change  ( Avast - and the firestorm is white listed in there) reinstalled all viewers-  from scratch , deleted everything off my pc! ( a long shot)  did not work !  i didn't think it would :) Tried other accounts on my PC  same as my main . Tried 2 other pc's in the house and worked fine.  so its not blocked in my router/firewall was told it used Port 443? then is open , if that is the port its using and was blocked why would it work on other pcs? I restarted the router and unplugged it and restarted pc ... I have been to the testing regions but it doesn't work.   the old voice system does work just fine its just the WebRTC that is the problem I was thinking it was My Pc where the problem is - but having talked to support again this am.  seems too think it may not be? I  have sent my logs to support . Which is where I am at now. submitting this to form as requested by support

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

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

Bug copied from https://jira.secondlife.com/browse/BUG-234859 ---- What just happened? Using Second Life on Bellisseria as sun set. I had the Statistics bar up for PBR viewer testing. As the sun finally went down there was a visual change and a big drop in FPS, which did not recover afterwards. FPS while sun was still up was approx 85fps, with a frame of around 11ms. Immediately the sun finally set the FPS dropped to around 40FPs and the frame time jumped up to around 25ms. It stayed like that for some minutes. Looking at the statistics bar about 5 minutes later the FPS was round 70 FS and frame time around 15ms. What were you doing when it happened? Watching the sun set on Bellisseria with Statistics bar open. Using Release candidate 7.1.2.7215179142. What were you expecting to happen instead? Frame rate to stay similar in all sun/moon conditions. Other information A relog after 5 minutes or so appears to allow the FPS to go back to around 85fps (frame time 11ms or so) rather than the limited FPS it had settled on ahead of the relog. I had noticed during previous testing related to the NVidia GPU/8 core CPU systems on Firestorm and LL viewers that there could be a big an sudden change in FPS at times when sun was out and not. But the report as shown above was my clearest indication the frame rate drop was exactly as the sun finally left the sky and the sky turned a sudden deeper blue with no sun colour in it.

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].)

Using the latest SL Viewer, data usage seems about double from earlier versions - specifically the latest full release of FS v7.1.11 Visiting a single store and caming around for a short time (app 20 minutes) uses 2.63 GB according to Windows. Visiting the same store on FS (7.1.11) and caming around in similar fashion uses 1.37 GB of data. Both viewers are on MID-ish settings, no mirrors, some reflections, DD of around 64M. Yesterday I visited about 10 stores and used almost 10 GB of data. At this rate, I will start to run into data limit issues with my ISP pretty quickly on the new viewers (the issue also seems to affect FS recent beta versions)

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