Viewer Bug Reports

This problem started cropping up after the introduction of PBR. We have had many reports of this in Firestorm support, and it does repro on the official SL viewer. The problem generally involves letter/number displays that are scripted to change. Other parts of the object are not affected. Typically the scripted item will make its texture change, and the texture will rez, blur, rez, over and over, or simply remain in an unreadable, blurry state. Right clicking the item or putting it into edit mode will often cause the textures to completely rez. Once the item is deselected, it blurs again.

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.

A regular texture without normal or specular maps applied to face and set to "fullbright" is rendered pretty much oversaturated when using an EEP for PBR (Reflection Probe Ambience > 0). I remember this was fixed at some point (by Runitai) in the past, but its back. You can easily notice the difference by switching between the old Midday ( RPA = 0 ) and new Midday ( RPA > 0 ). The way its rendered with the old Midday is the expected/correct behavior for regular textures applied to faces with full bright (which was fixed in the past). I'm attaching 4 snapshots... One with Midday, Another with old midday. Snapshot saved to disk compared to rendering with full bright. Processed file after Photoshop compared to rendering with full bright. See example at http://maps.secondlife.com/secondlife/Taber/110/186/3102 . ( I switched all textures on vendors to full bright to show how much they are oversaturated when using any EEP with Reflection Probe Ambiance > 0, change your EEP to the regular old Midday, you can see how they supposed to be rendered ) This was probably after the code implementing that sharpening (which is useless btw, sometimes it seems to fight with anti-aliasing in sharp edges which may show jagged.... ) and fiddling again with tone mapper. I really thought the focus was to fix bugs and improve performance.

Reflection probes trigger an update every time you cross a parcel connected even when both parcels are using the same EEP setting and same large probe, that is disrupting, it should not trigger an update if both parcels are using the same EEP within the same region, same owner. It's very common in regions like Bay City, Nautilus (not limited to it... ), where we cannot merge parcels, that was not problem before PBR, and reflection probes are quite slow to update ( 1 to 3 seconds ) noticeably "brightening" the scene while its updating. In my case I have several in Bay City, and 3 scenes share two or more parcels connected. Left an example here: http://maps.secondlife.com/secondlife/Bay%20City%20-%20Moloch/162/227/26 2 parcels, same owner, same region, same EEP... 1 probe, 1 scene... can be observed by walking the concrete walkway. That only happens with "Use Shared Environment", does not happen if you select Midday (the new one) on the viewer as a fixed environment.

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.

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

Using SL on multiple monitors is a necessity for content creators. With content creation requiring Photoshop, Blender, and any number of other secondary applications to accomplish. Still, the desire to remain connected to friends and customers via SL remains, even while working. Placing SL on a second Monitor, and clicking on any other application will cause the application to start, what I can only call "crappifying" itself, with already fully downloaded textures being discarded for lower rez, worse quality blurry alternatives. This only seems to have become a real issue, recently. This can make working with SL as an 'inworld preview window" utilizing local textures to check one's work as they're going along, not just frustrating, but frequently impossible. Is there a setting where this behavior can be turned off, please?

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

Visit Darkheart Cafe http://maps.secondlife.com/secondlife/Cadborosaurus/68/26/48 on an intel Mac, be unable to function.