Henri Beauchamp

Likely a race condition between the two regions you are crossing to when in a corner and moving to the opposite region on the diagonal. As I guess it, the race could be as follow when, e.g. you are in region A and you walk NE to region B that you want to reach, and there's region C, North of A and West of B: you cross the corner and shortly get into C and from there cross to B. Normally, you would get: CrossedRegion sent by departure region A with destination region C. Region A hands over to C (server to server messaging). CompleteAgentMovement sent by the viewer for region C. CrossedRegion sent by transit region C with destination region B. Region C hands over to B (server to server messaging). CompleteAgentMovement sent by the viewer for region B. But, what may happen, due to variable region ”ping” time with servers and reactivity (depending on their load), and the moment they are when receiving the messages during their frame (start of frame: message taken into account immediately, middle of frame and message processing delayed to next frame), you could actually get: CrossedRegion sent by departure region A with destination region C. Region A hands over to C. CompleteAgentMovement sent by the viewer for region C. CrossedRegion sent by transit region C with destination region B. Region C busy re-serializing the agent data it just de-serialized but must still update before re-sending to next region, meaning likely a one frame delay. CompleteAgentMovement sent by the viewer for region B. Message rejected by region B, since no handover was received for this agent yet... Region C hands over to B (finally, but after the viewer sent its own message !). Region B confused: where's that agent ?... Why did not I get its CompleteAgentMovement ? Of course, this is just a wild guess... But it could be fun to try and work around this guessed race condition to see if the hypothesis is correct. Viewer-side, we could try two things, when two region border crossings happen in a row: Delay the second CompleteAgentMovement a little bit (say, by 250ms, or a ”ping” delay + one region frame (20ms)). Send a second CompleteAgentMovement to B, if not ”hearing” from it after a couple seconds...

The effort is not vain, by far: even though Rosetta does a good job running x86_64 apps at decent speed, it cannot perform as good, when it translates x86_64 optimized code into aarch64 code, as what a proper optimizing compiler would obtain when compiling from sources into aarch64 binary... For the SL viewers, however, and since they use OpenGL, and since the latter is implemented like sh*t by Apple, the bottleneck at the GPU level is what drives their performances, far more than the C++ code optimization level.

It does, sort of, for Apple Mx, since those GPUs were only designed to run Metal, with an entirely different architecture as what a GPU designed for OpenGL can do. You end up with ”translated” OpenGL primitives into ones that can be implemented with Apple's custom GPU hardware architecture... OpenGL has always been implemented like utter sh*t by Apple, resulting in extremely poor performances for OpenGL apps on Apple hardware, while the latter usually got quite capable CPUs and GPUs... Beside, and AFAIK, there is not even a native aarch64 OpenGL driver for Mx... But I could be wrong here.

I am curious about how he got a native macOS ARM build (and how truly ”native” too)... The viewer contains SSE source-level code that can only be ”translated”/adapted via specific libraries (such as sse2neon), and he would have had to rebuild for ARM64 all the third party libraries used by the viewer as well... This is totally doable, and a couple contributors to my viewer and myself did it (for Linux only, so far). But it is not trivial either. However, AFAIK (but I am not a Mac specialist, by far: I do not even own a Mac and just toyed with Hackintosh x86_64 virtual machines, which cannot even run a viewer, but can still build it), there is no access to the OpenGL API for native ARM64 macOS builds, making it even more complex a task to compile a truly native SL viewer for macOS Silicon... So this gets me even more curious/perplex... 🤔 This is because, under ARM64 macOS, the bottleneck will be at the OpenGL emulation level, not at the C++ code one (be it ran from native aarch64 binary, or ”translated” via Rosetta from x86_64 to aarch64). Note also that Rosetta is not exactly an emulator: it is a dynamic binary code translator, taking a x86_64 piece of code it runs for the first time, translating it into its aarch64 (ARM64) counterpart, and then running the said translation for any further occurrence of that same piece of code: this is extremely efficient for speed (waaaaay less for memory consumption) after the first run (and you do not really care about the high inefficiency of the first translation run for pieces of code that will never be ran again). The same kind of translator exists under Linux (e.g. Box86 and Box64).

Try installing from a DVD, then (it's usually what I do anyway).

Wait... USB is just for installation/upgrading. Booting and running an OS from it is too slow (and prone to USB memory failures/corruptions: these prmitive and cheap NAND USB memory chips do not have a high endurance neither a ”clever” controller to spread writes over the whole memory and swap faulty blocks with reserved ones, like what happens on SSDs) ! Just install a dual (or triple: Linux +Win7 +Win1x) boot on your hard disk or SSD. Linux can do this just fine for you.

Did you try Rufus ? FYI, my oldest still running PC is based on a Core2 Quad Q6600 (OCed @3.4GHz) with 8GB RAM (and a purely BIOS, non-UEFI motherboard) and a GTX 460, and it does run Windoze 11 (in excess of Linux and Win7 which both run SL viewers much better and faster than Win11, with a blatant (+20% fps) advantage under Linux)...

Here you go: for its 16th birthday, official Cool VL Viewer ARM64 Linux builds. Note: for such a build to properly run on an SBC, you will need proper Panfork support for your GPU (if it shows ”LLVMPIPE” in the About floater, you do not have it and it would be unusable since waaaay too slow).

I still suspect a timeout due to an unreplied server message, here... If I were you, I would log all server messages and see whether my viewer does reply all of them.

Or of a missing reply to some other server message, causing the said server to ”pause” messaging to your viewer, waiting for it to reply before finally timing out on the latter and continuing with the rest of the queued messages... Yes, and it is still in use (even though all the asset and texture reserved bandwidth it accounts for should now be removed both viewer and server sides... A work for @Monty Linden ? 😜); this also means (and contrarily to an SL urban legend about supposed bad effects of a large UDP bandwidth setting) that you can now use a much larger bandwidth number (only part of it will be used for objects data, anims start/stop, etc, anyway). I personally use 32Mbps as a setting (I'm on an FTTH link) in the Cool VL Viewer (which defaults at 8Mbps).

What viewer are you using ?... Why is is so difficult for people to give proper clues for the problem they encounter ? 🤣 I suppose (wild guess, by lack of information), that you viewer is not PBR-enabled and did not recognize the new Materials folder as a ”valid” system folder. Make sure you are using a PBR-enabled viewer if you want to test PBR/GLTF materials. There are currently four of them (by order of appearance/availability): LL's PBR RC viewer. Alchemy beta viewer. Cool VL Viewer, experimental branch (v1.31.0). Firestorm PBR alpha viewer.

Just a wild guess, but are you replying to ”StartPingCheck” with ”CompletePingCheck” too ?...

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