Jump to content

Henri Beauchamp

Resident
 View Profile  See their activity

  • Posts

    1,180

  • Joined

 Content Type 

Posts posted by Henri Beauchamp

    Official Statement from Oberwolf Linden

    in General Discussion Forum

    Posted

    6 minutes ago, Jaylinbridges said:

    Check your messages.

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

     

    5 minutes ago, Arielle Popstar said:

    I did point to R /Secondlife ”Official Statement From Executive Chairman Brad Oberwagerin” on Reddit where there is a posted linked copy of the blog post.

    Not a Reddit user... 😛

    Official Statement from Oberwolf Linden

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    6 minutes ago, Arielle Popstar said:

    Not really. There were allegations about child avatars but also allegations about some of the inner workings of departments within SecondLife that has had alleged ramifications to the residents.

    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.

    • Like 2

    2024 Faster fps without spending money (: "NOT FOR LAPTOPS"

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    43 minutes ago, rottweiler Lednev said:

    The joking using cool viewer makes me question using cool viewer now as my payment information would be linked to it.

    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:

    Quote

    3.- Privacy policy:
    No data whatsoever is collected or sent to the author of this viewer. Data is however stored on your hard disk and exchanged with the servers of the grid(s) you connect to, in the exact same way as an official Second Life viewer would do.

     

    • Like 3

    What are the ideal settings to run this program smoothly in 2024?

    in Second Life Viewer

    Posted · Edited by Henri Beauchamp

    57 minutes ago, Kathrine Jansma said:

    It is not so outlandish for iGPUs like non-gaming notebooks.

    That's why you cannot recommend such a poor hardware for SLing... iGPUs or APUs = no go.

    3 hours ago, Modulated said:

    How about helping someone have a better experience on the hardware THEY HAVE instead of telling them to buy this or that or throwing a ridiculously priced shopping list at them?

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

    What are the ideal settings to run this program smoothly in 2024?

    in Second Life Viewer

    Posted

    21 hours ago, Modulated said:

    Keep your draw distance low-ish, around 64 or maybe slightly higher

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

    • Like 2

    Why I Don't Like PBR

    in General Discussion Forum

    Posted

    4 hours ago, Love Zhaoying said:

    Darn! Too bad it wouldn't mean ”go ahead and render any underlying non-PBR materials instead”!

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

    • Like 1

    Why I Don't Like PBR

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    34 minutes ago, Chic Aeon said:

    So does that mean that the object with PBR ”disappears”?  What if ONLY one material of the object uses PBR as well as legacy textures (like a mirror surface maybe)?

    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.

    • Like 2
    • Thanks 1

    Why I Don't Like PBR

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    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.

    • Like 1

    Why I Don't Like PBR

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    12 minutes ago, Porky Gorky said:

    In fact I couldn't care less about legacy content.

    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 !

    Quote

    The problem I have been trying to solve is consistent rendering of PBR materials under different SL lighting environments.

    Well, good news then: this is the exact same problem (the blue hue impacts legacy and PBR contents alike) !

    • Like 3
    • Thanks 1

    Why I Don't Like PBR

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    30 minutes ago, Porky Gorky said:

    The only solution is to change the environment to one that simulates light more realistically. @Jenna Huntsman free EEP on the marketplace is a good example of one that works. The sky still looks blue but the way the light interacts with various rough/metallic surfaces is acceptably realistic. So on a personal level the problem is solved. My 10 test materials look acceptable with my customised EEV. They look as good as they do in Unreal Engine before lighting is baked and post processing added, but that’s ok they look acceptable considering this is SL.

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

    • Like 2

    Why I Don't Like PBR

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    5 hours ago, Andred Darwin said:

    Your pull request was actually approved!

    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.

    • Thanks 1

    Why I Don't Like PBR

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    1 hour ago, Rowan Amore said:

    But people use all kinds of different lighting.  That's my point.  There are a myriad of options now with EEP.   Why give so many options then basically take them away because future content will make all those option obsolete?  I'm sure my lighting at home is far different than everyone else's as it should be.  Now, the lighting will make the furniture, dress, house, etc look good but all the avatars will look like crap?  Awesome!

    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 ! 😵

    • Like 4
    • Thanks 2

    Why I Don't Like PBR

    in General Discussion Forum

    Posted · Edited by Henri Beauchamp

    54 minutes ago, Porky Gorky said:

    The creator was using 8 materials on the chair, so that would be 32 x 1k textures which is absurd.

    If 2k textures are rolled out maybe LL could offest the impact by heavily reducing the number of surfaces/faces available on each piece of new mesh.

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

    • Like 2

    When did voice chat come in Second Life?

    in General Discussion Forum

    Posted

    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.

    • Like 2

    Order of deletion when too many prims

    in General Second Life Tech Discussion

    Posted · Edited by Henri Beauchamp

    17 hours ago, Monty Linden said:

    There is an order to it. .../... (region, parcel, location, time, date in the Mayan calendar, etc.).  This thing is a function of 47 or more variables.

    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:

    1. Objects subject to parcel-auto-return returned first (first rezzed, i.e. closest to the auto-return delay, first returned).
    2. Existing ”Locked” objects either owned by the parcel owner or set, or deeded to the parcel group never returned.
    3. 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).
    4. 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).
    5. Last rezzed, first returned.

    Chat logs unreadable?

    in General Discussion Forum

    Posted

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

×
×
  • Create New...