Viewer Bug Reports

I've been experiencing an issue across a few of my creations, but this one in particular seems to be the worst. (I say this because I'm mostly a platform and store hermit, so I’ve only encountered this issue on my own parcel and once during a content creator group meeting, where my clothing had the same problem.) The issue occurs at random. Yesterday, I reached out to the community on Facebook and Discord, and it seems others are experiencing the same thing. Someone suggested clearing the cache, which did help temporarily. However, when I returned to take some screenshots, the issue reappeared. The problem happens on both Firestorm and Alchemy viewers. Sometimes it resolves itself, but when the main face becomes completely distorted, the only solution seems to be relogging. When the issue is minor - such as a slight blur on the "metal" material - it usually corrects itself. However, when the main area is affected, it doesn't recover on its own. I don’t believe this is an issue with the mesh itself, as I haven’t received any feedback from customers regarding similar problems. That said, I can’t be entirely sure. For reference, the main area affected has 2,755 vertices. I’m attaching screenshots to show how the item should look versus the slight blur on the metal material and the main issue occurring on the primary material. This has been a persistent and frustrating problem, and it seems to be getting worse lately. I’m unsure what steps I can take on my end to mitigate it. If anyone has insights or suggestions, I’d greatly appreciate the feedback! Thank you ♥

Reproduces on the develop branch and on ExtraFPS on Linux and Windows. I have been able to repro fairly consistently by starting at (wait until all textures have loaded): http://maps.secondlife.com/secondlife/May%20Queen/141/50/53 , teleport to http://maps.secondlife.com/secondlife/Nutmeg%20Mainstore/68/123/21 OR https://maps.secondlife.com/secondlife/Anthem/134/129/1107(again, wait until all textures have loaded), and then teleport back to the starting location http://maps.secondlife.com/secondlife/May%20Queen/141/50/53 . Notice that although the memory pressure has been relieved, and the viewer seems recognize as such (Est. Free in texture console) , the bias value does not drop (or, does not drop in a reasonable timeframe, as in this particular test the bias value did eventually drop over the course of about 10 minutes back to 1.0) to allow the viewer to use more VRAM. I am also not the only user to experience this issue, others have also encountered this issue - see this discussion from the Second Life Discord server - https://discord.com/channels/677442248157167619/681998835458768900/1313874733275807765

Graphics preferences at default for WIndows 11/GTX1080 except draw distance at 128m, no limit on avatar complexity, maximum object detail. Go to http://maps.secondlife.com/secondlife/Nautilus%20-%20Elissa/145/36/26 and face the canal gates (see picture). Turn on the texture dashboard with Shift-Ctrl-3 Observe that the bias remains in the range 1.9 to 2.0. It will slowly decrease then something pushes it back over 2.0 again. The grey wall texture on the building to the right should be a PBR brick wall. There were 7 agents on the sim, zero adjacent, none in the field of view. It's notable that the texture console never settles down having fetched everything it needs - it's continuously fetching textures rather than getting in control of the scene.

Go into debug settings, set RenderResolutionDivisor to any value. Nothing happens until you relog. Once you've relogged, the effect will start and you're able to change it as long as you don't set it to 1, at which point it stops working again. When the effect is active, it no longer just pixelates the screen, but it seems to mess up the camera by rendering only a corner of the scene. To test, set the value to 4, relog, and lower the value one by one. The pictures are roughly the same camera placement with RenderResolutionDivisor at 2 and 1. When set to 2, it seems to only render a corner of the screen. Prior to PBR, the feature would only lower your resolution.

Go to adjacent sim and walk on. The region textures will turn white

The viewer tends to crash, mostly after a moment when the app is on the background. It seems related to llvertexbuffer The same is happening on multiple Mac configurations Here is a partial crash log: Thread 0 Crashed:: Dispatch queue: OpenGLMT 0 <translation info unavailable> 0x10c14f978 ??? 1 libsystem_platform.dylib 0x7ff80361beb3 _sigtramp + 51 2 AppleMetalOpenGLRenderer 0x123ec49b3 GLDContextRec::testFence(GLDFenceRec*, int) + 27 3 GLEngine 0x7ffa21b5c76e gleTestSync + 149 4 GLEngine 0x7ffa21acd471 glWaitSync_ListExec + 22 5 GLEngine 0x7ffa21b4e80a gleCmdProcessor + 80 6 libdispatch.dylib 0x7ff80343f7e2 _dispatch_client_callout + 8 7 libdispatch.dylib 0x7ff80344c8f2 _dispatch_lane_barrier_sync_invoke_and_complete + 60 8 GLEngine 0x7ffa21abd580 glDeleteBuffers_ExecThread + 25 9 Second Life Release 0x103ef5e08 delete_buffers(int, unsigned int*) + 392 10 Second Life Release 0x103efbec6 LLAppleVBOPool::free(unsigned int, unsigned int, unsigned int, unsigned char*) + 54 11 Second Life Release 0x103ef5040 LLVertexBuffer::~LLVertexBuffer() + 176 12 Second Life Release 0x103ef570e LLVertexBuffer::~LLVertexBuffer() + 14 13 Second Life Release 0x1028ba2cf LLPointer<LLVertexBuffer>::unref() + 79 14 Second Life Release 0x103ea8bbd LLFontVertexBuffer::reset() + 77 15 Second Life Release 0x103f2738d LLComboBox::setCurrentByIndex(int) + 221 16 Second Life Release 0x103f266bc LLComboBox::add(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, EAddPosition, bool) + 236 17 Second Life Release 0x102f68c91 LLFloaterTools::updatePopup(LLCoord<LL_COORD_TYPE_GL>, unsigned int) + 1281 18 Second Life Release 0x103a18673 LLViewerWindow::updateLayout() + 307 19 Second Life Release 0x103a15cac LLViewerWindow::updateUI() + 11532 20 Second Life Release 0x102a1d5a9 LLAppViewer::idle() + 1561 21 Second Life Release 0x102a1b89e LLAppViewer::doFrame() + 1918 22 Second Life Release 0x102a1acc7 LLAppViewer::frame() + 55 23 Second Life Release 0x1029c5fcf -[LLAppDelegate oneFrame] + 15

Objects with an animated pbr textures stop animating the texture when we look elsewhere and back to the object. A right click on the object triggers the animation again. (a bit like the object not spinning as they should, a right click does the trick) Happens on mac and pc This doesn't happen if the material is not pbr.

Using PBR materials with Glow and Emissive is causing an incorrect alpha sorting behaviour. this behaviour is new as of 7.1.10 and did not exist before (see 7.1.9). This effectively breaks all PBR items using 'Glow' and 'Alpha' rez a cube, set it to 50% transparent, (or any existing alpha object) rez another cube apply a PBR material set alpha mode to 'Blend' set alpha to 0.00. assign blank emissive set emissive to white set glow to any value higher than 0.

The new Release Candidate is defaulted to Khronos for tone mapping. Content created in the last 12 months using ACES tone mapping is excessively impacted as a hard break of the tone mapping changes, particularly EEP settings created for both Firestorm, and LL Viewers. Values are blown out on the higher end of ranges making non greyscale colours not compatible with existing content on EEPs and dampening at an excessive level when colour introduced to sun, clouds etc. Can we default the Release Candidate back to ACES under advanced settings, so users can gradually update their own defaults to Khronos over a period of months. This soft break to content will allow creators to adjust new content and have a soft alignment of old content into the new tone mapping. Examples of screenshots showing the impacts can be found on thread - > https://community.secondlife.com/forums/topic/517003-khronos-tone-mapper

Just some observations about PBR: It is killing many of of our lower resource friends because their hardware cannot run it. It breaks many EEP settings we like. eg. I am at SLB21 event and my normal Nam's EEP flashes from dark to light. No control over some annoying local lighting except by trying to find source to derender. This stuff is pretty if you have hardware to run it but those that do not will be lost and I am afraid that will be many residents. I hope there will be an alternative for our many lower hardware resource friends.