Viewer Bug Reports

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.

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.

Nametags of underwater avis, as viewed above water, seem to be floating on top of the water, even if the avatars are deep below. Looking below water they snap back to normal.

My avatar will not rez in and is just staying an orange cheeto cloud. I have cleared my cache, switched groups, switched outfits, restarted SL, restarted my laptop, restarted my phone which I have used for my hotspot long before this became an issue, uninstalled and reinstalled Firestorm, and cleared my web browser history. This is sudden and I don't know what the problem is. I can log into other accounts and the avatar loads just fine, but for whatever reason, this one, which is my main suddenly will not rez in and I have closed and reopened Firestorm multiple times waiting hours in between.

Whatever I do the viewer crashes while Initializing Texture Cache. I have upgraded to the latest version, I have uninstalled and removed registry keys. I have installed into a different folder. I have done clean installs, and over the top installs. Nothing works. The few times I did get in-world before upgrading to the new viewer I got 5 frames per second on LOW settings with most of the textures missing and those that did appear were constantly switching between blurred and in focus and then back to blurred again, while I was standing still. I can't even install an old viewer to avoid this mess because the links to the older viewers are gone. The links take you in circles without showing a list of older viewers. Did Meta pay someone at LL to drive all the customers away? For god sake roll it back while you still have residents left!

Ten months ago I filed a support ticket after receiving complaints about textures not properly rendering on mesh models. Customer support told me there was supposedly a Jira ticket about this and it would be fixed. We are ten months later now. I am still getting the same complaint how people their plants and trees textures are not properly displaying. It appears to me that the region or this particular RC server is setting the textures randomly from alpha blending to emissive mask. This happens on a RC region. Second Life RC Ferrari 2024-03-18.8333615376 The issue has been documented and described in detail here https://community.secondlife.com/forums/topic/510476-texture-related-issues-still-taking-place-after-10-months/ Region where this particular bug is active: http://maps.secondlife.com/secondlife/Dreamworld%20Duck/122/209/22 Reported to Second Life Concierge support. Concierge placed region on regular Second Life server code. Issue did repeat. *Keep in mind this is not the only region where this takes place. I see it happening from time to time on full regions as well. Other people also confirm the issue and timeframe this bug has been active in the system, some claim it to be more than a year. In the past manually correcting the textures on the affected object would permanently solve the issue but recently the simulator just randomly switches some of the textures on the region back to emissive mask.

As the title says, the texture memory calculation currently is a big, inconsistent mess: LLViewerTexture::isMemoryForTextureLow() and LLViewerTexture::getGPUMemoryForTextures(): Former was used in LLViewerTexture::updateClass() for a more aggressive memory reduction if "texture memory" got low before the PBR release. Now it is only used in the Lag-Meter floater. Latter function is only used in LLViewerTexture::isMemoryForTextureLow(). LLViewerTexture::getGPUMemoryForTextures() itself uses LLWindow::getAvailableVRAMMegabytes() to determine the amount of available memory of the GPU. LLWindow::getAvailableVRAMMegabytes(): This method is platform dependent. In short, this is only more or less correct on Windows, while on macOS it's basically a wild guess. Wild is actually a good description of what is going on for either platform. Let's talk about Windows first: The total amount of VRAM on the GPU is queried via DirectX - and might just override what was initially detected by querying WMI. This query also returns the amount of memory used. If this amout is not returned for some reason, it is estimated as: LLImageGL::getTextureBytesAllocated() * 2 / 1024 / 1024. Remember this - it will be important later. Now there is some reserve of the total VRAM calculated that should be available to other processes. This is 2GB if the total VRAM of the GPU is more than 4GB, and half of the VRAM in any other case - remember this as well. The total available VRAM is now calculated as: total VRAM - reserve - VRAM used. Now let's switch to macOS: On macOS, the available VRAM is only estimated, based on the total VRAM and the VRAM already used. Former is calculated - as already seen for Windows - as: LLImageGL::getTextureBytesAllocated() * 2 / 1024 / 1024. Apparently a reserve is not necessary on macOS and the available RAM is calculated as: total VRAM - VRAM used Since we have now more or less scientifically determined how much VRAM currently is still available, we would assume the result of LLWindow::getAvailableVRAMMegabytes() is used in the texture pipeline to determine the discard level of the textures the viewer is displaying, correct? WRONG! Apart from initially mentioned in LLViewerTexture::getGPUMemoryForTextures(), LLWindow::getAvailableVRAMMegabytes() is only used in one other location: The texture console for information purposes. But what else is used in the texture pipeline to determine the discard level of textures? Well, this brings us to: LLViewerTexture::updateClass(): Here, we see some more magic happen: First, the total amount of used VRAM by the viewer is calculated/estimated as the sum of LLImageGL::getTextureBytesAllocated() / 1024.0 / 512.0 - which is the same as LLImageGL::getTextureBytesAllocated() * 2 / 1024 / 1024 as seen before - and LLVertexBuffer::getBytesAllocated() / 1024.0 / 512.0. Also the total amount of VRAM of the GPU is needed. Of course there should also be some reserve for other applications, so they get granted a reserve of 512MB - if you remember what we found out earlier, this reserve is completely from the reserve calculated earlier - if there was a reserve all. Anyway... no matter what, the viewer always claims 768MB for itself, which leads a mimimum total VRAM of 768MB. Based on that calculated total VRAM and the estimated VRAM usage of the viewer, the over-usage percentage is calculated to determine by how much the discard level on the texture has to be increased. You might have noticed that here suddenly the memory used by Vertex Buffers are also taken into account, while previously it was not. Honorable mention: RenderMaxVRAMBudget debug setting: This setting overrides the total VRAM reported and can be used to cap the amount of VRAM the viewer is actually using. The setting description says that a restart is required. However, a restart is only required to get a "correct" display in the Lag Meter floater and the texture console since its value gets passied into LLWindowManager::createWindow() at startup and affects the result of LLWindow::getAvailableVRAMMegabytes() - and that only on Windows, since it is not part of the macOS implementation. But for the texture discard level calculation, it is instant, because it is taken into account in LLViewerTexture::updateClass(). So, here's a list of questions: What is the point of LLViewerTexture::isMemoryForTextureLow(), LLViewerTexture::getGPUMemoryForTextures() and LLWindow::getAvailableVRAMMegabytes(), if their sole purpose is just informational? Why is the data displayed fundamentally different from the data the viewer's decisions are based on? If the displayed data should actually reflect what the viewer is really doing, how about having one calculation that is used throughout the viewer? Why is this a total mess?

According to Davep, texture transparency handling was fixed a builds ago, but it still happens specially with XY Text based scripted / objects. I did checked several other places known to using similar scripts... same results... garbled ugly rendering. (This on the latest viewer @ github marked with release/qa tag as of today, the current official viewer also shows same behavior) Sometimes, it seems to work fine, after a while seems stuck.... There are hundreds of gadgets and signs in-world using scripts based on XY Text. This bug is probably a showstopper for many. http://maps.secondlife.com/secondlife/Taber/110/186/3102 http://maps.secondlife.com/secondlife/Bay%20City%20-%20Moloch/183/150/2219

Have a large prim like a landmass object. When viewed from one side it renders the full resolution texture. When the camera is rotated slightly, the texture goes low res no matter how close I look at it. Turning the camera a few degrees back makes it high res again.

At some locations most of the content looks black and white unless you set Refection Coverage to none. The attached pictures were taken at http://maps.secondlife.com/secondlife/Alope/252/195/21 facing east. The one looking black and white, Reflection Coverage set to full scene, the normal looking image set to none.