Viewer Bug Reports

• Use concise, precise descriptions
• Do not include sensitive information.
• Create a support ticket at https://support.secondlife.com for individual account issues or sensitive information.
PBR Viewers Flickering Black
Viewers Tested: Alchemy Beta 7.1.9.2501 (64bit) Second Life Release 7.1.10.10800445603 (64bit) Firestorm 7.1.11 (76720) Nov 9 2024 02:03:12 (64bit / AVX2) All 3 of these viewers all exhibit the same issue where, if anything even a little graphically intensive starts to occur (busy sims, a second viewer is opened, this sort of thing), the viewers quickly start to flicker black across the entire viewers window, minus the windows surround and titlebar. I am currently using Firestorm 6.6.17 (70368) Dec 10 2023 18:36:33 (64bit / SSE2) as it is the latest pre-PBR viewer as my daily driver because it and any other pre-PBR viewers I try do not exhibit this issue. I don't exhibit any issues with other programs/games that I've been able to determine and you can see from the specs below I should have no problem with the requirements for PBR viewers. This issue seems to be exclusively the domain of the PBR renderer for SL as it is viewer agnostic. I have completely re-installed Windows twice both on Windows 11 23H2 and 24H2 updates, I have run memtest86 for hours with zero errors and I have borrowed my partners GPU and PSU all to no effect. I have taken videos of the issues in each browser and obtained the logs for each, however I'm unable to upload them to the ticket as the videos are too big and the logs are zipped up and that filetype is apparently unsupported so I've put them in my onedrive and attached the links below, if you'd like be to upload them elsewhere, just say where and I'll re-upload them. SL Logs: https://1drv.ms/u/s!Argy6Q-UWl9BpqdxVEIqu2sud0QkFA?e=FnChfU SL Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdubODgMVIK4RqS4w?e=hemGAv Firestorm Logs: https://1drv.ms/u/s!Argy6Q-UWl9Bpqdw0-q0kaa1AuAdvw?e=IrV7OQ Firestorm Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdsUNzCSdoVTKEh6w?e=mJDdli Alchemy Logs: https://1drv.ms/u/s!Argy6Q-UWl9BpqdvQa589QIX9y9NIw?e=a0xGcG Alchemy Video: https://1drv.ms/v/s!Argy6Q-UWl9BpqdtJcjY_gITIV70ow?e=lpmwn3
8
·

under review

[ExtraFPS] Performance does not scale with resized window
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.
3
·

needs info

[DeltaFPS, ExtraFPS] Viewer slowdown coming back to focus
While trying to understand why Featurettes compared to current releases felt like a more "smoother" experience, even after all the "improvements", I found the following: - Performance goes down by a lot after the viewer comes back into focus, while switching between applications , even after waiting a minute or so until the textures are "resized/rendered", not only in FPS count, but stutters... really noticeable comparing to a after login experience, I never noticed that with older builds... and keeps getting worst overtime in long sessions... its not memory, since this machine has a 64gb DDR4 @3200 and videocard with 16gb VRAM. This only happens on a PBR scene (several PBR objects + PBR EEP + reflection probes ). Steps to reproduce: Login with DeltaFPS, wait about a minute or so, cam around a bit... take a reading. Switch to another application (Youtube, Substance, etc), use it for a few minutes, while SL still logged in, in the background. Switch back to the viewer, wait for a minute or so until all textures are "full rez" again, or until FPS stabilizes. Cam around, take a reading, which should show a much decreased performance, also compare how it feels rotating the avatar, stutter, etc... This simply does not happen if you are on a "legacy" only scene (Legacy materials, Legacy EEP with Reflection Probe Ambiance set to zero )... performance is pretty much the same after switching and using different applications. I'm attaching a few screenshots with such readings which I can reproduce easily, it gets worse overtime with longer sessions, with the lowest I've experienced going down to about 50fps, really "stuttery" rendering, those are just examples, while writing/editing this, and switching back to the viewer, ExtraFPS is at 60 fps... On another note: ExtraFPS is probably right there as one of the worst RC releases when it comes to its state, is more like a "preview" released for a specific small group to test: EEP controls (Editor, Personal Lighting), simply does not work correctly, its broken, no "realtime" effects to see results, does not position the sun (also visible on the snapshots below), etc, there is no way to know if something was saved or not. Due to the current implementation of a "new" tonemapper, colors are completely off, oversaturated in PBR scenes. Probably forgot to "tonemap" the EEP too. Full bright textures are now completely overblow, its really hard on the eyes to play for a while looking at that rendering. Is the "fix" for too dark, to be oversaturated? Seems like you are trying to fix bad EEP settings with a different tonemapper, mistake over another mistake. Colors on the color picker simply don't match, they are different (maybe forgot to "tonemap" the color picker too?). Why the default documentation and tutorials for authoring tools with recommend settings that dont match the new "default" tonemapper. What is the solution for whoever already created several PBR items to make it display as intended with this new "default tonemapper"? Change all over again? Tell customers, "switch your tonemapper"? Usually that kind of "stuff" is really implemented in third party viewers, which is great, specially if they serve a specific purpose (Black Dragon as an example for photographers, etc... ), not the "official viewer"... one of the great benefits was conformity between authoring objects and publish in-world (From Substance as an example, to display/sale in-world), easily reproducible steps, what you see there, is what you get here using default/recommended settings. Is that gone? Are we going back to mess?
7
·

tracked

Li/ARC accounting systemically rewards insane poly counts
I present the same model (a small avatar accessory) with 2 different sets of LOD models. In each case the lowest LOD model has been 'zeroed out' to 18 tris as is typical in this use case. Triangle counts are as follows. * Model 1 - High 63040 (36k virts), Med 15760, Low 3940 * Model 2 - High 15760 (10k virts), Med 3940, Low 3940 Both of these models are visually indistinguishable in use. The DAE files prior to upload are sized as follows. * 63040 tris - 9.2mb * 15760 tris - 2.2mb * 3940 tris - 500kb Working on the dae sizes alone ... * Model 1 - 11.9mb * Model 2 - 4.9mb However .... * Model 1 - Download weight 0.7 * Model 2 - Download weight 3.1 When worn ARC is equally broken (as reported in firestorm) * Model 1 - ARC 319 * Model 2 - ARC 672 Objectively Model 2 is better for performance. Duplicating the mesh for 2 detail levels is punished to the point that using a sub division surface modifier to generate an insane 63k tris high model results in 'better consumer numbers' at intended object scale (it's also cheaper to upload). In addition to model duplication being unnecessarily punished, the scale component of Li accounting is fundamentally flawed and pushes creators into a situation where large items need to be low poly and tiny (often worn) items are best high poly! No wonder everyone's avatar is solid in wire-frame. This model is a small avatar accessory. Obviously the example mesh is over detailed, 'unoptimized' and created using techniques best suited to slow rendered content rather than real time. The point is why should anyone bother with 'low poly' when this gets the-job-done and is predictably rewarded.
4
·

tracked

Load More