Henri Beauchamp

And its existing contents, created by the said user base. The amount of assets in SL is enormous (even if half of it is crap), and no other virtual world can compete with that any more... The drawback is that each time LL wants to improve SL, they must take into account legacy contents to avoid breaking it at all price (and I wish they had been more careful with PBR before pushing the latter to release: it still does not render legacy contents properly, for now). This of course ”holds back” SL quite a bit and causes added complexity to the render engine, database, scripting engine, etc... But like you said, starting from scratch with state of the art renderer and contents, like LL tried to do with Sansar, is bound to failure: it would be a bottomless money sink for the company before it would even reach a tenth of what SL is today.

I claim the first move on BOOL-eradication (almost 10 years already I removed them all from my viewer sources) ! 😛

This is typical to the Win10/11 ”rounding up sleep time bug” I described above...

We could patch libcurl (it's already a patched version that is statically linked against the viewer binary, anyway) to insert a hook in its code and recover the decyphered data...

Add a pointer to my message then. 😉

This rings a bell... There is an issue with Win10 (excepted early, now long deprecated versions) and Win11, due to how timers are implemented in them: they basically ”round up” sleep delays, causing such issues. I had to implement a workaround in the Cool VL Viewer for this: see linden/indra/llcommon/llsys.* files in sources, ”inaccurateSleep()” method, ”mInaccurateSleep” boolean and the timeBeginPeriod() Win API calls as a workaround. I just 'grep'ed the last FS' sources I got for ”timeBeginPeriod” but found no occurrence of this necessary workaround... You should report this issue via the FS JIRA and point them to this message.

Yup, totally a Windows thing... Linux viewers are started via a wrapper script, which (normally) takes care of setting everything up for you via environment variables (those can control the Vsync settings, driver threading, etc). The Cool VL Viewer also offers you an easy way to configure those settings yourself, either on a per-installation, per-user, or system-wide level (see the ”cool_vl_viewer.conf” file in the installation directory).

Unlike LL's official viewer, TPVs usually offer a frame limiter which is much more fine-grained than what you can achieve with (any) vertical sync: Vsync basically holds on the GL API calls by the CPU until the next frame is ready to be displayed on the monitor, which causes ”stutter” when your frame renders in a little bit more of time than the refresh rate of your monitor allows (i.e. if your system can render a scene only at 59fps and your monitor syncs at 60Hz, you will most often have two frames rendered properly in 1/60s, then the next frame will have to wait for 2/60s = 1/30s which translates in 30fps; since a frame must be displayed in-between nonetheless, the previous frame is displayed, causing a ”stutter”). This is why you should never, ever use Vsync (or Gsync, or FreeSync: those are slightly better since more fine-grained, but will still cause stutter at low fps rates), when the viewer offers a frame limiting of its own: your thermals will be just as good with the latter as with Vsync, but without stuttering issues. Also, during this delay, introduced by the graphics card driver, the CPU is ”stuck” and cannot perform other useful things it could otherwise perform during this frame (such as decoding textures or launching HTTP requests for new textures, etc). A proper frame rate limiter instead sleeps the CPU after everything it could do during that frame has been done, and only when there is some time left before the next frame needs to be rendered (thus respecting the frame rate limitation you impose to it). Because I implemented a ”smart” frame rate limiter in it. Other TPVs only sleep the CPU for the remaining time when a frame renders ”too fast” for the frame limit you impose, while my algorithm will sleep it when nothing else useful can be performed, such as reevaluating textures priority, decoding more textures, processing more UDP messages from the server, yielding to coroutines, etc. The CPU is kept slightly busier, but things will rez way faster (even faster than without frame limiting, because instead of pointlessly rendering frames that the monitor won't even be able to display in time, the viewer then uses this time to rez more objects and textures). FS uses a custom profile, and force-enables it. Other viewers may let you decide (this is the case of the Cool VL Viewer). If you keep that setting on ”Auto”, the driver may decide to let threading optimizations OFF, depending on battery level or other considerations, and then you would loose half of the frame rates you would get with that setting set to ON.

With TPVs providing a frame limiter (not just V-sync like LL's), you should keep all forms of vertical sync (V-sync, G-sync, FreeSync) OFF, and use the viewer frame limiter instead (it will cause less stutter in frame rates, in particular, and with the Cool VL Viewer it will reduce your rezzing time). Also, you should keep Triple buffering ON, to prevent any tearing while vertical sync is off (it will not cause any slow down). Finally, you should force Threaded optimization to ON (FS will likely override it to ON anyway, via its own NVIDIA profile), else you loose 50% or more in frame rates !

It depends on what the script is doing. For example, it could open a listening private channel, and if some other script in the region is posting to that channel, the text will consume stack space (and maybe heap space, if the script stores it in some variable) in the listening script... Without the script sources, it is hard to tell what is ”normal” or not.

Don't let Niran see it either ! 🤣

In C++ viewers, we use libcurl, which ”silently” retries such 500 errors (basically re-posting the same poll to the server, but unknown from the viewer code itself). If I were you, I'd implement a 26s timeout in Sharpview for event polls in SL, like I did to fight TP race conditions (also due to the tearing and retrying of the poll due to the server error message). See my former messages about it in this thread, and the Cool VL Viewer code (in lleventpoll.cpp, mostly, for the event poll timeout and restart parts, but also llvieweregion.cpp, llviewerdisplay.cpp and llagent.cpp for the TP race workaround itself).

Deleting SLVersionChecker.exe from the installation directory will prevent auto-updates to get triggered (the viewer will complain it can't start it, but will still keep running nonetheless); however, after LL blocks this version at their login server level, it won't allow you to login any more.

There are more options in the ”Preferences” floater, ”Cool features” tab, ”Misc.” sub-tab: ”Always render known close ban walls regardless of collision risks” check box and ”Ban walls maximum rendering distance” spinner. Do read the explanatory (and long) tool tips for these too... I advocated, several times, during the Server User Group meetings, for getting a capability that would allow the viewer to request all ban lines in a given region (agent region or neighbouring ones alike), so that the viewer could draw the walls when you need them and draw the forbidden parcels in the mini-map, without having to wait after the server to send you that info (which often comes too late, especially when driving/sailing/flying). But so far, this went into deaf ears, sadly...

Real life users (and an indeterminate number of sub-groups for them). Traffic bots.

Gets this into your head: Not everyone can afford one month worth of their salary or revenue to buy a new computer and keep playing in SL (and SL cannot afford loosing these residents either since it just barely survives with its current user base). Some people (I am in this case), while owning quite capable hardware to render in PBR mode, just find the current state of the PBR renderer unacceptable so much it ruins their SL experience with totally f*cked up legacy contents rendering, ugly waters, etc. The consequence of the above points is that there will be a transition period, before the renderer is fully fixed (which will hopefully only take a few months: the less, the better), and everyone can use PBR (speaking from experience, with the transition to Windlight (v1.19 to v1.20+) which had a similar impact on ”old” hardware, this will take about 18 months). As a creator, to adapt yourself to this transition, you could offer your customers a choice (or risk seeing diminishing sales). As a TPV developer (and eager early adopter, but also someone not making any concession when I see regressions), I already adapted to try and keep as many SLers using SL, by offering them a choice. This is my last message about this subject in this thread, because we derived a lot from its original topic and I do not want to pollute it more than already done.

Singling out random SLers is not the best way for creators to gain a good reputation... And I would not single anyone, just blacklist textures which would ruin rendering for people not able/willing to use a PBR viewer: these textures would simply be replaced with a blank one, or with the base color one (my viewer can do that too, when not rendering in PBR mode). PBR adoption would have been wider and easier, if only the PBR viewer had not been pushed too soon to release, especially with bad legacy contents rendering... It's LL's fault, not yours or mine; and I did tell them but they did not listen... They will perfectly know that they will encounter PBR contents without a proper fallback, but they will certainly think that you are just too lazy to apply your base color texture as a diffuse texture if you ever recourse to the ”OUTDATED VIEWER” texture... This kind of behaviour is akin to ostracizing people and will just make them feel miserable (especially people who cannot afford updating their potato computer to enjoy your marvelous PBR shinies, instead being reminded by your ugly texture that they are not rich enough for this). By ”possible fallback”, I meant something that would render a mesh, not just a cube. With PBR contents, you *can*, as a creator, keep making stuff that will not render like sh*t during the transition period that will be necessary for everyone to adopt PBR: fallback exists and is quite acceptable.

I might blacklist the UUID of that texture (and any other such textures) in my viewer, so that people who cannot or do not want to use PBR just now (for whatever reason, but the main reason being that it is still very much in beta state, and this until LL fixes PBR properly) will not see it... If you do not want to be bothered with ”outdated” viewers for your new builds, simply set the diffuse texture to be the same as your PBR material ”base color” one: it will not be perfect but, at least, your products will not look revoltingly ugly to people who do not use PBR. ”Same”, really ?!? 😵 When it got rolled out, mesh did not ruin legacy contents and environment rendering (e.g. ugly PBR water vs gorgeous Windlight water). Also, it did not impact performances in existing scenes on old hardware (1). What you did back then was therefore very different from what you intend to do now: back then you merely ”informed” people about the use of a deprecated viewer (2), while now you would slap in their face for refusing to use a beta-quality viewer ! Just please, don't do this... ---- (1) Even if, over years, the addition of many unoptimized meshes did impact new scenes with them, for everyone and whatever the hardware. (2) And there was no possible fallback for mesh rendering in old viewers, unlike what PBR allows, since legacy diffuse texture and material can still be applied to a PBR face.

This is normal, if you got the ”BackgroundYieldTime” debug setting set to anything else than zero and the SL viewer window is not the foreground window (*). This setting defaults to 40, which means sleeping for 40ms after each frame has rendered (translating into 25fps at best when not in foreground with a super-light render scene such as in a sky box). Simply set this setting to 0 to keep rendering at full speed. ---- (*) Or more exactly, when it does not have the focus, since some window managers allow to focus a window in the background of another: you may achieve this with the hidden Xmouse feature under Windows: set ”focus follow mouse” on and keep ”auto raise window” off; as long as you do not click in the background window, it will not be raised to the foreground but will keep the focus nonetheless. With smarter window managers (such as most Linux ones), you may also disable the ”raise window on click” and keep working in the background window while still seeing what happens in another, smaller overlapping window.

For me, as a ”foreign” (non-native English ”speaking”) user, it is an impairment. While I write and understand written English just fine, I do not understand half of spoken English (and even less when spoken with some weird accent, through a microphone with saturation and statics, with background noise, being at the speaker level, or in my own environment). Equally, I speak English in such a poor way, that nobody would understand half of what I would say. I hate meetings held on voice and, in fact, I do not even bother attending them (which would be a total loss of my time).

It looks like it does not come ”alone”: here is what VirusTotal thinks of it. Granted, this could be a false positive (this won't be the first time), but since no one knows about this viewer, and the web site does not even provide a link to the sources, I would advise anyone wishing to give it a shot to be extra-careful (use Wine under Linux, for example, in a custom ”Wine prefix” and not as 'root', of course).

The green boat was also missing on login: I right-clicked on it to get it to appear, but forgot the two boats on the right... The Cool VL Viewer was not impacted, because it got a workaround for this years-old bug (race condition between interest list sending by the sim and spatial partitions rebuilds in the viewer renderer)... Here is what the scene looks like in the Cool VL Viewer, with PBR mode on: Note how the water is a bit less ”sky blue” (I hacked the water shader for this).

IMHO, this is terribly pedant a way to treat people who cannot afford updating their hardware instantly, and to people who prefer to see legacy contents rendering properly, instead of being ruined by the currently broken PBR shaders: yes, this will get fixed, in the end, but there will be an interim/transitory phase during which not everyone will run a PBR viewer. Well, about ”eye candy-ness”, let me show you a simple outdoor scene, taken with LL's current PBR viewer (v7.1.2) and with a non-PBR viewer (*) and, shockingly, in forward (non-ALM) rendering mode ! PBR: Legacy: Question: which one is more ”eye candy” ?... Yes, in its current state, the PBR renderer sucks rocks at rendering legacy contents (and water bodies even more)... Yes, it will (hopefully soon) get fixed over time, but no, creators cannot yet consider that everyone will be using a PBR viewer every time and everywhere for now (and, I would bet, not before a couple years has elapsed from now). (*) In fact, with the Cool VL Viewer, which can do PBR rendering, but here switched to the legacy forward renderer. FS or any other non-PBR viewer would render the exact same way in this mode.

I have been using many CPU brands, and to speak only about the x86 CPUs, in the past I used Intel, Cyrix and AMD, in this order. I am not a fan of any brand, and I simply pick up the best choice I can find at the moment I upgrade my PC (or build a new one), this choice being governed by both the best performance/price ratio, and the best suitability for my various usages (which go way beyond SLing, of course). For SL, I have been using Athlons (XP, 64), a Core2 Quad, Core CPUs (Sandy Bridge, Coffee Lake), and I am currently using a Ryzen 7900X. In the early 2000s, AMD CPUs were the best choice (faster), then Bulldozer ruined it for AMD, and I switched to Intel (with the Core2 Quad) and Intel CPUs have been the best choice for SL during a looong time... Yet, with Zen4, AMD is back on par with Intel for performances, and superior to Intel in term of power consumption (important, since the more power consumed, the more heat to dissipate, the bigger and the noisier the cooling system); Zen4 is also not impaired by the P/E cores split (yuck !) seen in Intel's current CPUs... I therefore chose AMD, with a Ryzen 7900X, for my last PC, and I do not regret it the least !... Despite the heavy threading in my viewer (Cool VL Viewer configured to decode textures with 22 threads and create them in 22 other shared GL contexts/threads, adding to the 2 threads for the renderer and the graphics driver, plus miscellaneous other threads, such as for the texture fetcher, the texture cache, the object cache, sounds, plugins, etc), the CPU is never loaded at 100% (or only for a few seconds after a TP or login in a render-heavy sim with gazillions textures and meshes): it runs cool and quiet ! The Ryzen 7900X is also a beast to compile big programs (with it, the Cool VL Viewer compiles in less than 165s under Linux, which is 2.7 times faster than with my previous overclocked Core-i7 9700K @ 5GHz). Note that with any of the modern CPUs (those capable of 5 GHz and higher boost clocks), you will likely not notice the slightest difference in peak frame rates, but for a smooth experience, do choose a CPU with 16 or more (virtual) cores (today's viewers can use quite a few threads, and future viewers will use even more of them).

Normally, EstablishAgentCommunication for a neighbouring sim is sent when your avatar camera FOV crosses that region's border. Maybe your viewer is not sending the data (agent position, draw distance, camera axis) the agent region is expecting to send the EstablishAgentCommunication for its neighbours... On login, you could try and send two sets of data: agent position at the center of the sim, draw distance at 384m or so, camera axis pointing alternatively North West and South East, and see what happens...