Jump to content

Henri Beauchamp

Resident
  • Posts

    1,159
  • Joined

Posts posted by Henri Beauchamp

  1. 2 minutes ago, Scylla Rhiadra said:

    Right, but I won't be able to easily create content that employs PBR?

    Just as ”easily” as managing to use Blender (*), I suppose... 🤣

    (*) People complain about the SL viewers complexity, but I personally think Blender got the most disconcerting, obscure, unstable (it changes dramatically every few months) and unusable UI of any software I ever used in my life.

    • Like 2
  2. 2 minutes ago, Scylla Rhiadra said:

    So, will the eventual obsolescence of ”diffuse” maps mean that I will no longer be able to do that without more specialized knowledge and/or software?

    It won't be obsoleted, or it would mean instantly destroying all the legacy contents of SL...

    • Like 1
  3. 15 minutes ago, Scylla Rhiadra said:

    Ok, sorry, can you elaborate? What is the difference?

    Color encoding and alpha differ, for a start, then the other maps mix to the base color texture, so the final aspect (including colors) will often be very different (unless your object does not need at all PBR to render in the first place). I cannot elaborate here (too complex). Have a look at the specs for full details.

  4. 1 hour ago, Qie Niangao said:

    There's no particular reason that glTF materials should use more memory than full Blinn-Phong materials (how often will the emissive mask be used, really? and for that matter, how many albedo maps should just be a 32x32 blank texture with an applied tint, if the model's surfaces are sensibly partitioned for materials?).

    I'm afraid the theory won't apply in practice: in SL PBR materials can bear up to 5 textures: the diffuse texture (that should be populated/used, and allows non-PBR viewers, which will likely include the future mobile viewer, to see something else than a white blank face), plus the four ”base color”, ”normal”, ”metallic roughness” and ”emissive” maps, against only 3 textures for legacy materials (”diffuse”, ”normal” and ”specular” maps), and one (diffuse) for the forward renderer.

    Since there is no limit either to the texture upload size for all those maps (which can all be 1024x1024 pixels wide), and even though the renderer can use smaller maps (via LODs) to render them (LL's PBR viewer uses this trick, and I further refined it myself), the memory usage (RAM, for sure, VRAM, most likely as well) is higher in practice (especially considering how SL creators love to use high resolution textures everywhere, even when they are just a total wastage of memory and won't change a thing on the final product rendering quality).

    Add to this more render buffers needed for PBR, reflection maps, etc, and the PBR renderer appears like a gluttonous pig: graphics cards under 8GB of VRAM will have trouble rendering PBR-heavy contents at 256m draw distance, when it did not cause any issue with forward or even ALM renderers.

    • Like 2
  5. 7 hours ago, LipstickAndDreams said:

    ALM is still slower than the forward renderer, after all these years.

    Actually, it depends on your GPU... Modern GPUs can run ALM (deferred rendering) just as fast as forward rendering, and even slightly faster in some specific cases (depending on what is being rendered).

    However ALM consumes more memory (at least when there are materials around), and PBR even more. So, here again, depending on the scene being rendered (e.g. large venues with lots of avatars) you may see issues with ALM that you won't see happening, or only later (in even worst scenarios, such as with more avatars coming around) with forward rendering, due to the VRAM filling up to the brim and the vertex buffer allocations starting to spill over the RAM, slowing everything down and/or causing stuttering/hiccups in frame rates.

    While with a GTX 970 (and older cards) I was pretty much never using ALM (since slower), with a GTX 1070Ti I could use either, and with my latest RTX 3070 ALM is most often faster. Yet, there are cases when I still prefer using forward rendering, such as when driving/flying/sailing outdoors, since then there are almost no materials in sight (so I loose nothing with ALM off), and forward rendering still uses less VRAM (meaning I can push the draw distance to the max, which is quite useful for such activities, letting you see where you go) and offers a waaaaaay better anti-aliasing (native GPU SSAA), and this despite the fact my viewer got SMAA shaders for ALM, which are themselves way better than LL's FXAA: the scene looks even more gorgeous with just forward rendering in this case.

    As for old GPUs or iGPUs/APUs, yes, ALM is definitely way slower than forward rendering, often by a factor of two !

    I warned LL about what would happen if they removed forward rendering. They ignored my warning; now what I ”predicted” (or rather simply inferred) is happening... 🫣

    • Like 4
  6. 1 hour ago, NiranV Dean said:

    Also oof at that shadow issue. However if i see that right and this is for 7.1.1 i do not yet have these changes. I'm still pre 7.0.0 (missing a couple idk maybe like 20-30 or so)

    It is still not fixed, but you will find on the JIRA I opened for this issue an update I made with hints for adjusted settings to (partly) revive shadows in LL's broken code (that I sadly had to adopt, since it became a prerequisite to other fixes to PBR shaders and render pipeline).

    But there are many other issues with PBR indeed (e.g. BUG-234816 or BUG-234820)... So yes, it should still very much be considered ”beta” despite LL having pushed it (or rather shoved) to ”release” status. 🫣

    • Like 1
  7. 15 hours ago, LipstickAndDreams said:

    Would removing PBR violate this term?

    No.

    Due to its bad wording, rule 2.k is too often badly interpreted. It is there to prevent TPVs from introducing features that would break how your own avatar looks in other viewers. This case did happen (before the TPV Policy was published), when a TPV introduced double-attachments per joint (back in that time you could only wear one attachment per joint), when other viewers (and LL's first among them) did not know how to deal with this; this caused avatars of people using that specific TPV to appear with floating attachments around them in other viewers, thus ”breaking the shared experience”.

    However, you can do whatever you want, locally (i.e. on your own viewer screen) with your own (non shared) experience: as long as it does not impact others, you are not breaking any rule. This is already the case when you switch to a local environment setting, or change graphics settings. This is the same thing for ALM, PBR, etc...

  8. 31 minutes ago, Jenna Huntsman said:

    I believe Henri has essentially reimplemented the viewer 6.x renderer alongside the viewer 7.x renderer, which may work, for now, but I remember Henri has also mentioned that this option won't be around forever, and will only be maintained as long as it makes sense to do so.

    ”v6” renderer and all its predecessors, rather...

    The Cool VL Viewer started (as the first public release of the Cool SL Viewer v1.18.4.3) with a pre-Windlight renderer... Then came Windlight, which was badly taxing many PCs back in those ”old days”, so I maintained v1.19.2 (a fork of LL's v1.19.0.5) for months (with around 90 weekly releases, IIRC), alongside the v1.23 Windlight branch... The time for everyone to be able to run the latter in a decent way. It was rather ”annoying” for me, because it implied maintaining two different branches along each other (double work, especially with the backporting of new features from the v1.23 code base to the v1.19 one).

    Later, came meshes, and the backport of LL's v2.6 render to the Cool VL Viewer (v1.26)... A huge amount of code changed in the renderer and viewer underlying libraries alike, but there was no need for keeping the old renderer around (legacy objects still rendered in the exact same way in the new mesh renderer).

    Later again came (now legacy) materials... But there was no need for maintaining two renderers: no issue with speed or legacy contents, and even though ALM suddenly used more memory (with up to three textures per face instead of just one), you still could switch back to the forward rendering mode when needed/preferred.

    Then, came Extended Environment, and sadly the renderer was pushed to release way too soon (just like PBR has just been); the result was a slooooooow renderer with many rendering glitches, which was totally unacceptable for me. I then decided to make my first ”dual renderer” viewer, because I did not want to reproduce the v1.19/v1.23 experience. Once LL fixed the EE renderer and made it fast enough again (”performance viewer” changes), I gave up on the Windlight renderer part to adopt EE as the only renderer in my viewer.

    With PBR, I feel again compelled to maintain a dual renderer viewer, and yes, only for as long as it will make sense. And it makes sense for as long as legacy contents renders like sh*t in the PBR renderer, and for as long as we do not get faster performances on ”weak” hardware, or the said hardware is no more used by SLers, or we get a fast Vulkan renderer... whichever happens first. 😜

     

    1 hour ago, Jenna Huntsman said:

    It does also mean that any object using PBR materials either won't render (will use the Blinn-Phong texture underneath) or will not use the entire material (i.e. rendering base color only - this will mean that any object that uses PBR will look broken).

    Not really... PBR-enabled objects can (and should) still make use of the diffuse texture, to offer something adequate (even if not ”shiny”) to people not using a PBR renderer. Of course, it will depend on the good will of the creators, and on the choice/pressure from their customers (if people refuse to buy objects without proper diffuse textures, then the merchants will feel compelled to use them in their products).

    But yes, as PBR materials-bearing objects will spread over the grid, using the legacy renderer will become more and more unappealing; though, if to judge from what happened with legacy materials, there will likely be plenty of places in SL where you won't see a difference (e.g. main land outdoors), even in a couple of years from now...

    • Like 1
    • Thanks 1
  9. 1 hour ago, Tomas McConaught said:

    Water items like the linden water seas have gone from beautiful and calming to sickly, imo, and I have been an ocean or river view type for much of my game.  The overall effect is like the bit-depth of the colors has been reduced.

    Try editing app_settings/shaders/pbr/class3/environment/waterF.glsl in the viewer installation directory, and change line 277

    color = ((1.0 - f) * color) + fb.rgb;

    to read:

    // Make water appear less sky-blue: 0.65 and 0.8,0.85,0.75 factors added. HB
    color = ((1.0 - f) * color) * 0.65 + fb.rgb;
    color.r *= 0.8;
    color.g *= 0.85;
    color.b *= 0.75;

    This looks much better, IMO (I will use this hack in next Cool VL Viewer release), even if faaaaaar from the beautiful water surface Windlight has been providing for years. 😢

    Here again, Lindens, get the Cool VL Viewer, stand near a water body, then toggle rendering between PBR and EE/WL with the corresponding check box in the graphics settings, then observe the dramatic render quality degradation in PBR mode, and please, pretty please, fix PBR waters !!!

    • Like 1
    • Thanks 1
  10. 12 hours ago, Gabriele Graves said:

    Originally, I did have concerns that existing content would look bad but that hasn't been the case thankfully.

    Really ?.... I beg to differ, and I just created a JIRA issue to illustrate the bad rendering discrepancies seen on non-PBR contents. See BUG-234816.

    It's getting late here and now, but tomorrow I will try and open another JIRA (I will have to make a video for it) for the ugly waves-like artifacts seen at the surface of water bodies when moving close to them (or on them)...

    EDIT: and here is the JIRA about the water surface artifacts: BUG-234820

    • Thanks 1
  11. 1 hour ago, AmeliaJ08 said:

    Left is PBR isn't it?

    The other way around, I think... 🤪

    Joking... But if anything, this would ”show” how personal interpretation (and taste) does ”matter in such matters”. 🤣

    And for many people, the fact you need to move your camera around an object to see the lighting changes and finally declare ”oh yes, materials (PBR or not) look definitely better !”, demonstrates how much it matters for some situations; e.g. when riding/flying/sailing in/above/along SL main land: all you care about, then, is a sharp (*) picture, with fast frame rates and as few as possible loaded but accurately rezzed textures. And, surprise, surprise, in this kind of SL usage, the super-old-legacy forward rendering mode is still the best compromise you can find !.... O.O

    (*) ALM/PBR totally lame FXAA anti-aliasing shader makes things look like a blurry mess (it blurs details *inside* textures, instead of dealing only with prims edges), when forward rendering GPU's native 4x SSAA looks gorgeous.

  12. 14 hours ago, Quartz Mole said:

    We use a variety of machines of all  shapes and sizes -- I'm still running a GeForce GTX 660 GPU !

    And I still got a PC with a GTX 460 (and an Intel Core Quad Q6600 with 8GB RAM) that I also use for testing viewers... Also got a GTX660 (Intel i5-2500K, 32GB RAM), a GTX970 (Intel i7-9700K, 64 GB) and my current, main PC with an RTX 3070 (Ryzen 7900X, 64GB)... And even my Linux firewall PC is used for testing, with a poor man's iGPU (UHD Graphics 605, Intel Pentium Silver J5005, 8GB RAM).

    12 hours ago, Quartz Mole said:

    It shouldn't make a big difference to people's performance, at least not with the Official Viewer. 

    I would agree as far as you enable ALM in the (now legacy) viewers renderer (because indeed, and as long as you keep all reflections settings turned off, the PBR renderer does perform as good or even better, in most circumstances, than the ALM EE renderer), but it is an entirely different experience if you disable ALM in the latter (i.e. use the now removed ”forward rendering” mode): on old/”weak” hardware your frame rate will double, and your VRAM usage will lower enough that all the textures will look nice, instead of half blurry.

    I am sorry, but many users will find PBR too costly for their hardware, especially when they want to keep the same level of rendering quality (same resolution/viewer window size, same draw distance, same objects rendering LOD settings, textures that don't go blurry on them, etc).

    14 hours ago, Quartz Mole said:

     I know the Mac users were having difficulties not so long ago, but I think those have now been ameliorated, if not completely fixed.

    If by ”fixing” you mean disabling HiDPI (i.e. dividing by 4 the resolution of the render), then I suppose it is fixed... But no, really, it is not an acceptable ”fix”, and much less a ”complete fix” !

     

    There are also many issues with the PBR renderer as it was shipped for release. e.g. ruined shadows or ugly ”waves-like” artifacts on water bodies surface when turning around or moving forward/backward with your avatar/camera, but also rendering discrepancies with the legacy renderer, when rendering legacy contents, e.g. full bright faces not rendering properly, semi-transparent faces with legacy diffuse textures appearing much less transparent/too opaque, legacy shininess not rendering the same, legacy (non PBR) materials not shining the same way, or appearing blueish, etc, etc...

    While I welcome innovation and always have been an eager early adopter, I still think that PBR, which will be a big plus for SL in the long term, has been rushed out too soon, which will sadly cause many SLers to hate it, while they should have loved it, had it been truly ready for release.

     

    This is why I decided to maintain a dual renderer (EE with forward and deferred/ALM modes + PBR) in the Cool VL Viewer for as long as LL will not come up with a properly fixed PBR renderer, and for as long as people with weak/old hardware will need an alternative. And by the way, dear Moles and Lindens, if I were you, I'd use the Cool VL Viewer to test the impact and discrepancies of the PBR renderer against EE ALM and forward modes: you can switch between the rendering modes in real time, with just the ticking of a check box, making it an invaluable tool to detect rendering issues...

    • Like 6
    • Thanks 1
  13. 2 hours ago, Conifer Dada said:

    The downside of PBR, at least with the current release, is that rezzing times are much slower, both for avatars and for the built surroundings. This is even the case when graphics set to minimum. I generally use the LL standard viewer and it had been fine up until this PBR release.

    This is not related to the PBR renderer itself, but to the fact that LL's PBR viewer (and all TPVs directly importing LL's code from git, meaning all TPVs but mine) changed the texture fetcher algorithm.

    <technical stuff>

    So far, the textures were fetched (and decoded, and cached) in the order of their priority (i.e. the higher priority textures first) and the priority (importance to camera, virtual size on faces using them, closeness to the avatar, texture usage - e.g. is it a preview texture, an attachment texture, etc -) was reevaluated every few frames for each texture in FOV.

    This priority was also preserved whenever the fetcher thread encountered a delay (e.g. cache read delay, HTTP fetching delay, decoding delay, cache write delay), with just a (huge), constant penalty subtracted from the priority when such a delay was encountered, penalty immediately reverted as soon as the callback for the step that incurred the delay was invoked (meaning as soon as it got ready for the next step, the texture found itself back with its original priority in the queue).

    Together with the PBR viewer (but independently from the PBR rendering code itself), LL changed that algorithm for a simpler ”first seen, first served” priority-less queue, in which, each time a delay is encountered, the corresponding texture is moved back at the end of the queue so that the fetcher can attend to the fetching of the next texture in the queue.

    This simpler (and quite naive) algorithm avoids the periodic priority reevaluation and the sorting of the queue before each new fetcher loop, saving some (but not that much, in fact) time on the CPU side during a frame. But on the other hand, while it performs almost just as good on high end hardware or at least hardware with balanced performances (good CPU, good network bandwidth, good storage speed), it performs like utter sh*t on weaker or unbalanced hardware (e.g. good CPU, average storage, poor network, or average CPU, good network, average storage, or excellent CPU and storage but poor or unreliable network, etc...): the problem here is that important textures that got delayed must wait for all other textures to pass through a fetcher loop before they have a chance to escalate to the next step.

    </technical stuff>

    This is the reason why you are seeing this slooooooow rezzing on some hardware with all PBR viewers but the Cool VL Viewer, for which I kept (and further optimized, tuned, sped up) the old texture fetcher.

    • Like 4
    • Thanks 10
  14. The full LLThreadSafeQueue warnings seem highly suspicious to me, and could possibly be a factor in the login failure.

    The CertExpired error could also be relevant: if the viewer fails to negotiate a valid certificate for TLS transactions with the SL sim servers, you won't get in...

    Your best bet is to poke FS' support team and file a JIRA, providing the full log as an attachment to the JIRA issue.

  15. 33 minutes ago, animats said:

    Cranking up Sharpview's values to the highest values shown there reduced region loading time from about a minute to under 10 seconds.

    Glad to hear it !

    Strange that other viewers than mine (which, AFAIK, is the only only one to use extrapolated values) are not suffering from the same delays as the ones you encountered... 🤔

    Also, it might be worth playing around with the bandwidth repartition in the slots: since ”Texture” and ”Asset” are no more in use (in SL), you might want to try and reduce those to increase ”Task” accordingly, instead, which I suppose would be the bandwidth reserved for object updates...

  16. 3 hours ago, Conifer Dada said:

    I did have to stop using it though as the fan on my computer was humming louder than I've ever heard it before!

    ”Preferences” floater -> ”Cool features” tab -> ”Misc.” sub-tab -> ”Frame rate limit” spinner. Do read the tool tip and enjoy a quiet, cool and fast SLing (frame rate limiting will even lower rezzing time with the Cool VL Viewer, thanks to its smart ”free time” per frame utilization algorithm).

    • Thanks 2
  17. 3 hours ago, animats said:

    // Resend, Land, Wind, Cloud, Task, Texture, Asset in kb/s.

    [ 100.0, 100.0, 20.0, 20.0, 310.0, 310.0, 140.0 ]

    all multiplied by 1024.0 before sending.

    I extrapolated those for higher bandwidth settings in the Cool VL Viewer:

    // Bandwidth settings for different bit rates, they are interpolated /
    // extrapolated.
    // The values are for: Resend, Land, Wind, Cloud, Task, Texture, Asset
    static const U32 BW_PRESET_50[TC_EOF] = { 5, 10, 3, 3, 10, 10, 9 };
    static const U32 BW_PRESET_300[TC_EOF] = { 30, 40, 9, 9, 86, 86, 40 };
    static const U32 BW_PRESET_500[TC_EOF] = { 50, 70, 14, 14, 136, 136, 80 };
    static const U32 BW_PRESET_1000[TC_EOF] = { 100, 100, 20, 20, 310, 310, 140 };
    static const U32 BW_PRESET_2000[TC_EOF] = { 200, 200, 25, 25, 450, 800, 300 };
    static const U32 BW_PRESET_10000[TC_EOF] = { 1000, 500, 25, 25, 1450, 5000, 2000 };

    (see the linden/indra/newview/llviewerthrottle.cpp file in the Cool VL Viewer sources)

    Note however that these are just clues for the sim server, and as I understand it, the latter is the one making the actual decisions.

    It would also be about time to kill the ”Texture” and ”Asset” slots, in SL (not in OpenSim !), since those are now all transmitted via the ViewerAsset capability in SL...

    Oh, and ”Cloud” messages were removed years ago, too, from SL (I am now generating them viewer side, in the Cool VL Viewer, so that I can still enjoy Classic Clouds in SL).

    • Like 1
  18. 15 hours ago, Zalificent Corvinus said:

    I mean, it's only been 30 or so years since keyboards were improved to have those, right?

    Damned right !... I never understood why some people insist on and keep using those keys to move around in games, when the right-handed cursor keys are so much easier to access (well, maybe they are left-handed people only ?).

    Not to mention WASD only works on a QWERTY keyboard... 😛

    • Like 1
  19. 6 hours ago, LillthNightSide said:

    okay  i have the log file up what am i looking for now?

    Look at the ”WARNING” message lines, starting from the end of the log file: anything about the network, the inventory, for example ?...

    Also, providing the log file as an attachment to a FS' JIRA would allow FS devels to better/faster diagnose any specific bug.

    Oh, and by the way, my link to find the logs in my former message did not really apply to FS (which uses a custom folder for logs instead of LL's viewer standard log folder). See this article about where to find FS' logs.

  20. 8 hours ago, Monty Linden said:

    They were handing out router/modems with shoddy firmware.  Trust but verify.

    I do not trust the least my own ISP's Internet box: I got it configured as a (pseudo) bridge, i.e. its routing firmware is disabled, and I am using a Linux firewall/router between it and my local network...

    Yes, I am paranoid, and proud of it ! 😜

  21. 22 minutes ago, Monty Linden said:

    Might take more than 50 in .eu and beyond.

    I tried with 100... It takes forever and never reaches the host.

    I also tried with the -A (TCP ACK) and -F (don't fragment) options, but still no joy... It would be so much simpler if LL's sim servers were configured to accept ICMP pings. 😜

    • Like 1
  22. 19 hours ago, Monty Linden said:

    sudo tcptraceroute -m 50 <simhost hostname or IP> 12046

    Not here (and under genuine Linux):

    root:~# tcptraceroute -m 50 simhost-0af4b368836ec81c2.agni.secondlife.io 12046
    Selected device eth0, address 192.168.1.2, port 45583 for outgoing packets
    Tracing the path to simhost-0af4b368836ec81c2.agni.secondlife.io (35.89.194.181) on TCP port 12046, 50 hops max
     1  * * *
     2  * * *
    .../...
    50  * * *
    Destination not reached

    I also tried with port 12043 (the one used for capabilities), to no avail...

×
×
  • Create New...