Henri Beauchamp

The more you load the GPU, the less the optimizations that went into the C++ code (i.e. CPU side) are noticeable. However, once all settings set at equal values (*) the Cool VL Viewer will never perform worst than others just because you turn shadows on in them all. (*) Careful about the default FOV of the camera, for example, which is different in my viewer and which, instead of making you looking a bit down at the ground, makes you look parallel to the ground, causing more objects to be encompassed in your FOV (more objects to render, more textures loaded). There are also other settings added to improve how the world looks, but impact frame rates (e.g. mesh objects boost factor, Linden tree LODs at 3.0 instead of 1.0, higher LOD textures, etc). Also, for shadows, some settings (only accessible via the debug settings) have been changed to give better shadows (they now match what LL's PBR viewer is using), so shadows are indeed costlier with them...

Well, yes, there is a VRAM ”leak” in (almost) all viewers, due to how LOD-boosted textures are made ”no delete” by the viewer, meaning you will accumulate them over time and they will occupy uselessly some RAM and a lot of VRAM. To see it in action: log in (preferably in a sky box to consume as little VRAM as possible), check the VRAM and GL bound textures usage in the texture console (CTRL SHIFT 3), then TP to a busy club or venue; wait for everything to rez and return to your login location, wait 3 minutes for the sims to disconnect and the textures to get cleaned up from memory, then check again the texture console: the numbers will be (sometimes much) higher... The ”almost” above is because I worked around this in the Cool VL Viewer by: Using more sparingly the ”no delete” attribute (i.e. only where it is actually needed, such as for UI textures or sculpty textures). Implementing a force-cleanup algorithm for boosted textures that have not been used in a while.

You forgot the Cool VL Viewer... 😜 The current viewers all share the same characteristic: they use a mono-threaded renderer, meaning you basically get limited by the performance of a single CPU core (with the exception of very simple scenes, such as in a skybox, where the CPU will be fast enough to saturate the GPU itself: with the Cool VL Viewer, on a Ryzen 7900X and RTX 3070, I top up at 1500fps in my sky box, at which point the GPU is 100% loaded). Also, your GPU is not really a good performer for OpenGL (AMD OpenGL drivers suck rocks), and you'd get +30 to +50% in performances with an equivalent NVIDIA card. One thing some viewers can do, is to use more threads while rezzing scenes to fetch, cache and decode meshes and textures faster: with the Cool VL Viewer, you may configure a multi-threaded GL image thread, for example, and it will by default use as many threads as your CPU got (virtual) cores (minus two, reserved for the mono-threaded renderer and the GPU driver threads, when it can and is configured to use threads) to decode textures.

Precisely no ! If I don't use it permanently, it is just by choice, because forward rendering provides a nicer picture and/or larger draw distances for the same memory consumption. My hardware can handle everything you could throw at it: Ryzen 7900X + 64GB DDR5 6200 + RTX 3070, and I got a 1Gbps downlink/700Mbps uplink FTTH Internet connection.

Over years, SL became much more demanding on PC power, which is, in fact, totally normal (likewise, you won't play today's AAA games on PC built 15 years ago)... For today's SLing, 16GB of RAM is barely enough, and 32GB is recommended. The main ”culprits” are meshes (and ”onion-layered” rigged meshes especially) and materials (3 textures per face instead of just one: and PBR will push that further to 4 textures per face). No, it won't change a single byte in memory usage, but yes, it does help to keep PCs cool and quiet: it does not make much sense to render at frame rates way over your monitor vertical refresh rate (which is commonly among 60, 120 or 144Hz, depending on your monitor), and doing so causes excessive/useless power consumption and totally superfluous heating (with the corresponding very large noise increase due to fan spinning much faster). So, using a frame rate limiting is indeed a good idea... Provided your viewer is ”properly coded” in this respect. If it only allows VSync limiting, then you are out of luck, since it will cause large variations (”hiccups”) in frame rates like 60 to 30fps for a 60Hz monitor and a frame render time varying around 1/60 of a second (if a frame renders in 1/59 of a second, the VSync bit will cause the GPU driver to delay the return from the frame swap OpenGL call by the CPU till next frame and you will get a drop from 60 to 30fps for that frame). FS is using a varying sleep() call instead (i.e., when a frame renders ”too fast”, it just sleeps the CPU for the remaining time before the total time is 1/60s of a second, or whatever rate you configured it for), which is better, but not ideal either: it avoids the fps ”hiccups”, but slows down the UDP messages, textures and mesh decoding tasks (which are updated by the viewer main thread, which also happens to be the render thread). For the Cool VL Viewer, I instead implemented a ”smart” limiter: when there is ”some time left” before starting to render the next frame, it uses that time to decode more stuff, and only after all the queued tasks are finished, does it sleep the CPU. With this algorithm, the viewer rezzes even faster than without frame limiting (because the time spent to uselessly render frames that your monitor would never display is instead spent decoding and updating stuff).

Feel free to open the JIRA you like, and let people decide via votes... 😜 The opt-out was just a suggestion for a minimal solution to the ”badge issue”; I would, too, prefer an opt-in, but I find the removal a bit of an extreme measure (some people do like it: let's them enjoy it !). I believe in giving everyone a choice (freedom !).

Sadly, your poll will not bear any meaningful result. The reason is that, aside from people with a ”weak” PC (no discrete GPU, 8GB or less RAM, quad core or less CPU), and for whom there is no real choice to run SL at decent frame rates (on such hardware forward rendering offers +50% to +100% fps, even when compared to the PBR renderer with all reflections off), everyone can use ALM, and will do so in some specific circumstances (e.g. avatars around wearing materials-enabled meshes that won't render ”as intended” by the creator in forward rendering mode). I myself got a very powerful main PC, and yet there are many times when I do use the forward rendering mode instead of ALM. The reasons for not using ALM are: The anti-aliasing in ALM sucks rocks: the FXAA shader is terrible and blurs details in textures (example) instead of just smoothing jagged prim edges. I did implement SMAA (a backport from Alchemy's) in the Cool VL Viewer, and yet, even with SMAA, things do not look as good in many scenes (e.g. ”wobbling” edges). See the examples I gave in this post (follow the links to the pictures and video, which are still valid). The memory usage (RAM, but most importantly, VRAM) in ALM mode is much higher, meaning that you cannot always use the largest draw distances, which is a bother when, for example, sailing along main land coasts or flying above main land, when you need 512m to see where you are going ! While, on a powerful PC such as mine, ALM most often performs just as good in term of frame rates, or even slightly better than forward rendering in some specific scenes, the other way around is also true, especially when ALM fills up your VRAM and you are moving or camming around, which causes VRAM memory usage overshoots (the GPU driver then spills vertex buffers and textures over to the RAM, with an enormous amount of data exchanged through the PCI bus, causing the ”freezes” and ”hiccups”). As you can see, there are reasons for not using ALM, depending on circumstances (i.e. it's not just about the PC power): I use ALM where it makes sense (e.g. in a club of venue with avatars wearing materials-enabled meshes or attachments, or in a scenic sim making use of materials), and forward rendering where it is needed (sailing, flying, driving on roads in main land) and where materials are either rare or too far away to even notice. @Jules Catlyn If I were you, I'd add an answer to your poll: ”Not always”. Or even better yet, make another poll asking when and why people are not using ALM... As for myself, I decided to keep supporting the forward rendering mode in the Cool VL Viewer even after PBR will be released (you may already get a preview with my dual-renderer experimental branch v1.31.0) : it will take time for PBR materials to spread over the grid, and even after it will have spread, just like with current materials, there will still be places where using PBR rendering won't make much sense, especially when you get better results with the forward renderer. Until things get ”fixed” (anti-aliasing, VRAM usage, tone mapping for PBR vs legacy contents), I will provide a choice for people to use whichever rendering mode fits best their needs depending on the various circumstances...

+1 Did anyone open a JIRA for this (e.g. asking for an opt-out setting) ?... If yes, then publish the link in this thread, and people can vote for it, and the said JIRA could be used in future user group meetings to have the Lindens look at it seriously. I doubt this feature is part of a big plan to expose more private data about residents. It is most likely something about trying to ”reward” paying account holders with a cool badge (a medal ?) for them to show off publicly, as well as to incite non-paying members to ”join the club”. So far, LL has always been very respectful of residents' privacy, and reinstated (via Lab Gabs and meetings at SL20B, for example) their commitment in this respect; so I simply think they overlooked the consequences of this little badge for privacy-minded residents.

This amount of RAM usage is in no way ”exceptional”, especially when you push the ”texture memory” slider to the right (increasing both RAM and VRAM usage in the process): each texture in VRAM got two copies in RAM and if your viewer uses , say, 6GB of VRAM for textures, it will use about 9GB of RAM just for the ”raw” and ”decoded” copies. Then, you must add the meshes data, the vertex buffers, the objects data, etc, etc... Yes, this is part of the reason (avatars are very taxing on VRAM and RAM usage, since a modern avatar will wear one or several rigged meshes and many attachments, with materials, high resolution textures, etc). Draw distance also plays a big role (the number of objects rendered and thus loaded in memory typically increases as the squared value of the DD). Normally, and after waiting for the departure and neighbours sims to disconnect and the associated textures to unload (watch the number in the texture console: CTRL SHIFT 3), your viewer RAM (and VRAM) usage should decrease to return to, almost, the same value as when you started it (almost, because there are some things the viewer will keep in memory until you log out, such as mesh headers). For FS under Linux, I'd say it should return to 3GB or less. Reduce the amount of ”texture memory” (for the current FS release, it means turning off the ”Dynamic texture memory” setting and using the slider to set the amount manually). Sadly, it also means you will get lower resolution textures. Another thing you can do is reducing the draw distance, provided all avatars are not concentrated in a small area (in which case, it won't help).

Just as crappy as closing your tab in your browser because the server returns a 404 or 502, or simply never finishes loading the page... But I'm done with trying to explain to nonsensical persons... Have a nice day !

You obviously not have the slightest idea about how a web browser and a viewer are programmed... For a start, the first is non-real-time (and will retry connections as need be: but you still can get 404 or 502 errors, and no way to view the web page, having no other choice than closing the tab), the second is real time and must exchange data with the server so that everyone sees the same thing in the sim. It's like comparing apples and cucumbers... Sure, they are both of the vegetal kind and are both comestible... 🤣 And no, it's not the viewer fault: it's a problem with the TP protocol itself (which lacks a proper handshaking between the departure sim server, the viewer and the arrival sim server).

No, that's a disconnection (and the first dialog is not even that: you can still retry a TP, preferably from another sim since the failure is likely a server to server communication issue); the viewer is still running (normally in the first case, disconnected in the second). Sorry, but it you make up your own dictionary, changing the meaning of the words, don't be surprised if people find your stance nonsensical.

Since Havok is not Open Source, the Cool VL Viewer is using HACD (the oldest version from 2011, since the newer one does not perform as good): amusingly, the results are actually much better than Havok's despite the lack of a ”simplification” step...

There are already settings such as ”show in search” to preserve the privacy of people minding it: I do not see why LL won't be able to add a similar option for the displaying of the account type (since this info is transmitted by the servers, it is fully under LL's control, just like for ”show in search”). Then, people would be left a choice whether to opt out or not. Since this info is totally irrelevant to how people use SL (unlike the ”Show in search” option which is yet already implemented), I do not see how it would hurt to offer every resident (not just the lifetime Premium Plus holders, but also Premium, Premium Plus, etc) a choice in what info about them is disclosed to other SLers.

One of the few ”features” I do not plan to backport to the Cool VL Viewer (just ”Payment info used” displayed in the profiles, but nothing about the account type). At the very least, an option in your account web page (akin to the ”email settings” page) should allow you to opt out this ”feature”... @Fionalein if I were you, I'd open a JIRA issue for this.

Apparently, they just reverted RC BlueSteel to the former version (my home region just got restarted)... Bug in new BlueSteel ?

This exists in the Cool VL Viewer. You can right click on an avatar and select in the pie menu ”More>” and ”Refresh” to get the viewer to force-reload all textures and rigged meshes for that avatar. However it won't help when a mesh or texture fails to download at all (e.g. with 404 error due to the corresponding asset gone missing on the CDN server), or for avatars which UDP appearance message packets are incomplete (usually due to a missing mandatory wearable, or something in that vein: this is logged by the viewer when it happens). There is also the ”Refresh visibility of objects” (ALT SHIFT R) feature, to make objects failing to render pop back up into existence; this feature is also auto-triggered on login and on sim change, since these often cause such ”missing objects” due to a race condition between the server interest list updates, the viewer FOV updates (the interest list contents sent by the server depends on the FOV sent by the viewer), and the render pipeline spatial groups rebuilds. In the same vein, you can force-reload all textures for an object by selecting it (right click or edit) and using CTRL SHIFT U: this may help with blurry or corrupted textures.

For attachments, this is because any change to them is only committed to the inventory database when you either: detach them, TP away, cross a sim border, or logout cleanly. Note that I won't complain the least about this state of affair, because it got the very nice corollary to permit ”undoing” any changes to your attachments when you edit them and badly mess-up; in this case, simply copy the attached item in your inventory and paste it (LL forbids copy of attachments in their own viewer, but AFAIK, all TPVs allow it): the pasted item will have all the changes ”reverted” (actually unsaved) and you can then detach and delete the crippled item, and wear the ”reverted” copy instead... However, this means that in case of a real crash (and most often on spurious disconnections as well), your attachments state changes will be unsaved and you will find them back in the state they used to be on the last login, wearing, successful TP, or sim border crossing (whichever occurred last). On spurious disconnection I however noticed that, on next login, you often find your avatar moved back to the last successful login/TP sim, instead of inside the sim where you got logged out: I would definitely consider this a bug in LL's avatar ”presence” management/tracking, and unlike the above ”attachment reversal bug/feature”, I find it an annoyance (especially if you changed your avatar's outfit in the mean time, and the latter does not match the maturity level of the sim where you get logged back in). Well, a viewer should never crash on bogus/stale data reading, even during a login after a spurious disconnection... Even in this case, you should understand why the crash happened and fix it (which is, of course, much harder than for crashes happening in a simple, reproducible way)... Over the 16 years I thoroughly polished LL's code to make it ”mine”, I took great care, in my viewer, to sanitize every place where such a bogus data processing could lead to a crash. My principle is that a ”release quality” software should simply never, ever crash: if something unexpected happens, you must, as a programmer, still find a safe and sane path to handle the issue and minimize the consequences (e.g., for the viewer, a render glitch would be acceptable, as long as there is a suitable warning logged, so that this ”unexpected” issue can be further diagnosed and dealt with properly, and also as long as the viewer does not crash but keeps ”happily” chugging along). If you are curious enough, try this command line on my viewer sources: grep -ri Paranoia linden/indra/* | wc -l This will currently report 513 matching sites for the release branch, and 542 for the experimental (PBR+EE) branch... These sites are all the places where I added a check to avoid a crash and provided a suitable fallback path for ”unexpected” situations, and for which I added a ”// Paranoia” comment to them (but I did not always added a comment, especially 5+ years ago, before I started systematizing those)...

I'd rather kick some asses at Amazon... But it's just me. 😜

And I am not against this or denying it. However, what I am saying is that, to achieve the AAA-games-like quality they expect, you just cannot use the same techniques as the ones used in those games, because of the specific constraints of SL (or rather lack thereof, since you can pretty much upload anything into SL and pile it in an infinite number of ways around the corners of a sim). One word: Vulkan. Once the renderer converted to use Vulkan, many more things will be possible, especially related to parallel (threaded) rendering, like I suggested in my above post... Apparently (from what I understood based on what we were told during the SL20B meetings), LL also started to implement some on-the-fly conversion techniques so to be able to render SL on mobiles: this could also benefit the ”standard” viewer. For example, I'd envision some on-the-fly mesh optimization, so that the viewers (mobile and desktop alike) could render simpler objects (which could then be used, at least when at far distance, in the desktop viewer)...

+1 Not sure it is actually related, but it looks to me like TPs were way more reliable before the migration to AWS servers...

Depending on how your viewer is coded and whether it can do true multi-threaded rendering or not, instead of blurring distant objects or using 2D impostors, I'd push their rendering to a low frame rate rendering thread. It would be fine to render a far building, say, once every second, and reuse the result in the final, ”real time” render. You could vary the threaded frame rates depending on how close objects are and how fast you are getting closer or farther to them as the camera moves around... You could use several such threads too, e.g. one for 128m to 256m at 5fps (with fully textured objects), one for 256m to 512m at 2fps (with very low texture LOD) and one for 512m to 1024m (no texture, just a suitable ”averaged” color) at 1fps... IMHO, you are too much geared towards reproducing what AAA games are doing to solve their own issues within their own constraints. You perfectly know that SL is not an AAA game with pre-calculated and pre-rendered assets, very limited camera ”paths”, limited environment settings, etc... The solutions for SL cannot be the ones used in AAA games, even if the latter can be inspiring to find more suitable algorithms. What you suggest would imply that LL puts into place specific servers for pre-rendering impostors, backgrounds, etc: while it would be doable, I do not see LL doing such a thing, since it would cost a lot in term of server power (and here, we are speaking about servers capable to do 3D rendering, unlike what are SL's server right now): way too costly, especially now, with AWS as the servers host...

Lowest = 2 is pretty much a ”requirement”, because it allows to lower dramatically the LI (and the upload cost with it)... I'd blame LL for a poor algorithm with mesh LI scaling. This said, a mesh with three well designed higher LODs and a 2 triangles lowest LOD will still rez just fine at all but very far distances (where it will pretty much vanish): the lowest LOD is rarely ever seen rendered, especially seeing how much we must push the RenderLODFactor setting to get truly crappy meshes to render properly at all.

Similar hardware here (Ryzen 7900X, RTX 3070), also fiber (but Babbage is definitely not a challenge for the network), graphics pushed to the max excepted no shadows and water reflections set to terrain and trees ”only”, with additional 2.0x multiplier on mesh LODs (i.e LOD=3 for all but mesh, LOD=6 for meshes) and I get 50+ fps at 1024m draw distance with the Cool VL Viewer (current release), and rezzed pretty fast: with a cleared cache (i.e. not ”cheating” and fetching everything from the network), half a minute for 256m, and needed barely two minutes more after increasing DD to 1024m... But better than words, here is a video. Frankly, Babbage is not a challenge to render... Note: you will notice I took great care to use almost exactly the same FOV as yours, so that we render the same objects...

You are confusing blur caused/introduced by optical defects/imperfections (such as the limited depth of field of a camera lens) with the eye resolution (the minium angle between two objects/points for the eye to distinguish them apart). The resolution of the human eye allows to tell two objects 30cm apart at 1km. If you see them blurred, you need glasses (at my age, I alas do need them, but with them I see just as well in the distance as when I was 30 years younger). In SL, we are speaking about 512m max draw distance... There should simply be no blur at all on rendered objects larger than 15cm. Period. This is a different (environmental) aspect, which is possible to simulate in SL already (via Extended Environment settings, particles, etc), but should not be ”hard-coded” in the renderer... An acceptable kind of ”blur” would be to use lower resolution textures for distant (>256m) objects (that kind of blur won't affect the least the contours of the objects, which play a big role in how ”sharp” an image appears to the eye). The viewer is already doing it via texture LODs, but maybe pushing down one lower LOD for far textures won't be too noticeable: then you would save some bandwidth, but only for objects you are not getting closer to (since those will need full LOD at some point anyway); I have some doubts about the benefits in term of bandwidth. The viewer had this kind of option in its code (it allowed to load slower higher LODs the faster the camera was moving): it was never used and, when enabled, it made things much worst in rezzing time terms for objects you were getting closer to as you were moving... It finally got removed. The textures resolution does not impact the least the frame rates. On the other hand, using better optimized (or slightly simplified) meshes would definitely help (the well known mesh LODs issue in SL).