Henri Beauchamp

And I still got a PC with a GTX 460 (and an Intel Core Quad Q6600 with 8GB RAM) that I also use for testing viewers... Also got a GTX660 (Intel i5-2500K, 32GB RAM), a GTX970 (Intel i7-9700K, 64 GB) and my current, main PC with an RTX 3070 (Ryzen 7900X, 64GB)... And even my Linux firewall PC is used for testing, with a poor man's iGPU (UHD Graphics 605, Intel Pentium Silver J5005, 8GB RAM). I would agree as far as you enable ALM in the (now legacy) viewers renderer (because indeed, and as long as you keep all reflections settings turned off, the PBR renderer does perform as good or even better, in most circumstances, than the ALM EE renderer), but it is an entirely different experience if you disable ALM in the latter (i.e. use the now removed ”forward rendering” mode): on old/”weak” hardware your frame rate will double, and your VRAM usage will lower enough that all the textures will look nice, instead of half blurry. I am sorry, but many users will find PBR too costly for their hardware, especially when they want to keep the same level of rendering quality (same resolution/viewer window size, same draw distance, same objects rendering LOD settings, textures that don't go blurry on them, etc). If by ”fixing” you mean disabling HiDPI (i.e. dividing by 4 the resolution of the render), then I suppose it is fixed... But no, really, it is not an acceptable ”fix”, and much less a ”complete fix” ! There are also many issues with the PBR renderer as it was shipped for release. e.g. ruined shadows or ugly ”waves-like” artifacts on water bodies surface when turning around or moving forward/backward with your avatar/camera, but also rendering discrepancies with the legacy renderer, when rendering legacy contents, e.g. full bright faces not rendering properly, semi-transparent faces with legacy diffuse textures appearing much less transparent/too opaque, legacy shininess not rendering the same, legacy (non PBR) materials not shining the same way, or appearing blueish, etc, etc... While I welcome innovation and always have been an eager early adopter, I still think that PBR, which will be a big plus for SL in the long term, has been rushed out too soon, which will sadly cause many SLers to hate it, while they should have loved it, had it been truly ready for release. This is why I decided to maintain a dual renderer (EE with forward and deferred/ALM modes + PBR) in the Cool VL Viewer for as long as LL will not come up with a properly fixed PBR renderer, and for as long as people with weak/old hardware will need an alternative. And by the way, dear Moles and Lindens, if I were you, I'd use the Cool VL Viewer to test the impact and discrepancies of the PBR renderer against EE ALM and forward modes: you can switch between the rendering modes in real time, with just the ticking of a check box, making it an invaluable tool to detect rendering issues...

This is not related to the PBR renderer itself, but to the fact that LL's PBR viewer (and all TPVs directly importing LL's code from git, meaning all TPVs but mine) changed the texture fetcher algorithm. <technical stuff> So far, the textures were fetched (and decoded, and cached) in the order of their priority (i.e. the higher priority textures first) and the priority (importance to camera, virtual size on faces using them, closeness to the avatar, texture usage - e.g. is it a preview texture, an attachment texture, etc -) was reevaluated every few frames for each texture in FOV. This priority was also preserved whenever the fetcher thread encountered a delay (e.g. cache read delay, HTTP fetching delay, decoding delay, cache write delay), with just a (huge), constant penalty subtracted from the priority when such a delay was encountered, penalty immediately reverted as soon as the callback for the step that incurred the delay was invoked (meaning as soon as it got ready for the next step, the texture found itself back with its original priority in the queue). Together with the PBR viewer (but independently from the PBR rendering code itself), LL changed that algorithm for a simpler ”first seen, first served” priority-less queue, in which, each time a delay is encountered, the corresponding texture is moved back at the end of the queue so that the fetcher can attend to the fetching of the next texture in the queue. This simpler (and quite naive) algorithm avoids the periodic priority reevaluation and the sorting of the queue before each new fetcher loop, saving some (but not that much, in fact) time on the CPU side during a frame. But on the other hand, while it performs almost just as good on high end hardware or at least hardware with balanced performances (good CPU, good network bandwidth, good storage speed), it performs like utter sh*t on weaker or unbalanced hardware (e.g. good CPU, average storage, poor network, or average CPU, good network, average storage, or excellent CPU and storage but poor or unreliable network, etc...): the problem here is that important textures that got delayed must wait for all other textures to pass through a fetcher loop before they have a chance to escalate to the next step. </technical stuff> This is the reason why you are seeing this slooooooow rezzing on some hardware with all PBR viewers but the Cool VL Viewer, for which I kept (and further optimized, tuned, sped up) the old texture fetcher.

The full LLThreadSafeQueue warnings seem highly suspicious to me, and could possibly be a factor in the login failure. The CertExpired error could also be relevant: if the viewer fails to negotiate a valid certificate for TLS transactions with the SL sim servers, you won't get in... Your best bet is to poke FS' support team and file a JIRA, providing the full log as an attachment to the JIRA issue.

Glad to hear it ! Strange that other viewers than mine (which, AFAIK, is the only only one to use extrapolated values) are not suffering from the same delays as the ones you encountered... 🤔 Also, it might be worth playing around with the bandwidth repartition in the slots: since ”Texture” and ”Asset” are no more in use (in SL), you might want to try and reduce those to increase ”Task” accordingly, instead, which I suppose would be the bandwidth reserved for object updates...

”Preferences” floater -> ”Cool features” tab -> ”Misc.” sub-tab -> ”Frame rate limit” spinner. Do read the tool tip and enjoy a quiet, cool and fast SLing (frame rate limiting will even lower rezzing time with the Cool VL Viewer, thanks to its smart ”free time” per frame utilization algorithm).

I extrapolated those for higher bandwidth settings in the Cool VL Viewer: // Bandwidth settings for different bit rates, they are interpolated / // extrapolated. // The values are for: Resend, Land, Wind, Cloud, Task, Texture, Asset static const U32 BW_PRESET_50[TC_EOF] = { 5, 10, 3, 3, 10, 10, 9 }; static const U32 BW_PRESET_300[TC_EOF] = { 30, 40, 9, 9, 86, 86, 40 }; static const U32 BW_PRESET_500[TC_EOF] = { 50, 70, 14, 14, 136, 136, 80 }; static const U32 BW_PRESET_1000[TC_EOF] = { 100, 100, 20, 20, 310, 310, 140 }; static const U32 BW_PRESET_2000[TC_EOF] = { 200, 200, 25, 25, 450, 800, 300 }; static const U32 BW_PRESET_10000[TC_EOF] = { 1000, 500, 25, 25, 1450, 5000, 2000 }; (see the linden/indra/newview/llviewerthrottle.cpp file in the Cool VL Viewer sources) Note however that these are just clues for the sim server, and as I understand it, the latter is the one making the actual decisions. It would also be about time to kill the ”Texture” and ”Asset” slots, in SL (not in OpenSim !), since those are now all transmitted via the ViewerAsset capability in SL... Oh, and ”Cloud” messages were removed years ago, too, from SL (I am now generating them viewer side, in the Cool VL Viewer, so that I can still enjoy Classic Clouds in SL).

Damned right !... I never understood why some people insist on and keep using those keys to move around in games, when the right-handed cursor keys are so much easier to access (well, maybe they are left-handed people only ?). Not to mention WASD only works on a QWERTY keyboard... 😛

Look at the ”WARNING” message lines, starting from the end of the log file: anything about the network, the inventory, for example ?... Also, providing the log file as an attachment to a FS' JIRA would allow FS devels to better/faster diagnose any specific bug. Oh, and by the way, my link to find the logs in my former message did not really apply to FS (which uses a custom folder for logs instead of LL's viewer standard log folder). See this article about where to find FS' logs.

Have a look at the log file: the reason for the failure, or at the very least an interesting clue, might very well be logged there...

I do not trust the least my own ISP's Internet box: I got it configured as a (pseudo) bridge, i.e. its routing firmware is disabled, and I am using a Linux firewall/router between it and my local network... Yes, I am paranoid, and proud of it ! 😜

Because you really think that a pseudo-Linux running under Windoze would auto-magically solve the issues with routers blocking tcp probes ?... 🤣

I tried with 100... It takes forever and never reaches the host. I also tried with the -A (TCP ACK) and -F (don't fragment) options, but still no joy... It would be so much simpler if LL's sim servers were configured to accept ICMP pings. 😜

Not here (and under genuine Linux): root:~# tcptraceroute -m 50 simhost-0af4b368836ec81c2.agni.secondlife.io 12046 Selected device eth0, address 192.168.1.2, port 45583 for outgoing packets Tracing the path to simhost-0af4b368836ec81c2.agni.secondlife.io (35.89.194.181) on TCP port 12046, 50 hops max 1 * * * 2 * * * .../... 50 * * * Destination not reached I also tried with port 12043 (the one used for capabilities), to no avail...

It works ”fine” (1) under Wine (tested with v8.21) for me, on the condition to delete the old cache directory first (2), else, it crashes, but Niran explains this in his blog post, last paragraph, in bold. And no, you do not normally need to install VS runtimes for Wine. Also, as for every PBR viewer using LL's latest (shadows-breaking) changes to the PBR shaders (AFAIK, all viewers but mine), you will need to set the ”RenderSkyAutoAdjustHDRScale” debug setting to 1.0 (instead of 2.0), else the sky will appear white instead of blue... (1) Well, as fine as possible, given known Wine bugs... (2) ~/.wine/drive_c/users/<your user name here>/AppData/Local/Black Dragon

Ask to your ISP whether your connection is a ”full stack” one (with all 65535 ports available) or not. If it is, the problem is elsewhere, if it is not and your available ports range is limited, either ask for a ”full stack” IPv4, or ask what ports range is allocated to you, and choose one port number within this range to configure the viewer UDP listener port.

Static or dynamic IP, it does not matter: if this is a port range limitation, it won't change a thing...

This could be a limited port range issue... To make for the IPv4 addresses shortage, some ISPs (seen with Free/Illiad in France) are configuring their routers to share a same IP between several of their customers, attributing to each of them only part of the available 65535 ports, e.g. port 1-16383 to customer 1, 16384 to 32767 for customer 2, 32768 to 49151 for customer3, and 49152 to 65535 to customer 4: if you are ”customer 1”, you are in luck and got the privileged ports in your attributed slot, but others will be in pain (especially when they host a server at home). With SL, ports 130xy are needed, viewer side; if your ISP routes them to another customer, you are hosed ! If you are in this case you may however configure the port used by the viewer for UDP (in the Network tab of the Preferences for most viewers), and you could also request a ”full stack” IPv4 from your ISP (they might make this a paying service, however)...

Try setting ”RenderSkyAutoAdjustHDRScale” to 1.0 instead of 2.0... Yup. Please see BUG-234564 and this post of mine about it. For these reasons, I did not yet port the culprit commit/changes to the Cool VL Viewer...

I warned them that it would kill the experience for people with ”weak” hardware... To their defense, LL's developers did try hard to optimize the renderer, but this is totally insufficient for ”old” hardware, like I anticipated (they even had to turn off HPDi for macOS, so bad are the frame rates with it). The good news is that, since my plea to preserve at least the forward renderer got ignored, I decided to implement a dual-renderer in the Cool VL Viewer (currently implemented in the v1.31.0 branch) :you can still use the EE renderer (in both forward and deferred (AKA ALM) modes) or the new PBR renderer, to your heart's contempt, and with just the ticking of a check box in the Graphics preferences (the switching happens in real time: no need to restart the viewer). I intend to keep maintaining this dual-renderer for as long as the PBR renderer will not be fixed (many graphics glitches still exist in it despite the (hasted) push to the ”release” status) and made faster... Or until LL comes up with a Vulkan renderer (whichever will occur first). This means you can keep enjoying SL for at least a little more time... 😉

This is Cloudflare's fault again (this thing is a total nuisance)... However it only repeats the check once for me, then allows redirection to the website. Usual suspect for failures with Cloudflare are: Disabled Javascript in you browser. Disabled Cookies in you browser. Unknown ”User agent” sent/advertized by your browser to the site. This sadly also badly impacts many ”confidential” (rarely used) forks of common browsers.

@sarcmp You could also try and log in with the affected account using the Cool VL Viewer; its inventory code is much more robust to ”unsuspected” issues and won't bar you from logging in. After login you could then try and repair your inventory: from the ”Inventory” floater, ”Folders” menu, choose ”Consolidate/restore system folders”, then log out and retry a login with other viewers. Note that the new inventory thumbnail code as implemented by LL (or more exactly the updates to the AISv3 inventory protocol that accompanied it) can result in this sort of issue as a missing system folder causing failures to log in (because they do not use any more the legacy UDP folder creation message that was synchronous and could solve missing folders issue by creating them in a ”fire and forget” way, instead of needing a callback after creation, callback that cannot be honoured during the login process).

You simply did not install gstreamer... Please, have a look at the installation ”howto” for your OS (e.g. Linux, Windows).

Can't help it: I'm of the ”plug and play” type... 😛

Good news: I don't ! 😜

Another stupid stance by Apple... Not the first, sadly, and likely not the last such stupid stance either, dishearteningly...