Henri Beauchamp

This is typical of a failed mesh skin download, and likely not the viewer's fault. In the Cool VL Viewer, you'd get something logged in this case, like: 2023-08-06 09:41:06Z WARNING: LLMeshRepoThread::run: Skin request failed for 576367a8-7916-0c74-1f74-80fd5704720a Other usual suspects are with people who wear a new (suitable for their destination) outfit and immediately teleport to their destination without waiting for all attachments to actually attach/rez and/or for the server to fully bake their avatar: they might then see their avatar ”fully rezzed” on their screen, but others will not see some of the late rezzed attachments or bogus bakes (the latter may also bear a wrong UUID, causing failure by viewers to download the corresponding texture). A long time ago, to help users with incomplete/in progress baking issues, I implemented in the Cool VL Viewer a small status icon (a red shirt) that appears while your avatar is baking. But I might add a warning dialog for when you TP away while not fully baked... And yes, as Wulfie explained, the weird texture is due to a missing BoM mesh head that should be using it and make the legacy body head vanish.

FYI, PC and MMORPG worlds are full of acronyms. Some persons can find it to be a PITA. AFAIK, UK and US folks are also especially fond of them, IMHO (from a EU citizen's POV), way too much, which reflects in SL; and BTW, get used ASAP to ”PBR” AKA ”GLTF” acronyms for SL too... ROFLOL !

I'd say SL is based on code written back in the early 2000s, yes... 🤣 If you meant the viewer in question, its current incarnation was based off Snowglobe v1.5 (older versions were based on LL's v1.18 to v1.23 viewer code), which I forked and to which I backported the v2+ viewers code over years. The UI taken apart, it is no more v1 at all... But I kept it lean and clean, and thoroughly optimized it at the C++ code level.

This is a known, antediluvian bug of SL (it existed already back in 2006, when I joined SL), happening exclusively on deeded land with deeded objects: if the land got build restriction to the group it is deeded to (instead of ”Public” rezzing permission), then the deeded scripted objects will fail to rez other objects unless the original deeded objects owner (the person who deeded those objects to the group) is online. I never understood how LL could screw that up (i.e. how the online status can even play a role in this), but they did...

I really hope not: see how street view horribly distorts pictures when you ”move” your FOV with the arrows, as it tries to interpolate between two views... There is the same risk with building impostors: to minimize this risk, we would need to divide the sim in a number of squares (16m x 16m or 32m x 32m, perhaps) with a set of building impostors (one impostor per building and per square) for each of them... But there is also the problem of lighting... Building impostors would have to look differently between night and day (and sunset and sunrise), and the lighting would have to match the environment settings chosen by the end user (which most of the time is not even the ”parcel environment”). As I see it, building impostors would be too complicated to implement in SL (as @Norris Mainline remarked SL is not an AAA game with predefined scenes/buildings/environments).

Cool VL Viewer. As for the hardware, Core-i7 9700K, recently updated to a Ryzen 7900X (both give similar fps rates in simple scenes, with a +20% bonus for the 7900X in complex scenes), with a RTX 3070.

That's why I always use a minimum draw distance of 256m in SL (512m in islands without neighbour regions)... With a 256m DD, the outdoors surroundings always look good. Of course, it impacts frame rates, but my viewer is fast enough (> 60fps pretty much everywhere, and usually around 200-400fps without shadows and 60-200 with)... I'm not sure impostor buildings would look quite as good, even if they would of course help with frame rates on ”weak” PCs, as well as with poorly designed mesh buildings which LOD crumbles too fast with distance (I implemented a ”mesh boost factor” in my viewer for those). On the other hand, long distance background sim surrounding looks like a very desirable feature, even with large DD. However, I am not sure how these could get baked in SL to look good whatever the draw distance chosen by the end user...

It's like a little buzzer in your mind, that might ring, sometimes, to tell you that something is going wrong and breaking... Always worth a look.

I don't like the way it rezzes textures with transparency: they look ugly while half-decoded. This is especially obvious on trees foliage. It also sometimes fails to decode textures that OpenJPEG v1.4 deals with without trouble.

Interesting... I usually update the ca-bundle.crt for my viewer each time LL is issuing a new one, but it looks like I missed the latest update (that likely occurred during LL's git migration from bitbucket to github), meaning my viewer is still using the ”old” bundle, instead... and works better (just fine, actually) with it in Aditi right now ! 🤣 The latest is not always the greatest, after all... 😜 Indeed, and I am surprised AWS servers are not configured for it by default...

Probably some transitory issue, which are not uncommon on the beta grid. Also, did you try with another avatar account (sometimes, your inventory in Aditi can get stuck in a bad state, which would cause avatar rezzing failures) ? As for PBR reflections, I also noticed they don't always show properly/fully after a TP (probably some race condition at work with their updates), but always show fine after a relog... I'd suggest you try and reproduce the issue reliably enough (to give precise repro steps to LL), and file a JIRA issue. I just tried logins and TPs, with both the current stable release (v1.30.2.22) and the new experimental release (v1.31.0.0, with dual EE and PBR renderer) of the Cool VL Viewer, and they seem to work fine (at least as I am writing this).

The license is fully respected (see linden/indra/libopenjpeg/readme.txt and linden/doc/licenses-linux.txt). I see no reason why you won't be able to use it in your viewer (and my own work can be reused under either of GPL or LGPL licenses, at your convenience).

Try and borrow the Cool VL Viewer's v1.4.0.635f version (”f” is representative of how many modifications sessions I performed over the original 1.4.0.635 code, with all known security holes fixed, personal optimizations added, v2 optimizations backported, Kathrine Jansma's AVX2 optimizations added, ARM 64 bits support added), which is part of the viewer source tree (linden/indra/libopenjpeg/ subdirectory).: it decodes just as fast as OpenJPEG v2 (and, should you implement GL textures decode multi-threading in BD, like I did for my viewer, just as fast as KDU on modern CPUs), and does not have the bugs that plague the latter in SL with partial decodes (lower texture LoDs), or the silly way even the ”fixed” v2 decodes textures (making them appear as quite ugly while rezzing).

+1 Not to mention viewers are configured differently, e.g. on the number of threads they use. And with modern CPUs such as Intel's with their ”performance” and ”economy” cores, you cannot really control which are the cores affected to two simultaneously running viewers. They will also fight for VRAM and GPU resources, meaning you can draw strictly no conclusion on which one of the two running viewers is getting the most resources from your computer hardware (but it will never be a 50/50 split, you can bet on it). To compare viewers speed, you must run them one after the other, have them render the exact same scene (*), with the exact same FOV, and with the exact same settings (this might be a challenge, since each TPV got its own peculiarities, with its own ”boosting” features, own sliders scale (e.g. for the LOD factors in graphics settings), etc). Benchmarking properly requires a very strict protocol... --------- (*) This sadly means it is close to impossible to compare them in a scene with non-bot avatars around, since avatars come and go, with vastly different render cost. I wish LL would provide a testing ground sim on Aditi, with a rich (heavy), varied environment for objects, and a dozen bot avatars (with equally varied and render-heavy outfits).

Congratulations ! You just understood what the issue is all about: a ”one color scale fits all monitors” is vowed to fail. Today, most monitors owned by, I would bet, 80% of the SLers are not HDR. LL's devels should keep this in mind and verify on a ”mainstream” monitor what their renderer looks like on it, once in a while... 🫣

I totally agree. It is important that the user can get SL to display beautifully on their monitor and following their tastes. I personally do not care the least how things are supposed to look (they will never look as they are supposed to anyway, because monitors are imperfect, even HDR ones, and their adjustments by the final user is even ”more imperfect”). I just want SL to look good for me, on my monitor. The rest is pedantic purism. Beside, SL is not RL. I do not need (and even less want) SL to look exactly like RL !... I personally use SL to roleplay, and enjoy having a virtual world that is not like RL, in which I can live and share my fantasies, while having things left to my imagination.

You are totally right. However, we must do with what monitors can display, and unless you are rich enough to pay for a high DPI monitor (with the graphics card to match the resolution at high enough FPS rates) and a full HDR color space and super-high contrast dynamic (i.e. with a QLED or OLED screen) , you do need some kind of dynamic range compression, or you will have to push the luminosity to levels that will make black spots look grey (and make your eyes bleed), so to see all the color details. This is why, with my monitor (which is an excellent one, but definitely not an HDR one) I prefer (and pretty much need) linear color space... In fact, on non-HDR monitors, an HDR rendered scene will look way more artificial and even ”toonish”, with way too saturated dark colors.

To render with the same color scale as before, and this only for places with a ”legacy” sky environment setting (one without the new ”reflection probe ambiance” parameter that only this new RC viewer provides, so for now pretty much all main grid skies are in this case), set the ”RenderSkyAutoAdjustLegacy” debug setting to FALSE.

Not my taste... But just a question of taste, of course... 😜

More exactly, more contrasted... The new PBR renderer is using a HDR (high dynamic range) color scale to render the scene, instead of a ”linear” scale. If you got a HDR monitor, with contrast not set too high, it might pass, but others will find the scene overexposed under the Sun and underexposed inside a building or under shadows... The latest code (the PBR viewer changed several times regarding which color scale it uses) uses HDR for new extended environment sky settings with a non-zero ”reflection probe ambiance” parameter, and forces HDR off (linear colors on) when that parameter is set at 0. For legacy sky settings (the ones that do not have a ”reflection probe ambiance” parameter at all), the default is to ”auto-adjust” to HDR (i.e. force HDR on), so legacy scenes with legacy sky will definitely look different... You may change this by changing the ”RenderSkyAutoAdjustLegacy” debug setting to FALSE, which will then cause the viewer to render scenes under a legacy sky in the linear color scale. I find it sad that 1.- the default for that settings is not FALSE and 2.- that it is not exposed in the menus (e.g. next to the environment settings options). I would also like to see a setting to force HDR off, including under new skies with a non-zero reflection probe ambiance: after all, LL cannot control what type of monitor you got...

I do not think I wrote it was ”broken”, but yes, the new ”dynamic” algorithm implemented in FS' latest release seems to be causing issues with VRAM consumption for quite a few people, and as I could notice myself; my suggestion to people encountering a problem to turn it off proved to solve their issue... The problem with VRAM is that when you fill it up, the GPU driver starts spilling its memory allocations over to the RAM, and then there must be heavy transfers performed on the PCI bus, causing ”hiccups” or right out seconds long freezes. With the old algorithm (fixed and moderate VRAM amount dedicated to the viewer), you do not risk to spill memory as much as you do with the ”dynamic” one. Also, I noticed that, at least with NVIDIA (I do not have any AMD card to test it against), there are times when, after a seconds-long overshoot of the VRAM amount, the driver was never quite able to ”fully recover” and migrate back all its structures to the VRAM once enough of the latter gets freed (e.g. after teleporting away from a busy place to a sky box), and the only solution left was to relog in a new session (or endure much lower fps rates)... Feel free to have a look and ”borrow” the code I implemented in the Cool VL Viewer to try and keep everything in line, but be aware that it involves a rather complex set of algorithms with discard bias adaptive adjustments and amortizing, anticipation/extrapolation of the VRAM and GL textures consumption, as well as force-freeing of stale bound GL textures (which otherwise cause a ”leak” of VRAM over time), among other more subtle/indirect adjustments (in my viewer, the texture discard bias also influences the objects retention and push delays in the object cache, for example)... I am also extremely skeptical about LL's PBR viewer new code for texture discard bias and VRAM management (it causes the VRAM to fill up to the brim), thus why I preferred to (deeply) change the old algorithm for my viewer...

I never had any such complaint, no... But my viewer user base is in no way comparable to Firestorm's either (there is likely a difference of two orders of magnitude in number of users), so... True, for users of several different viewers, it means more disk space taken by separate caches, but with today's cheap storage solutions, it should not be much of a bother... Interesting idea, but this might be an overkill for people using a lot of accounts (this time, filling up their storage too much). If anything, I would recommend making such a feature a configurable option. 😉

Nope... The Classic Clouds had their own position generator on the servers, and cloud update messages were sent by the sim server to avatars around, so that everyone could see the same clouds rendered in their viewer, if they had them enabled, of course. When LL announced they would shut down the Clouds, I immediately captured the cloud messages to see how I could generate them viewer-side instead, and after a bit of reverse-engineering, I came up with the cloud generator code that I implemented in the Cool VL Viewer and which activates itself whenever the sim server is not sending any cloud update message (OpenSim grids sim server can still send them, at least in non ”var region” sims, but then the Cool VL Viewer can also generate the clouds in those). The generator uses the Wind update messages to move the Clouds around (everyone in the sim receives the same Wind messages), but the ”puffs” are generated randomly and are therefore not rendering the same in two different Cool VL Viewer instances (i.e. everyone using the viewer in the same sim would not see the same clouds). I also made the Classic Clouds altitude configurable (there's a spinner in the Graphics prefs for it) instead of fixed at 192m like they were with SL's clouds. I don't like it when nice features are removed... So, I keep them every time I can in my viewer; another example would be animated Linden trees... 😜

In fact, no, not for everything (e.g. it uses the same directories for the IM and chat logs on purpose, so that you can switch between SL's official viewer and mine without loosing any part of your conversations in your logs, but these are ”per account” files, so they won't risk to collide in two simultaneously running sessions of any viewer). It also uses the same global logs and settings directory, but with different file names than any other viewer. However, the caches (which structure and format are often different) are held in different directories than any other viewer. So, yes, in the end, it cannot collide/conflict with other viewers, not even with a different version of itself or any number of running instances of the same version (I took great care to detect such occurrences in the code, to avoid fighting for caches, logs or settings writes), so it is safe to use in multiple instances on the same computer.

Nice feature. However it has been almost 3 years now, that I abandoned 32 bits builds support: not a single user was using such builds any more, anyway, and they were way too limited to fit modern SL in 3 or 4GB (depending on the OS) of virtual address space (not to mention the fragmentation of the latter during the session, which finally resulted in exhausted address space, allocation failures, and finally crashes). Interesting feature... I might consider implementing it in the future, especially with the upcoming PBR viewer and its 4 textures per face (it won't impact too much people at first, but as PBR objects will spread on the grid, it will inevitably result in viewers needing way more memory than now). For now, the Cool VL Viewer uses a higher discard level for ALM textures (normal and specular maps) whenever the bound GL textures VRAM consumption increases above a (configurable) level: this allows to fit more high resolution diffuse maps (which contribute much more than the other two maps to the objects prettiness and avoids blurring them too soon) in the same amount of memory...