Viewer Bug Reports

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

Blinn-Phong textures with alpha channels appear excessively transparent in the PBR client, with thinner alpha edges. Adjusting the exposure to the lowest setting or changing environment settings doesn't help. This issue affects many products, and the only solutions are to double the layer or make textures more opaque and have two versions of the same product included with the purchase. However, this causes inconsistency for users who don't use PBR, as they will see the items differently than PBR users.

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

* Details When chatting, received Japanese messages are sometimes garbled. Garbled messages will display correctly when you select the string. However, if the selection is deselected, the string reverts to a garbled state. If the chat window is closed and reopened, the garbled text will not display properly. Receiving other messages may cause garbled messages to appear normal. * Steps to Reproduce We do not know if this phenomenon occurs only in Japanese or in other languages as well. Also, the only known way to reproduce it is to keep chatting for a long time (more than about 30 minutes). This is only happening with ExtraFPS, not with viewers up to DeltaFPS. There seems to be a problem with the processing changed in ExtraFPS.

Create a reflective object, like a sphere with 1 metallic 0 roughness Look at it from some distance Zoom in really close It turns black based on the camera distance

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.

I have my viewer set to yield about 60ms to the host to keep the frame rate down while I am doing other things such as playing another game like The Elder Scrolls Online. It usually hovers around 10fps when inactive, compared to 40-75fps when active. With the DeltaFPS viewer, this lower frame rate in the background causes multiple textures to downrez, and will stay like that until the frame rate goes back up, causing the textures to load back in fully. This does not happen on the current stable release, and it is not a lack of VRAM because there is still 8-9GB free when this is happening in my test. Repro: Allow the viewer to load in everything fully first, more complex scenes are better Make the window become inactive, such as having the task manager over it Make sure the frame rate drops low enough as it yields resources to the host (10 in my testing) Wait a few moments, and you should start to see a good chunk of textures being brought down what looks like one notch of their full resolution Make the window active again so the frame rate goes back up to a high number such as 40-75 Watch as those textures start to rez fully again

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

The attached images demonstrate some rendering artifacts I have just encountered. One was taken with viewer version 7.1.10.10800445603 and one with ExtraFPS RC (7.1.11.11565212741). Both exhibit the same faults. The bells in the images are made of prims. The hollowed-out and profile-cut torus that forms the side wall is now divided into four circular bands with shading discontinuous between them. Viewing in wireframe confirms that these divisions correspond to the actual division into bands of triangles. I experimented with a few more types of prims (the white ones in the images), and several show the same thing. Notice that the surface forming the inside of the torus hole is smooth shaded, only the outside (the "hollow" face) has discontinuous shading. Cylinders also have this, but spheres do not. No earlier version of the viewer is available to compare, but I have never seen this before. I note that an older version of the Firestorm viewer (7.1.9.74745) is still able to login and does not have these faults, but the current one does (7.1.11.76496), suggesting that this is a recently introduced problem originating with the official viewer. There is also a shading anomaly that is common to all the viewers mentioned, and is shown by the Tube prim at the top left of the images. Here too there is a perceptible division into circular bands of the inner face of the outer cylindrical skin of the tube. Yet these bands meet with zero exterior angle. None of the other faces of the tube show this anomaly. As this is present in the older version of Firestorm, this looks like a different problem of older origin. No graphics settings or tweaks to texturing properties (shininess, normal map, switching to PBR, etc.) affected any of these observations. The images are screen shots. Viewer snapshots are the same.

Demonstration Video: https://youtu.be/eQ_YiWhfJWY It appears that projector priority seems to be using inverse the light radius to calculate shadow priority. Make 3 projector lights equidistant from each other pointing towards a centerpoint (for ease of seeing the shadows) Adjust the radius of the light furthest from your view larger and smaller and observe Adjust the radius of the light closest to your view larger and smaller and observe.