Henri Beauchamp

Yes, and this is done on purpose; this way you can share the same IMs, groups and chat history files for use in my viewer and LL's, for example... Since all other, viewer-specific files and sub-folders bear different names in that folder, there is no risk of any collision. The Cool VL Viewer installer never touches your settings and chat/IM/groups logs files and thus always keep them intact, even when uninstalling the viewer. About graphics settings, another one you will want to enable is triple buffering (this prevents tearing with VSync off, and could, maybe, prevent to turn VSync off if kept off as well). IIRC, there are two related settings (”allow” and ”enable”, or something in that vein), in the NVIDIA control panel. Same thing in case of per-application settings, of course... Yes, it is normal that today's viewers use a full CPU core at 100%, plus 50% to 100% of another full core (actually used by NVIDIA's threading driver) when just ”sitting” there with everything rezzed and frame limiter and VSync both off; with SMT CPUs, it means you will see 3 or 4 virtual cores loaded at 100%. While rezzing, newer viewers (implementing LL's ”performances viewer” improvements) will eat up even more cores, and the Cool VL Viewer even more than these (up to 100% of your CPU cores) so to rez things even faster. To avoid wasting power and keep fans quiet(er), you may want to try the frame limiter (for viewers having one), but AFAIK, only the Cool VL Viewer implements a ”smart” limiter that does not impact the rezzing speed at all (and in fact, improves it since, at each frame and when there is still some job to do, rather than just sleeping the CPU, its ”free time” is used by my frame limiter algorithm to rez even faster, while still keeping a lighter load on the GPU by not rendering uselessly too many frames that your monitor won't even display).

The Cool VL Viewer has always been faster... 😜 Very strange... The core GL profile provides a massive boost for me with NVIDIA cards (no gain whatsoever with Intel or AMD, and even a slight perf degradation with them), tested on three different PCs, with GTX 460, GTX 660 and GTX 1070Ti, under Linux, Win7, Win11. Did you enable threading in the NVIDIA control panel 3D (system-wide) settings ? The warning is merely for GPUs much weaker than yours (which could likely deal with 4K display at the same frame rates). Again, check your NVIDIA system-wide settings, and verify that VSync is set to ”let application decide” or something in that vein. That panel also allows to set per-application settings: check that Firestorm or the SL viewer do not have VSync overrides set in these... No. The Cool VL Viewer uses separate files (different file names) for all its settings (and a different cache folder too, for assets, textures, objects, etc).

And that's why I think the current work around the PBR viewer and the deprecation of the forward renderer (that is much lighter on weak/old GPUs, and that leads to a much lower power consumption on modern GPUs) is a mistake or at least on a bad timing... Add to that the skyrocketing energy costs which make SLers conscious about the power consumption of their computer, and you logically can deduce that any code change leading to raise the hardware ”minimum requirements” is a bad thing, at least for now...

Thanks to sse2neon.h it has been surprisingly painless (if you except the time the builder had to spend rebuilding all the pre-built libraries on his ARM64 system)... Adapting to Android is certainly possible (at least as long LL does not remove OpenGL v2.1 support, which could happen with the PBR viewer). Android is ”just” Linux by Google, but still has differences that would require code changes in the viewer itself. You may as well run Linux on most Android devices, but it sadly often requires quite a bit of hacking...

If we go by the tree relation of the name, then it would be a ”grove of Lindens”, like already suggested... Or a ”thicket of Lindens”, perhaps (and I'm not suggesting Lindens are ”thick” or ”dense” 😜 ) And when the thicket of Lindens stands under the rain, it becomes a Linden infusion...

A virtual mess ? A bear pile ? A bear-able mess of Lindens ? (for military-minded ones)

I made several edits in a raw (it was past 02:00 and I was tired): you probably missed the last ”line 134” addition I made just before going to bed... Yes, you'd need to update glibc; it should be doable without reinstalling everything (that's the beauty of Linux), and ”just” a matter of finding the glibc v2.32+ packages for your distro (you could grab packages from a newer distro and install them manually in yours). Sadly, the pre-built libraries builder apparently updated his own system and re-complied some libraries with it... This kind of things will not happen any more when I will have bought myself an ARM64 SBC, at which point I will ”officially” support Linux-arm64 Cool VL Viewer builds.

Not line 134, no, but you may change both (clang will accept it too, for Darwin). Normal... libopenjpeg is pure C code... Yes, but with just the change of the compile flag, you should get it to compile without risking breaking sse2neon.h for other compilers.

See my EDIT above :-P Yes, apparently Phil encountered the same issue, at first, but he also found a newer distro with a newer glibc for his PI...

I thought I had that fixed already ! 😲 EDIT2: I did fix it for v1.30.1.2 (experimental branch), but forgot the v1.30.0 stable branch... 🤪 These are just ”warnings treated as errors”, because we use the pedantic -Wall and strict -Werror. You should be able to compile the viewer nonetheless, using the ”--ignore-warnings” option (or ”-i”, for short) in the linux-build.sh command line, i.e. ./linux-build.sh -i But I'll try and (blindly, since I cannot test) fix those warnings. EDIT: the missing ”asm” is likely due to your gcc compiler being (strangely, since I'm not seeing this happening with gcc for x86_64) too strict about the C standard. Try and change 'set(CMAKE_C_FLAGS ”${CMAKE_C_FLAGS} -std=c11”)' for 'set(CMAKE_C_FLAGS ”${CMAKE_C_FLAGS} -std=gnu11”)' line 134 of linden/indra/cmake/00-Common.cmake EDIT3: the implicit posix_memalign issue should be fixed after inserting '# include <stdlib.h>' before '# include ”sse2neon.h”' in linden/indra/libopenjpeg/dwt.c and linden/indra/libopenjpeg/mct.c Not sure why sse2neon.h is not including stdlib.h by itself...

With future/arriving SBCs using the new RK3588, you will likely be able to double or triple that FPS rate when compared to the PI4B RK3399 I'll probably buy one (once proper Linux support is available) next year... I would also be interested to know if you can compile the current Cool VL Viewer release (v1.30.0.19) on your PI, using its current pre-built arm64 libraries.

Solution sent in PM, the reason being that while using a trivial recipe with the official SL viewer, it still exposes a ”security by obscurity” ”protection” (or lack thereof) of sound assets... This said, it would be nice if LL could officially implement in their viewer a way to recover any of your own assets (the ones you are the creator for). It is of course already possible for note cards and scripts (via text copy/pasting or the use of an external editor, in recent viewers), but the rest relies on ”tricks” or is close to impossible (for a rigged mesh asset, for example).

If you cannot reproduce the same issue with other viewers, then it might indeed be a Firestorm bug: I'd suggest you verify, by using another viewer for a while (i.e. enough time that you can be confident the bug does not happen at all with it), then, once you are sure it is indeed Firestorm-specific, report to the bug on Firestorm's JIRA. I would recommend using LL's official viewer for that check, since in case you could reproduce the bug with the latter, you would then be well founded to report it on LL's JIRA instead...

You would probably be better off fixing the bugs in Cinder's updated Radegast version so that it properly works under Mono: main issues are about broken fonts and buttons, so that's not something terrible to fix... Do not count on me, however. I'm busy enough with the Cool VL Viewer.

Synaptic is just a GUI around apt (and also rpm, for example in PCLinuxOS): it is very good and easy to use.

You just need to install the mono package that brings Mono Windows Forms support, which is likely named ”mono-winforms”, or something in that vein... Simply fire 'synaptic' (your package manager) and search for ”mono”, or ”forms” to find the proper package.

Radegast v2.12 runs just fine with Mono 6.6 (the version I am using) under x86_64 Linux.

This won't have any significant impact for non-gaming PCs: the problem with them is the number of shaders involved in the render pipeline. Their GPU is just too weak to run that many (and that complex) shaders, whatever the number of objects involved in the scene. That's why keeping the forward rendering mode is so crucial to avoid ruining the SL experience of non-gamers.

@ChinRey Your description is no different than what already happens with today's materials... Take a latex outfit, for example, it might just look as a matte surface with ALM off. And so what ?... E.g. when I travel in SL (sailing, flying, riding, etc), I cannot care less about a specific latex outfit an avatar is wearing in the distance, but I do care about large draw distances at good FPS rates, as well as an anti-aliasing algorithm that does not make the scenery look blurry, with bad banding on distant parallels, for example... In this case, turning ALM off is the best compromise, by far, especially if you do not have a gaming PC. However, when frequenting a BDSM club, I want to see all the gorgeous latex outfits and accessories, and I turn ALM on. PBR will be no different, at least as far as my SL usage is concerned.

The forward rendering mode uses just one texture (the one that existed since day one in SL), the diffuse texture. All the rest is ignored (not rendered). PBR materials will not be seen (just like current materials are not): not a big deal as far as I am concerned, as long as the viewer got a rendering mode that runs at decent frame rates on non-gaming PCs (or mobile: the Cool VL Viewer already got ARM builds)...

You are mistaken. The forward rendering mode cannot care less about materials (it simply does not use them), be them current (ALM) materials or future PBR ones. That map will simply be ignored; you will not see all the ”shinies”, but things will keep rendering as they do today when you switch ALM off. Anyway, should LL force deferred rendering on with their future viewers, you will see a Cool VL Viewer version with a dual renderer (as I already did with WL+EE), one with PBR, and the other with forward rendering...

The only problem with 32 bits Linux viewer is actually with boost::fiber and/or boost::context (I would rather suspect a bug in the latter, since it is the underlying and architecture-dependent code for fibers). The use of boost fibers causes an immediate crash with 32 bits Linux builds, when 64 bits builds run just fine and 32 bits Windows builds run just fine as well... With the old, Linden-patched/modified boost coroutines (IIRC, in boost v1.68) the 32 bits builds were working fine, so I kept for a while a dual-path code (coroutines and old boost for 32 bits Linux and up to date boost with fibers for everything else), but it was unpractical and held back some newer code from being backported in my viewer, and since, after a poll, I got the confirmation no one was running 32 bits Linux builds any more, I gave up on them (and on 32 bits Windows as well)... Yes, this is the last working Mono-compatible version... Sadly, Cinder's Radegast versions never properly worked under Linux+Mono for me. However, this version is using old protocols (login and inventory, especially), and the old login protocol was supposed to be removed from LL's login server (but is still available for now), so using this version might become impossible at some point. To save your time, first check what glibc version the distribution you wish to try is supporting. The pre-built ARM libraries builder (bjdragon) apparently used a distro with glibc v2.32, so any 64 bits Linux distribution with a glibc version equal or newer to v2.32 should do and would normally be able to run the existing Cool VL Viewer ARM binary.

There is nothing ”insane” at all (and I would appreciate you do not insult me by calling me insane or anything else in that vein, thank you). Again, it's a matter of choice. Yes, I never used ALM so far, so to be able to enjoy faster frame rates at larger draw distances (and also because ALM looked ugly, with blurry scenes)... So what ? With the upgrade, 3 years ago, of my main PC to a GTX 1070Ti (which is powerful enough to deal with ALM, even if it means a much noisier cooling due to fans spinning much faster), the improvements brought by LL's performance viewer a few months ago, and the backport I made from Alchemy's SMAA shader (which partly fixes the ugly blur seen in ALM mode on detailed textures) a few weeks ago, allow me, today, to enjoy (with the Cool VL Viewer) the same frame rates on my main PC with ALM on (but I still keep it off when traveling in SL, because the AA is still bad while moving around, when compared to the forward anti-aliasing). This does not make my point any less valid or urgent (and, yes, worrying to the point of alerting people) for people not having a modern gaming PC available to run SL !!!

Take any modern computer (a notebook, for example) without a discrete GPU, and you would be faced with the exact same problem with ALM ! It's not just ”old potatoes”, it's pretty much any non-gaming PC ! I will add that this move (lowering the FPS rates on ”modest” hardware) goes right in the opposite direction to SL porting on mobile platforms (that is quite feasible, as long as the rendering engine is not too heavy, or at least got a ”lightweight” direct rendering mode). That is why CHOICE is important: everyone is using SL in a different way, and LL is going to remove a choice (better FPS rates and/or draw distance at the cost of slightly less ”realistic” scenes). I am not ”demanding other development is held back” but simply that LL keeps the same direct rendering mode as we have now (i.e. without PBR) available. This is quite feasible, even if it involves two different sets of shaders and some branching in the render pipeline: I already did it with the Cool VL Viewer v1.28.0 when LL shoved EEP down our throats while its shaders and render pipeline were still largely unfinished and caused a large loss in performances: with that viewer, you could choose between the Windlight and the Extended Environment renderers.

Yep, exactly what I meant... Down to half the performances with an iGPU (or ”old” GPU: e.g. GTX 460 or 660) and ALM on is also what I am seeing, here... There is no way any of these improvements will compensate for direct rendering simplicity, on ”weak” hardware: Intel iGPUs and AMD APUs, but also (not so) old graphics card, such as anything below a GTX 960, not to mention even newer AMD cards, since they are so much weaker than NVIDIA's when dealing with OpenGL. There is simply not enough power in these GPUs to run that many shaders ! People with a modest/old PC cannot care less about PBR or ALM: all they want is decent frame rates and draw distance (sure, you can get better frame rates by lowering the draw distances, but then you cannot enjoy SL as you should). What I want is to still be able to use forward rendering (without PBR) as I can do today. To me, anything below 60fps is sub-par and below 30fps is unacceptable... Especially when walking/driving/sailing around !!! Equally, a DD below 256m (and 512m in islands, i.e. sims without neighbouring sims) is sub-par, and anything below 128m is unacceptable. I'd rather switch off ALM (and double the frame rate or DD as a result) than enduring such low rendering performances !