Henri Beauchamp

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 !

ALERT ALERT ALERT They are doing it ! This is totally, utterly, dishearteningly crazy, but LL is removing forward rendering (non-ALM) support from their future PBR viewer. See this commit. I urge users with modest PCs to publish here their frame rates with ALM (no shadows, no SSAO, no DOF) on and off (no other graphics setting being touched), so that LL, maybe, may understand how terrible is their mistake and how miserable they will cause many users to feel when logging into SL in the future ! ALERT ALERT ALERT

You were trying to build it from source (and there's an error in a MD5 sum for a pre-built library, thus the interruption). The installation of the existing build would have been simpler. 😜 Please, see my reply on the Cool VL Viewer forum, with the fixed install.xml file for building the current release from sources.

The Cool VL Viewer has been proven to be able to at least run on a PI4B (with and ARMv8 and 64 bits Linux distro) and on a RockPro64, with, citation: So...

False positives are, sadly, extremely common with anti-viruses... You must understand that anti-virus software work with either ”signatures” (meaning a small sequence of bytes that you can find in a given virus/malware) or with ”heuristics” analysis (meaning the anti-virus tries to find suspect sequences of code in the analyzed file; sequences that would, for example, write to the Windows registry, attempt to gain higher execution privilege, or overwrite/corrupt/infect some system file). Neither of these methods are 100% reliable, by far, and especially when it comes down to software installers such as found for Windows software: these installers use a compressed form of the software they install (and a byte sequence corresponding to one ”virus signature” could accidentally appear in that compressed data), and they do write in the Windows registry, in the protected Programs folder, etc, so they can be mistaken for ”hostile” pieces of code by some ”heuristics” engines (not to mention other random compressed data sequences that could look just like hostile code to the heuristics engine)... Anti-virus software providers are constantly updating their databases and engines to fix the false positives they have been made aware about, but it can take time... Point is, the very same viewer installer binary could have been considered safe three months ago, be considered ”infected” today and will be shown safe again in three months. If Virus Total reports just one positive, then it is most likely a false positive... Oh, and on a side note, before being detected by anti-virus software, a new virus always passes Virus Total tests like a charm !... If you want to be 99.99% sure you do not have any virus/malware on your system, then use a Gentoo Linux distribution (i.e. an operating system that is already natively very hard to infect (Linux), and you compile from scratch on your own computer, from well known sources): this is the only way... As a compromise and as far as SL viewers are concerned, you could also compile your preferred viewers from their sources, on your computer...

Did you check your computer against a malware (here, likely of the key logging, or files stealing kinds) ?... If your password is really a strong one (I personally use a randomly generated password, and I am only using it under well secured Linux PCs, and thus do not need MFA), then it is most likely that it was not guessed/cracked, but instead stolen, and if you did not give it away, the only solution is to have it stolen from your computer in one way or another. Also, do NOT use web-based email services to register your credentials, with any service: these are subject to data theft, and this could allow a hacker to pirate your email account and manage to fake a ”forgotten password” procedure to register a new password without you even noticing it. Always use an ISP-based email account, and preferably via a dedicated email client (Thunderbird, Sylpheed & Co) configured to retrieve and delete your emails from the ISP's server (this way, you are safer in case their server gets hacked and data on it stolen, not to mention privacy reasons for not letting clear text emails on any other computer than yours), i.e. via POP3/SMTP protocols, and not IMAP ! Right now, and as Wulfie explained, viewer-side MFA login is not enforced by LL's login server, to give time to TPVs to implement MFA (AFAIK all major/well maintained TPVs got it done now) and to users to update to the MFA-enabled versions of the said TPVs, so the person who stole your password did not need MFA authentication to login with any viewer... But your SL web account is still safe.

Thing is, it's been decades I'm no more a kid ! 🤣

I will probably buy an ARM SBC next year... I am waiting for RK3588-based boards to be widely available (and with proper Linux support): this SoC is a little beast, and these boards will have 8GB of RAM or more, making them suitable for running a full-fledged SL viewer. The Banana Pi BPI-W3, for example, looks very promising...

OpenGL is fine with modern ARM64 SoCs under Linux. FMOD is not needed (we have OpenAL support as well under Linux for TPVs, and my build scripts automatically select it for ARM builds). It's good to see a Linden interested in this. It still puzzles me that LL did not yet change their stance about Linux support... You know, mobile platforms are mostly ARM-based, and Linux works very nicely with them, not to mention Android is just ”Linux by Google”, so an Android version of the viewer (with OpenGL ES) should be possible, after LL adapts what TPV devs have done for years for the viewer under Linux... Just imagine the perspectives it would open for a wider SL adoption.

See above...

Yes, I am assuming a PI 4B, here (my viewer no more supports 32 bits builds, especially under Linux, due to crash bugs in modern boost fiber/context 32 bits libraries).

Try the ARM build of the Cool VL Viewer (the corresponding forum thread is here)... No guarantee, but worth a try. You should also be able to build the viewer from its current sources on your Pi (instructions for building are the same as for x86_64 Linux builds, i.e. merely untar the sources, change to the linden/ directory in a terminal, and type ./linux-build.sh)