Henri Beauchamp

I have one novelty I noticed, but that I don't think will be listed in the release notes: On login (with any viewer), the avatars now always fly (*) Annoying... 🤪 (*) Until you click with the mouse in-world, at which point the viewer will update the flying state; normally, the avatars should never be flying on login, and it is the viewer which sets the flying flag (if needed) and informs the server of this, based on a saved setting (the flying state is saved on logout in ”FlyingAtExit”)...

Most likely a race condition. I did not investigate, since I would expect from LL that they fix their own mess... Sadly, they currently seem busier pushing new features (which will of course introduce even more bugs), rather that fixing all the outstanding PBR bugs (moires on water with SSR and non-working water reflections, blue hue on shiny objects unless you hack EE settings beyond repair, broken shadows, broken alpha with shadows on, broken semi-transparent faces on legacy contents, etc, etc, etc...). 🫣

Precisely no... This is a new bug that only happens in PBR rendering mode (the fact I can switch between all three forward, ALM and PBR modes in the Cool VL Viewer allows me to be 100% affirmative on this): the old bug does have a workaround (that has been implemented for years too, in my viewer, including with an ”auto” mode, on login, TP and sim border crossing), but this new one does not have any other work around I could find, beside the OP's one (i.e. zoom out beyond draw distance, wait a few seconds, then restore camera to normal view). This is not to say that you got that bug in Sharpview: on the contrary, I do believe this bug is specific to LL's PBR renderer code (C++, shaders, or a combination of both, and most likely a race condition too).

The PBR renderer is especially sensitive to this... Probably a race condition in the occlusion code. Even with the Cool VL Viewer (which got a workaround for such cases, workaround which always work for its ALM and forward rendering modes), when in PBR rendering, I sometimes observe this phenomenon (and the ”Refresh visibility of objects” workaround is helpless in this case: only the zooming out of draw distance can fix it)... 😢

I don't have the sources, to start with...

It would likely compile just fine on a Linux aarch64 SBC (Orange Pi5B, Rock Pi5B, Raspberry Pi5, etc), and might run fine on them too, though at low FPS rates. With the sources (apparently not yet available), I could give it a try on my Orange Pi5B...

It will work fine (CPU and GPU are plenty powerful enough), but you might want to verify if you can expand the RAM (are there free slots left, or are all the motherboard slots already populated, because then it would mean buying 32GB (2x16) of DDR4 instead of an additional pair of 16GB (2x8) DIMMs if/when you want to update). 16GB is really a minimum for SL, nowadays, and you would be much more at ease with 32GB of RAM (the viewer alone can easily consume up to 24GB of memory in heavy environments such as scenic sims with a gazillion of meshes and textures, or very populated places with dozens of avatars wearing complex attachments).

Well, given my account will be 18 years old in 7 months, I'd say I should not need any ”age verification” any more, not even today (unless you think I could roam SL while still a RL baby)... 👴🤣

Sadly, many JIRA issues are missing, still. Examples: BUG-234816 (PBR rendering discrepancies) BUG-234896 (cannot set a diffuse texture on a PBR face)

Thanks for the private pointer. Still 98% of SLers who will not get it and will scratch their head when reading Brad's statement... Not a Reddit user... 😛

If I can't see the original allegations, how could I understand Brad's own post and what it is really about ? IMHO Brad's statement is more confusing to 99% of the SL residents than anything.

So, basically, this is a reply about something no one knows anything about... Totally dispensable, IMHO ! 🤪

Any pointer/URL ?

Err... Excuse my ignorance, but what were those ”allegations” Brad is replying too ?... Some press article in the US ?... Something else ?

Let's vote (and add comments/suggestions), for a start then... 😉

I totally assume my naughtiness... Do expect more sexy time naughty bumping ! 💋

*sighs* I'm done with this thread. Don't feed the:

Please, stop spreading FUD... There is no ”link” whatsoever between a viewer you would use and your payment info... As for the Cool VL Viewer specifically, it is probably the most respectful viewer regarding your data: it does not even use a custom web login panel page (like many other TPVs are doing), meaning that your IP address cannot even be known by a web server that would run such a custom page. It does not have either any auto-update feature that would log the version you are using together with your IP. I get absolutely zero feedback on who is using my viewer or not, what is their IP, OS, etc... Even the web site hosting it pertains to my ISP (meaning I do not even have access to the HTTP logs for it). There is not even an automatic crash log/dump upload feature like all other TPVs got... See ”Help” menu -> ”About” floater -> ”Usage policy” tab:

Bump !

OK... So you want ludicrous frame rates ? Here you go: 1340fps in a sky box. GPU consumption: 204W. CPU consumption: 100W. What did I win ? 🤣

That's why you cannot recommend such a poor hardware for SLing... iGPUs or APUs = no go. Any discrete GPU equal or better to a GTX 1070 and any 6-core (+SMT) CPU with 16GB RAM will render SL at 30+ fps (and 60+ in most cases), even with a 256m draw distance... If you cannot do that with this (relatively) old hardware, then your viewer is poorly optimized: try another. I think I am helping people with ”weak” hardware a lot already, via the Cool VL Viewer development (the latter can even run at 20+fps and 256m DD on my old potato (4th) computer equipped with a GTX 460 and a Quad Core2 Q6600 @ 3.4GHz, with 8GB RAM, but of course, in forward rendering mode only, not in ALM or PBR)... As for modern SLing, any system with a 4+ GHz octo-core (+SMT) CPU with any modern discrete GPU equipped with 8GB of VRAM or more and 32GB of RAM will do very nicely, and you will not need to spend a fortune for such a system either...

Are you kidding ?... 🤪 It has been many years (over 10, for sure) I have been using 256m as the minimum draw distance in SL, with 512m in islands (sims without any neighbouring sim), or when sailing or flying along/over main land... 64m is ridiculously low: if you cannot do better with your hardware, it is time to upgrade (or opt for a faster viewer)...

For that, you can use the Cool VL Viewer and switch it to the legacy ALM or even forward rendering modes... 😛

The faces with PBR materials disappear (regardless of the presence of fallback diffuse texture or legacy material on these faces), the rest keeps rendering. Note however that some PBR materials can actually be classified as PBR alpha masks, and would keep rendering... This is purely a debug feature, and not meant to be used in daily SLing.

For information, I just released the Cool VL Viewer v1.32.0.12 which implements my first workaround attempt for the ”ugly blue hue on shinies” and does not require anyone to touch anything at their environment settings (use the one which suits you best, including an old Windlight one if that's what you prefer). It also makes water bodies look less sky-blue and more realistic. The workaround is still not perfect, but it does attenuate a lot that silly blue shine by using a desaturation technique on ”blue horizon” and ”blue density” sky colors for reflection irradiance maps renders... EDIT: and here is the corresponding pull request for LL's viewer code base.