Henri Beauchamp

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.

Yes, let's wipe out from SL everything that has been built before PBR release ! 🤪 Cannot you understand, that no, this will not happen (thankfully, since it would mean killing SL !), and that, as a creator, you must also care about legacy contents, a contents among which your shiny new creations will be rezzed as well ?!? Such a state of mind as carelessness for legacy totally baffles me: if you want to kill SL, then by all mean, keep acting this way ! Well, good news then: this is the exact same problem (the blue hue impacts legacy and PBR contents alike) !

Perform the same test, on a platform at, say, 500m over the ground, not using any reflection probe (typical conditions, matching the gazillion of such platforms and sky boxes which exist in SL). Do it with both PBR metallic objects and legacy shiny ones (they suffer from the blue shine in the exact same way). Good luck with eliminating the blue shine via EE settings without having the sky turn either grey or pink ! 🤣 As for the ”fixed” mid-day setting by LL (yes, the one with broken, static clouds too), you will get the same thing I got: see the screen shots I attached to my reply to Dan Linden in this feedback thread. Beside, I won't consider the problem ”solved” if the ”solution” implies modifying all the existing EE settings in SL to have existing contents to properly render with the PBR viewer ! An acceptable solution would consist in a workaround/kludge/hack being added to the renderer so that the EE parameters involved in that ugly blue hue are automatically and appropriately corrected instead of being used ”as is” in the shaders while rendering the reflections (and only them)...

No, it is still blocked for now (awaiting Callum Linden's review). But the ”problem” (for LL, not me) is not even about that one-liner pull request, it is in their refusal to make scrolling clouds the default for everyone when you first log in with their viewer. As for your advices about my ”tone”, please keep them for yourself. Thank you.

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...