Henri Beauchamp

See this modest pull request of mine (a one liner fix in LL's code, to fix an EEP-era bug with non-scrolling clouds, and a request for LL to forward the fix to their new ”default mid-day” inventory setting), and see how it suddenly seems to become ”problematic” and how, in the mind of some devels at LL, everything in the environment should suddenly stay put, with any variation (even cloud scrolling) being an ”impairment” for creators.... See, in particular, my last post about the creator-centric streak that has suddenly been taken with PBR, causing grave damage to SL-users experience... I must confess I have been flabbergasted by the reaction ! 😵

Not at all, you'd get 2k textures instead of 1k ones everywhere, because every creator would always upload their highest resolution (2k) textures (and only them: why spending more in uploads and ”wasting” time in selecting the right texture version when building stuff ?) and reuse them for all their builds, whatever the final object size, and whatever the face area on which the texture is applied ! Sure, the viewer is capable of downsizing textures to fit them in VRAM, based on the calculated virtual surface area, but the latter changes with the FOV and when your avatar moves around, or when you cam around, the said surface changes, better level of details are used and the larger versions of the textures are used in VRAM. The result is that, on the network side, you will almost invariably end up downloading the full size texture, and the latter will stay in RAM for as long as even the lowest LOD is used (because the viewer cannot know if, after having cammed closer and then farther to the face bearing that texture, you will not cam close again soon). As a result, you can see viewers eating up easily 24GB or RAM in textures-heavy sims... Just imagine what it would be like with 2k textures occupying 4 times the amount of memory 1K textures are using ! In VRAM, with GL images, things can even go more hectic, because of ”boosted” and ”no delete” GL images, and even after having ceased to render a given texture, it can linger in VRAM forever (this is why you almost invariably see the viewer using more VRAM after even a short session while you returned at your login place and waited patiently for the viewer to expunge all objects and textures, and disconnect from the sims you left). I managed to achieve a better behaviour in the Cool VL Viewer, after many weeks of careful auditing of the code, of redesign of parts of it, and of work around design and implementation for the remaining shortcomings, but while it works well for 1024x1024 textures, even with only 1GB VRAM, it would definitely be at pain with 2k textures (4x the memory consumption).

The first voice viewer was v1.18.2.0. Looking at my archives (*), LL's sources timestamp for this viewer version is 10 August 2007. Since sources were released together with the binaries, the latter have likely been released on this day. (*) I was already developing my private viewer builds based on LL's sources with a set of individual patches added.

Perhaps would it be time to simplify the algorithm (and then document it) until it is comprehensible by a mere mortal... I would personally expect it to work as follow: Objects subject to parcel-auto-return returned first (first rezzed, i.e. closest to the auto-return delay, first returned). Existing ”Locked” objects either owned by the parcel owner or set, or deeded to the parcel group never returned. Existing deeded objects on group parcel never returned (you never know if the account who deeded it will ever log back in again in SL to un-break the mess). Objects set to group parcel returned only after all objects not set to group parcel have been returned (this is relevant to public rezzing parcels without auto-return). Last rezzed, first returned.

Could it be that FS saved the chat in an UTF (8 or 16) format and you are trying to read it with an ISO editor nor recognizing UTF character sets ?... I did not yet have a look at the emoji-viewer(s), but while chat and IM logs have so far used the ISO character set, they might now use UTF-8 (likely) or even UTF-16, so to be able to store the emoji's... The worst case scenario would be a viewer with emoji support that would append UTF-16 text to and existing ISO chat log: the editor you are using could then get mislead into considering the whole file is ISO, and display it as such, and you'd get a nul (0) character interleaved with each ASCII character at the end of your log...

Well, then they made a mistake...

The limit for SL passwords is 16 characters, not 12. If you change your password, there will be a delay (up to 24 hours, IIRC) before it gets propagated to the SL beta grid (Aditi), so you won't be able to log in to Aditi with the new password before the change has propagated there...

TPVs do not use the same cache folders neither the same settings files than SL's viewer: each TPV uses its own private folders for caches and when sharing the same settings folder as SL's viewer (this is the case for my viewer), they use different settings file names. There should be no interaction whatsoever between different viewer ”brands” related to cache and/or settings !

Perhaps are you trying to a simulator which is down in Aditi. Try and log in in Morris: type this sim name in the input line associated with the combo where you select ”My Home”/”My last location”. If this fails, have a look at the viewer log to try and figure out what is going wrong (look for HTTP error messages, warnings, etc). You could also try with a different viewer: sometimes, inventory issues can also cause this sort of failure. The Cool VL Viewer will get you logged in, even with a bad inventory, and once done you can, in the ”Inventory” floater use the ”Consolidate/restore system folders” feature in the ”Folder” menu to repair what is ”broken” (usually a missing system folder or on the contrary duplicate system folders). Then you should be able to log in again with your usual viewer. If all these fail, file a support ticket.

I am sorry to say that your motherboard looks much too weak on the VRM side (1) to run a much more powerful CPU than the one you got... A 9600K(F) might do it, but that's about it. If you are ready to make a big jump and have the money for it, then I'd recommend going for an AM5 platform (a Ryzen 7700X would be perfect), which you will be able to upgrade without changing the motherboard for at least 3 more full years. Of course, it means replacing your DRAM too for DDR5 modules (go straight for 32GB in 2x16GB modules: 6000MT/s modules will do just fine and are not too expensive). You will also need a good CPU cooler. For SL, I recommend (for the present and the future alike), to aim, at the strict minimum, for 12 virtual/SMT cores or 8 full/non SMT cores CPU (with 16 SMT cores preferred), and to avoid hybrid core architectures (Intel's Performance/Economy mix), since the risk is to see the viewer running most of the time on the E cores, performing much worst as a result. While the SL viewers are currently using a single thread for their render pipeline, the modern OpenGL graphics drivers can use a few more threads on their own, which can result in up to 3 SMT cores or 2 full cores being used by the viewer+driver to render, to which you must add the many threads SL viewers can now use for other tasks (some TPVs such as mine can even use several times the amount of threads used by SL's official viewer and occupy all the available CPU cores during rezzing). Also, in the future (one or two years from now), we will eventually get a multi-threaded Vulkan renderer, making multi-cores performances more important than what it might look like right now... As for the SSD, a SATA 3 one will do just fine: NVME ones are over-rated, heat up a lot and are fragile, with a low endurance, and you won't see a difference at all in SL viewer performances. Note that SL uses a cache, with lots and lots of cache writes: those are toxic for the SSDs, so you need one with a very good endurance (2), or you could use a RAM disk for your SL viewer cache... (1) Voltage regulator rails: only 4 seen on the picture, and likely only 3 for the CPU cores themselves, the 4th likely being for the iGPU, which you would not even use... And no heat sink on this motherboard's VRMs... Definitely not a gaming motherboard. (2) QLC (4 bits per cell) and PLC (5 bits per cell) drives are to avoid at all price: way too fragile !... Try and get a MLC (2 bits per cell) or a TLC (3 bits per cell) drive: beware, some brands such as Samsung pretend their drive are MLC ones when they are actually TLC ones: they use the fact ”MLC” was a term invented back when TLC did not yet exist and means ”Multi Level Cell”, which could indeed apply to anything but SLC (Single Level Cell) drives, but should now only be used for 2 bits per cell drives.

It depends on the architecture and ”computer”... When using an ARM64 Single Board Computer (Raspberry Pi & Co, on which the Cool VL Viewer Linux aarch64 releases can run), then you are stuck with OpenGL 3.x and even then, not even fully debugged: most SBCs won't be able to do deferred rendering, for example, due to bugs in the current Mali GPU drivers (so, forget about PBR and even ALM: it's forward mode or nothing)... 😛 But yes, for x86_64 platforms, the minimum requirements as listed by LL are totally outdated and even plain silly (32 bits for Linux ?... 🤪 Nope, not any more !!!).

If you really want to compare the rendering speeds, you must use equivalent (and actually equal, whenever possible) settings, else you compare pears with apples. There is no reflection in the old renderer, so you must disable the latter in the new one (PBR reflections tax a lot the CPU when enabled, and cause a large decrease in frame rates): in the PBR viewer, un-tick ”Screen space reflections”, set ”Reflection detail” to ”Static only” and ”Reflection coverage” to ”None”. On the other hand, PBR does not have proper water reflections, so be sure to set the old viewer water reflections to ”None (transparent)” (or ”Minimal” for some TPVs). In LL's viewers, be careful with LOD settings (IIRC, they increased the maximum value for the slider corresponding to the RenderVolumeLODFactor, in the PBR viewer): check/set them from the debug settings to be sure (type ”LOD” in the search line, and set all settings it finds to the same value between viewers). Yes, there is something fishy with the PBR renderer (my (wild) guess is that it has something to do with occlusions during rezzing) and sometimes, after login, it renders at a lower rate a scene that it renders faster after a TP away/back in. I can see this too in the Cool VL Viewer (which can render in all three forward, ALM/deferred and PBR modes) by not even moving but just toggling PBR off and then back on (with CTRL ALT P), after which the fps rate significantly increases. The PBR viewer got quite a few optimizations in the underlying code (code that exists in both viewers), such as with the vertex buffers (now cached when possible), the VBO pools (with a much more efficient management code), and the avatars' matrix palettes uploading to the shaders (with the legacy code, they used to be uploaded pointlessly, sometimes several times per frame, while already uploaded). The Cool VL Viewer got all these optimizations backported, so they benefit all three rendering modes (forward/ALM/PBR) alike; if you want to measure the impact of the PBR shaders and render pipeline alone, this is a better viewer to perform your tests (and this is where you see the actual impact on old hardware). All in all, and with all settings at equal values (i.e. with reflections off for PBR, and water reflections off for ALM/forward), the PBR renderer is not slower than the ALM one, and sometimes even faster than the latter on modern hardware. However, if you want to benefit from all the new shinies (pun intended), such as reflections, you will see lower frame rates, even on modern hardware. There is always a trade-off for new features: no free lunch ! As for the stuttering you mention, this is likely due to the new way the PBR viewer manages the VRAM usage for textures (LL's algorithm causes the VRAM to fill up to the brim, with vertex buffers and GL textures spilling out to the RAM as a result as soon as you turn the camera around and get new stuff rezzed while VRAM is already full); the Cool VL Viewer does not use this new code (but instead the old texture discard bias method with a rewritten and refined algorithm) and won't suffer from this kind of stuttering/freezes.

You can see diffuse texture and legacy material maps rendered on the face by simply toggling off the PBR renderer, e.g with CTRL ALT P. For legacy materials, also make sure Deferred rendering/ALM is on, the toggle being CTRL ALT D. Render modes toggling happens instantly (provided you already toggled it once in a former session or the current one, and your graphics driver is properly configured to cache compiled shaders), so you can do this a gazillion of times during edits, if needed. 😉 Also, you can apply all three (and in whatever order suits you): diffuse texture (used in forward mode), diffuse + normal/specular (used in ALM) and PBR material, all to the same face: this way, it will render just fine and as you intend it to render, with any viewer. Finally, you can remove materials from the edited face(s) (both ALM and PBR) via the ”Reset materials” button, which would leave you with just the diffuse texture on the edited faces.

By basically destroying the said settings, yes... E.g. you currently need to turn the ”blue horizon” one into a... pink horizon ! The problem is that the current shaders are totally bogus and account way too much for blue horizon/blue haze, and anything shiny and not shielded from the sky by a reflection probe will render blue (which is totally unrealistic: I never ever saw this happening in RL, even under a cloud less sky at midday !). LL needs to fix this, but the time they take to fix it, there will be plenty of ”workarounds” in use in SL, among which hacked/destroyed EE settings that will need to be changed again once the fix is implemented ! LL really messed it up BIG TIME by pushing PBR to release while it was not even of beta quality and still full of render ”glitches” (to say the least), such as non-working water reflections, ugly and toonish blue-sky water bodies, broken semi-transparent legacy faces, etc, etc... 🙀

If you did not overclock it, then it might be the sign of overheating (cleanup your computer fans and heat-sinks), or of a hardware failure. Some browsers will use hardware acceleration (the GPU), and others not... Safari might not be using it (or not be configured to use it)...

Did you overclock your GPU or VRAM ?... This is typically what you would see when pushing frequencies a bit too high, but not quite high enough to crash it. The fact it won't appear when using the GPU for something else (Youtube uses the GPU video decoder) might be due to the fact that, in this case, the GPU would throttle its frequency... Also try and stress your GPU/VRAM with some test software, such as Furmark & Co and see if it reproduces the problem.

The Cool VL Viewer currently can render in all three Extended Environment (EE) forward (legacy) mode, EE Advanced Lighting Model (ALM) deferred mode, and Physically Based Rendering (PBR) mode. You can switch instantly between the three rendering modes (CTRL ALT P to toggle PBR on/off, CTRL ALT D to toggle Deferred/ALM on/off when not in PBR mode) and use the one that suits you for your current activity: forward is by far the best for sailing, flying and outdoor scenes in main land, ALM is best for legacy contents rendering with materials, such as clubs with lots of shinnies and venues with lots of avatars using legacy material on their meshes that would otherwise appear blueish with PBR, and PBR is required to properly render new shinnies using it (even though, the Cool VL Viewer also offers a hack to allow rendering a coarse approximation of PBR-only contents in legacy modes: see the ”Advanced” -> ”Rendering” -> ”Deferred rendering” menu and the explanatory post on the support forum). As for EE settings, it defaults, in PBR mode, to NOT auto-adjust legacy settings to HDR tone mapping: the toggle for the latter setting is in the ”World” -> ”Environment settings” menu. It also uses fixed ”Midday” settings with clouds that do look as they used to in WL viewers (i.e. with a proper clouds scale) and do properly scroll with the wind, instead of staying still like in LL's bogus viewer (I reported that bug to LL countless times, but they never fixed the typo in their code and the consequently wrong setting value in their Midday EE settings in their inventory database 🙄 ).

Actually, the lighter the rendering load, and the hotter the GPU will become when the viewer is left running without limiting the frame rate (which can then skyrocket and since the consumed energy, measured in joules, will be about the same for each frame in a given scene, increasing the number of frames per second just heats thing up proportionally). E.g., in a sky box (where there is almost nothing to render) on a modern desktop PC, my viewer can render at up to a ludicrous 1500fps, and then the fans roar, the GPU hitting its maximum power consumption. The true solution is to use the frame rate limiter (most TPVs got one). When the viewer does not provide one such limiter (e.g. for the official viewer), you may enable VSync (which will sadly degrade overall performances and cause frame rate stuttering, making SL feel much less ”smooth”).

This won't change a thing either about how your traffic is routed between your PC and SL servers... So no, this too is useless, unless your ISP-provided router/Internet-box is crashed.

Did you enable the ”Advanced” -> ”Network” -> ”TP race workaround” feature ? It helps a lot avoiding this issue. Note also that restarting your PC won't change a thing: it is a race condition between the server and the viewer: LL is aware of it and working on it. See this thread for all the gory details (warning: highly technical stuff ahead !). Depending on the routers between your PC and SL servers, things can be ”better or worst than usual”...

I actually think every topic is fine, as long as it is exposed by the original poster in a levelheaded way. You can have opinions (including strong ones) while respecting the opinion of others... Of course, if your text is sententious or disrespectful, you will likely start a flame war, but this is true for any topic. I suppose even a ”cutest cats” topic could turn into a flame war, this way: my cat is cutest than yours would be a good start ! 🤣

This is indeed a trick ”we” use a lot, and not only for this capability... And yes, it is utterly fragile and hacky: at some point, I reused this capability caching for server side baking (to work around another server bug which causes attachments to be unparented (derezzed) as a consequence of the departure region sending such a bogus unparenting message for the agent's own attachments), and while it first worked fine, it finally broke later on (details explained here)...

I think you meant Cool VL Viewer (as I explained in the above post)... You keep confusing the two viewers names (you already did in your Canny issue), which is strange... 🤪

CTRL ALT SHIFT H prints ”Hippos!” in chat with almost all viewers (not mine, since I reused that shortcut for something more useful)... 🤪

I myself live on Mars with a Buggalo named Beetlejuice. 🤣