Henri Beauchamp

Went there, all four regions come up and everything rezzes in less than 20s. Here is the relevant log info with milliseconds accurate time stamps and UDP messages debugging enabled (repeated, irrelevant messages removed for clarity); maybe you will find what is missing in your viewer/servers communications.... But you could learn a lot by yourself via the use of the Cool VL Viewer logging features (that's how I managed to make threaded object cache reads work flawlessly): Get the viewer, launch it, log in and go to the place you want in SL. Disable ”Advanced” -> ”Caches” -> ”Threaded object cache reads” (this way the viewer will behave like LL's and other TPVs and the threads delay won't risk polluting the messages sequence). Enable ”Advanced” -> ”Consoles” -> ”Precise timestamps in log file”. Use the mini-map to help setting the draw distance so that you can see only the four sims in the FOV cone (192m did it for me at the approximate position of your screen shot). Log off. Relaunch the viewer, and at the login screen use ”Advanced” -> ”Debug tags”, and in the floater that opens, scroll down and check ”Messaging” in the list; you may also enable ”EventPoll” if you are interested in those in excess of what is already normally logged at INFO level. Close the floater. (*) Log in, wait for everything to rez and your avatar to bake, then log off. The CoolVLViewer.log will contain all the detailed login and rezzing sequences, with detailed log messages. (*) Note: this floater allows to enable/disable DEBUG level messages in real time; once logged in there is also an ”Advanced” -> ”Consoles” -> ”Allow DEBUG messages” option (automatically checked when you did enable a debug tag), to disable/re-enable at once all the debug messages corresponding to the configured tag(s) when you deem appropriate, so to avoid too much/irrelevant spam in the log file (and console).

Library versions are not the only problem... For example, a TPV I will not name by charity, decided that it was a good idea to rely on a systemd-specific library, meaning you cannot use that viewer at all on systemd-free Linux distros... Other issues could arise from the usage of specific toolkits (e.g. a specific GTK or QT version, or xdg-desktop-portal for the file selector), here again, complicating things if you do not have the corresponding toolkit installed on your system... For the Cool VL Viewer, I have been extra careful to avoid such silly dependencies, making it compatible with all (not too old) distros.

You should try the Cool VL Viewer more often... I lost the count of how many times I have been releasing experimental branches with LL's RC viewers (or even project viewers, i.e. before the RC stage) code backported (and debugged by me, meaning less bugs than in LL's viewer !)... The current experimental branch implements PBR (while also still being able to render in ALM and forward modes, meaning I implemented a dual renderer), and even the stable branch can do Puppetry (something no other TPV can do, and LL put on hold)...

You do not give the version of macOS running on it, and this is the determining factor. Newer viewer builds require macOS 10.13 (High Sierra) or better. Your iMac13,1 is apparently (from a quick web search) capable of running 10.15 (Catalina), so if you are running an older macOS, you should be able to upgrade and run SL viewers again.

A couple other places in SL (main grid, with heavy mesh and texture contents) I do visit for stress-testing sessions (with 256 and 512m draw distances): Sainte Rose sur mer & bar Deco Ethereal City And of course, crowded clubs are also great for testing. I also use a lot YavaScript pod tours (base station, but there are many others: click a pod and get the ”Pod tour information” notecard for a full list), which are great for stress-testing the texture fetcher, the object cache, the mesh repository, etc (especially at 250% speed, but make sure to slow down on corner sim crossings 😛 !).

I verified and LL's viewers can still be ran under Windows 7, with the exception of the CEF plugin (it simply won't start) and the version checker (but deleting SLVersionChecker.exe from the installation directory allows to start and run the viewer just fine). I also started a poll for my own viewer...

Wine got bugs (at least two of which do impact viewers), making it a very bad option to run a viewer under Linux. I got workarounds for those bugs in the Cool VL Viewer, but even so, the stability is at best fragile, and the frame rates and smoothness very bad... Just run native Linux builds.

I give the prerequisite on the Cool VL Viewer web site:

For the version checker (and Python) issue, you can simply remove the SLVersionChecker.exe binary from the viewer installation directory (the viewer will complain it cannot start it, but will run without it nevertheless). However, I am not sure how LL specified their build target on github for Windows: if they did not specify a WINVER=0x0601 option, then their viewer binary won't run on anything older than Win10... The Cool VL Viewer still can run under Windows 7 (and 8.x), but for a couple releases it has already been using LL's CEF v118 github's build to replace the (vulnerable) CEF v91 old build, meaning you won't have a working web plugin any more under Win 7/8.x... I might add an option to build it against CEF v91 again, but you'd need a Win10+ system (or VM) to build it anyway (since VS2022 won't run either under Win7, even if it can build Win7-compatible binaries)... It becomes harder to support Win7/8.x, and updates to those, while still possible using tricks and hacks (making them POSReady-like systems), will also soon cease to be distributed by M$... Time to upgrade... Or switch to Linux ! 😜

The Cool VL Viewer (not ”CoolVL”, please...) requires a proper OpenGL driver to work (it does not have a text-only/headless mode), so it won't work on this terminal emulator...

There must be something very wrong in your system configuration, then... Tanuki, who built and used the viewer on their RockPro64 reported 10-25fps... Of course, it was not with ALM+shadows... This said, the level of OpenGL support for your card is of course the determining factor... If your Mesa version does not support your iGPU, it will fallback to CPU-side rendering, which will prove too slow to be at all usable. The viewer is NOT using Direct3D, but for the graphics driver version and VRAM amount detections. For rendering, it uses OpenGL, and only OpenGL, so the Vulkan code will never be used. The fact the viewer can run fine under Wine emulation for you (meaning you got a valid native OpenGL driver for your SBC, which Wine is using too), simply proves that you could run a native ARM64 build even faster (since then there will be no need for x86_64 to ARM64 CPU emulation/translation).

You should instead try and compile a genuine Linux viewer on your Pi: it has been a while the necessary libraries have not been updated, but the Cool VL Viewer used to compile and work (natively) on such SBCs. I am still keeping an eye myself on the Rockchip RK3588- based SBCs (such as the Orange Pi5, or the Radaxa Rock 5B), since they will be way more capable for running a full-fledged viewer. If I could find one such board at an affordable price (and with proper Linux support, especially for their iGPU), I would buy one and start providing ARM64 builds of my viewer...

This would be the sign that the (relatively) new ”ReadOfflineMsgs” capability is bugging (again): Radegast is old and does not use it (it uses the legacy ”RetrieveInstantMessages” UDP message). You could do this too with the Cool VL Viewer (In the ”Advanced” -> ”Network” menu, un-check ”Use offline IMs fetch capability”), and FS might have an equivalent setting (at least, it did have one in the past); ask to their support group. It might also be worth filing a JIRA issue for this bug, so that LL works on the broken capability (be it server or viewer side).

I suppose you mean ”10.13.6” (macOS Sierra) ?... This is the minimum requirement as of last Summer. So, it should work... If it does not, open a JIRA issue for it, providing all the info you can (a stack trace is most helpful), and in the mean time, you could use one of the TPVs' macOS builds, instead...

They would run just fine under x86 emulation over ARM, just like what Apple did with Rosetta (and no, I do not like Apple, at all, due to their closed source, closed hardware, and Open Source-hostile policies, not to mention their tax evading policy, but when they do something ”right”, they deserve my recognition for it)...

Well, currently, Linux (and its forks, such as Android) and BSD (and its forks, such as macOS) are immensely more common than Windows for ARM hardware. So... 😛 As for ARM vs x86, here is my stance: As a Linux user, should we get ARM-based desktop PCs with the same performances as existing high end desktop x86 PCs, it won't bother the least to switch to the ARM solution, much to the contrary ! x86 is an antediluvian, poorly designed ISA (*), which is today impaired by all the compatibility modes it must keep to run old software, causing bloated CPUs full of (mostly) useless parts needed to run those legacy 16 and 32 bits modes, support segmented memory (eeek !) and whatnot... ARM would at least allow to get rid of all this old cruft, once and for all (and yes, at the cost of using emulators for the old software, but those won't suffer from the emulation since they were designed to work on waaaaay slower hardware). (*) If only IBM had chosen Motorola and its gorgeous m68k ISA (32 bits registers, flat memory model, I/O in memory address space), instead of Intel and the 8088 (8 bits, segmented memory, separate I/O ports), we would have gained 10 years of advance in OS design for PCs, instead of waiting before Windows 95 (1995) and Linux (1992) could finally offer true multitasking 32 bits OS for the x86; back in the 80s, we already had genuine 32 bits OSes on the Macs, the Sinclair QL, the Amigas, the ATARIs, and genuine preemptive multitasking on the QL and Amigas...

In fact, you perfectly can... Micro$oft hid them, but the options to install (or upgrade) to Windows 11 do exist, even on super-old hardware; I installed it on my 4th PC (the ”main PC” I was using back in 2008-2012), which is based on an old Core Quad Q6600 with 8GB RAM and a GTX 460, without EFI (thus without a TPM neither ”secure boot”), and therefore on a MBR disk. The simplest way to do it is probably via the use of Rufus to setup a bootable USB stick installation drive. Another option is to install Linux (as a dual boot if you really want to keep Windoze after having tasted to the speed, stability, safety and freedom brought by the Penguin's OS 😜 ); it would juice out the best possible performances from your aging PC.

The cache misses will happen, especially on data, but on instructions, it is likely that all critical parts of the viewer code (the parts that run at every frame) will be kept in the CPU caches: they will of course migrate between the L1, L2 and L3 caches (especially during context switching by the OS scheduler), but today's L3 caches are so large, that the probability to see this critical code evicted from it is very slim... Also, be careful: L1 and L2 caches are per CPU (full, i.e. non-virtual) core (so the total quoted amount is to be divided by the number of cores, and by two again for the L1 instruction/data caches actual size per core), while L3 is shared (though maybe split in two, e.g. for AMD's Zen4 CCDs with 2x32MB for non-3D parts and 32MB/96MB for 3D ones); Intel recently made it even more confusing, with their ”smart cache”, which may allow cores to use some L2 cache from other inactive cores... It would be interesting to do some benchmarking on a Zen4 with 3D-V cache (and two CCDs) and see wether assigning the viewer main thread to a (full = 2 SMT virtual cores) core on the 3D CCD gives better results or not than when assigned to a core on the other CCD (with the smaller L3 cache)... This can easily be done with the Cool VL Viewer, using the ”MainThreadCPUAffinity” setting.

There is nothing ”stupid” in sharing info with persons you trust in ”public” places (not so public, for SL chat, just like for a RL pub; their audience is however limited and known from the chatters at the moment they are chatting). Beside, you cannot use others' ”stupidity” as an excuse to violate a TOS (here, SL TOS). I never said otherwise, but what I say is that if a place uses such a relaying tool, there must be an unmissable warning about it for everyone visiting that place that their chat will be relayed and recorded (one of the aspects of Discord I personally dislike) outside of SL. Not saying no one should use such tools, but just saying they must be used in accordance with SL TOS... And I do not see how anyone could disagree with this ! 'nuff said !

Try the Cool VL Viewer: it got a workaround for this one...

The 3D-V cache would not bring any benefit to SL viewers. The latter are already small enough to fit all the critical parts of their code into the L3 cache on non-3D counterparts, and the latter boost higher in frequency (the SL viewer is very sensitive to mono-core CPU performances). I myself bought a Ryzen 7900X for my new main PC, which replaced one with a 9700K. I'm not interested in a 7900X-3D; the 7900X performs beautifully in SL, and is a beast to compile large programs. E.g. the Cool VL Viewer compiles in less than 3 minutes on it, which is a huge time savior, when compared to the 10 minutes it took on the 9700K. Even CEF (the embedded browser library used for the viewer web plugin) builds (from scratch, with downloads, git ”deltas” etc, which take about 35 minutes to complete) in less than 1H35 (against 2H10 for the 9700K)...

It may contains private matters, especially during adult role-plays, e.g. about your kinks, which in turn can hint about your sexual preferences, RL gender, etc... It may also contain hints about your RL location (where you live), your political opinions, or other things you would share with persons you chat with in SL (and not necessarily during a RP, but about RL matters instead) when ”face to face” with their avatar, after you came to ”know them” better, or even, more private things you would chat with a group of SL friends, and that you would never share ”in the open” on Internet. You cannot make any assumption about what a chat post will contain, and whether or not it could lead to private info disclosure (even if indirectly). You cannot therefore relay the chat for everyone to an external service (especially one that exposes that chat publicly) without first ensuring the chatting persons are aware about it. Here is a RL analogy: you go get a drink in a pub with a group of buddies, and you chat in that pub about stuff (politics, private relations, your health, etc): you do so in a ”public” place (and other clients could overhear your conversation), yet you would sue the owner of that pub should they record your conversation and publish it on Internet... Same thing for SL !

Just... LOL !

I fly and sail with 512m draw distance. 256m is not enough to see where you are going. Not an issue with the Cool VL Viewer though (it is fast enough). 😜

Whatever you wrote earlier is not the issue I reacted about (and yes, I did read your former messages, and even visited the sites you linked to). What I reacted about is your dangerous shortcut in the very message I reacted to (what you wrote before this message did not shock me), and more precisely, the part in this sentence of yours I cited in my last post: This shortcut you did means ”LL TOS approval = Discord TOS approval”, and is all wrong. This is exactly what I reacted about. Period. And there is strictly nothing ”rude” in my post, so please do not be ”rude” in your turn...