Henri Beauchamp

This was due to NVIDIA driver viewer profile under Windows (see BUG-234706) that lacked the enabling of the OpenGL ”threaded optimizations” which can easily bring +50% in frame rates. If you are not running the viewer under Windows, or do not have an NIVIDIA card, or already had its driver configured for system-wide threaded optimizations, then you won't see any difference in performances.

Sadly, in its current state, the PBR viewer is a BIG step backwards for sailing, with ugly sky-blue water and broken water reflections (WL waters looked way nicer, including with just ”minimal” reflections, i.e. all but sky turned off)... Another of the things among the many rendering glitches that should have incited LL to keep the PBR viewer in a RC state a little longer. 🫤 Let's hope they will fix waters quickly so that we can again enjoy sailing on SL seas !

”Why” is a very poor choice of a forum topic... 🫤 What you are hearing is a collision sound, here triggered by your avatar's feet on each of the steps of the stair. The fact you can hear such sounds on some stairs and not others, depends on the physics hull (the mesh taken into account, server-side, by the Physics engine of SL): in this particular case the hull is likely the same as the stairs (rendering) mesh. Some creators will create a physics hull with a plane placed on top of the steps instead, preventing to physically ”bump” into each step. If you get annoyed by collision sounds, you may disable them in the viewer (depending on the viewer, this can be found somewhere in the Preferences floater, or at worst, via the debug settings as ”EnableCollisionSounds”, which you can toggle to FALSE).

This won't work for real-time mesh baking. This is for games with pre-defined assets, not for SL... Plus, it's closed source and a commercial (paying) software. Note also that the SL viewer does make use of (moderate) mesh optimization (see LLVolumeFace::cacheOptimize()), itself recently updated to use meshoptimizer, but this optimization step, happening each time a new mesh is loaded, won't combine meshes together...

In fact, there are three implementations... In order of appearance: Marine's, mine (*) which is very close to Marine's, and Kitty's RLVa. (*) The Cool VL Viewer (or rather Cool SL Viewer as it was named back at that time), was the first TPV to implement RLV after Marine's; it was back in November 2007, and my fork started as v1.00a (a fork from Marine's RLV API v1.00) in the Cool SL Viewer v1.18.4.3. The fork diverged over time in the underlying code/implementation, but still implements/obeys Marine's API (with some additions of mine).

Monty is making mention of BUG-234561. During the AISv3 protocol update which was necessary to implement inventory thumbnails, the legacy UDP message for creating inventory links got somehow broken server-side. In the event the limitation you are seeing in Catznip would be related to this breakage, it would be possible to ”fix” the viewer code by using AISv3 to create the inventory link instead.

It would be possible, instead, to temporarily (while it is edited/selected) override the PBR-bearing face rendering draw info, so to render the legacy texture channels instead. It is a piece of cake, reusing the media texture override (and USE_FACE_COLOR face state) code to do the trick. This is what I am using in my viewer (but the other way around: to render in ALM/forward modes the PBR-bearing materials with missing/default diffuse texture using the base color texture instead). See the LLVolumeGeometryManager::registerFace() and LLFace::getGeometryVolume() in the Cool VL Viewer v1.32.05 sources. The trick to render the legacy maps on the edited face could then be automatically triggered depending on the texture channel combo selection in the Texture tab of the Edit/Build floater... This would avoid having to send messages to the server (to remove the PBR material then reinstate it after editing), and risk a loss in the transmitted parameters due to race conditions or bad network...

I know at least one viewer that lets you see everything (PBR, legacy ALM, legacy forward) without needing to relog... 😛 And guess what... The other PBR viewers could implement a way to see diffuse/legacy material while editing a face (i.e. when the face is selected via the Build/Edit floater), by using the same trick I used in my viewer to render the base color map instead of the diffuse map in non-PBR rendering mode (it would be ”the other way around”, but would work with the same trick at the code level): if TPV devs are interested in how I implemented this, they can ask me, in excess of having a look at my viewer code and incremental diffs...

Thanks. I replaced ”builds” with ”items”, which is hopefully making things clearer/unambiguous.

Entirely seconded. I cannot attend (*) the SL creators user group meetings, but had I attended the last one (for which I could at least read the summary on Inara Pey's excellent blog), I would have loudly opposed to this totally silly statement about providing two different items for PBR and legacy viewers, when all viewers can render (even if differently) a combined PBR plus ALM (or diffuse only) bearing face ! Since this is a Firestorm thread, and Firestorm got such a huge impact in SL given it's enormous user base, let me here beg for FS devels to do what I just did in my own viewer: remove all the limits to edit legacy material and diffuse maps when a PBR material is already set on a face from the viewer code ! Yes, and I did consider doing one-time (on texture fetching step only, so to avoid excessive overhead) baking of a diffuse texture for PBR materials in non-PBR rendering modes; however, I am not a 3D engine programmer, and know close to nothing to shading, OpenGL, etc... So, this would have to be coded by someone else than me. But it definitely is possible; LL could have kept a forward rendering mode with such a backing for PBR materials in their viewer, but they instead opted to ignore people with ”weak” hardware. And you know what ?... Such a diffuse texture baking could even be necessary (or at least interesting/useful/faster) for mobile viewers. And it could even be extended to legacy materials !... Maybe this baking could be done server side, even (at PBR material application time on a face, with automatic generation and applying of the diffuse texture) ? --------- (*) Sorry, but I cannot understand well enough spoken English, and myself ”speak” it (or ”moo” it, rather) in ways that no one would understand either, so voice meetings are a no-no as far as I am concerned. PS: when mentioning my viewer name, please do use the three words making up that name (i.e. ”Cool VL Viewer”), just like you would use the four words making up the ”One World Trade Center” name. 😜 Thank you !

So can the Cool VL Viewer. Eg, under Linux: cd linden/;./linux-build.sh --tracy The Tracy profiler is then started on demand from the Advanced -> Consoles menu, or CTRL SHIFT 8

I would have preferred a ”Why I don't consider PBR ready” subject for this thread... Because, you know, the fact you do not like it is due to how unpolished (pun intended) it is right now, with ugly rendering issues for legacy contents (or vanished shadows, or glitchy/ugly (sky blue !) water surfaces, etc) and glitchy and incomplete UI for editing PBR stuff in the viewer. It is indeed, at best, at ”beta” quality and should never have been pushed to release by LL before all those nasty issues are solved. Sadly, what is done is done, and we will now see PBR contents starting to be sold by creators, with prerequisites (such as custom environment settings) that will make that contents incompatible with future fixes (e.g. a ”fixed” EE setting to stop shiny surfaces to appear blue will become a handicap after LL will finally fix that bogus blue shine that also ruins shiny legacy contents anyway). However, PBR, in itself, is a good thing for the future of SL. It is simply just as disruptive as Windlight has been when it got introduced (excepted that Windlight did not ruin the rendering of legacy contents), especially the PC power required to render it... Yet, would you consider, today, that Windlight was an error and has ruined SL ?... I doubt so !

I already explained it to you, in this post. Simply increase the ”RenderMaxNodeSize” debug setting (start with doubling it)...

If the PBR viewer cannot find the corresponding PBR-related capabilities and does not get the sim message for PBR materials and objects updates, it will just render like if there is no PBR object in a SL sim (or during the transition, when only a few SL sims had PBR enabled and you could yet use the PBR viewer everywhere). This is not a problem.

I explained it in this previous post.

If they exist on another object without a PBR material; this is normal... There might also be a possible race condition happening on login (when PBR materials data has not yet been received), or because of the object cache data for that object (did you wipe out the object cache as well ?). Anyway, when not in use for rendering, a texture will end up being evicted from memory (and VRAM).

PBR materials presence and reference (material UUID, face index) is transmitted via a new Extra Parameter (like for flexible, lights, sculpts, meshes, etc), in UDP Object Updates messages; this also includes reflection probes data for reflection probe objects. The PBR materials data itself (texture maps UUIDs, PBR factors, scales, offsets, rotations) is transmitted separately (and sometimes before the UDP object update message) by the sim via a new UDP message. This data is also cached on disk by PBR viewers, as an extra object cache file (one per sim, like for the object data above). PBR maps (textures) are fetched on demand, when the object is rendered, via HTTP fetches (like for other textures), via the CDN assets server. The textures themselves are only fetched when in use: if your viewer is a PBR one, it will not fetch the legacy material textures for faces also bearing a PBR material. But the data associated with the object itself will still contain a few fields (UUIDs, texture entry index = prim face, diffuse texture scale and offsets, etc) dealing with legacy materials.

Come on ! 🤪 You said 60fps in ALM with shadows, and in the very simple scene I benchmarked, I hardly pull 20fps with shadows and without SSAO from the GTX 460. Short of testing in a skybox or an empty sim, there is no way you'd get 60 fps with shadows on. Period !

Too much Champagne...

They recently changed the code to not rez avatars with partly rezzed meshes attachments. This got nothing to do with PBR, and I personally find it annoying (you risk bumping into people just because one of their meshes did not yet rez and you can't see them at all, or they can stay unrezed forever if that mesh fails to download)... I therefore won't adopt that change in my viewer. 😛

I re-did the tests I had done a few weeks and months ago, using my ”potato” computer (which was considered quite decent a gaming computer back when I built it): Core2 Quad Q6600 CPU OCed @ 3.4GHz with 8GB DDR3, GTX 460 (Gigabyte GV-N460OC-1GI) with 1024MB VRAM, 1920x1200 24” monitor. Sadly, this PC is ”too weak” to record a video while doing the viewer benchmarking (it would too badly impact the frame rates), so I could only take screen shots as proofs, but you are of course welcome to redo the tests by yourself if you still do not trust me ! I used Second Life maintenance viewer v6.6.17 (pre-PBR), Second Life release viewer v7.1.2 (PBR), Black Dragon v5.0.3 (PBR; I did not find a pre-PBR version of BD), and the Cool VL Viewer v1.32.0.4 (dual renderer). All viewers were tested under Windows 11, and the Cool VL Viewer (the only one with native Linux builds among them), was also tested under Linux (but I forgot to test shadow modes... Drat !). The benchmarking conditions and protocol are as follow: CPU and GPU locked to their maximum (OCed) frequencies, all energy saving features turned off. Viewers in windowed mode and their window maximized (same size for all viewers). GL/GPU settings set to core GL profile, anisotropic filtering on, FSAA in 4x mode. The NVIDIA OpenGL driver is configured to use threading, V-sync off, triple buffering on. Texture memory setting (GL bound texture memory for Cool VL Viewer) set to 512MB so that the viewer won't spill vertex buffers and GL textures over to the RAM (which would tremendously slow it down), while using as much VRAM as possible. All benchmarks made in a single place, in front of my shop in Hunburgh, with just one avatar on screen (my alt avatar, a potato legacy avatar too !... You won't tell the conditions are too stringent, this way... 😜). Draw distance set to 256m (the same draw distance I always used, including in the old days when this PC was my brand new one). Environment setting set to midday (legacy version, i.e. without PBR auto-adjust). Camera settings set so that all viewers got the same FOV (and the same objects to render). All rendering settings common to all viewers set at an equal value (and the ones that are specific to a given viewer are disabled). In particular the LOD factors were set as follow in all viewers: Objects (volumes) LOD to 3.0, Linden trees LOD to 3.0, Terrain LOD to 2.0, Avatars LOD to 1.0, Avatar physics LOD to 0 (off), jelly dolls off (no complexity limit), max non-impostors set to 10 (16 for the Cool VL Viewer: I just remarked this discrepancy, but it is not really a problem with just one avatar on screen). Each time, the viewer in benchmark was started and left alone until it settles to a stable frame rate, with all textures loaded (verified via the texture console). Here are the results (note that the quoted fps rate is averaged and varies in real time with spikes and dropouts by about +/-5%, for all viewers): In forward rendering mode: Second Life Viewer 6.6: 46fps Cool VL Viewer under Windows: 71fps Cool VL Viewer under Linux: 81fps In ALM mode, without shadows (and SSAO off too): Second Life Viewer 6.6: 37fps Cool VL Viewer: 42fps In ALM mode, with shadows and SSAO off: Second Life Viewer 6.6: 23fps Cool VL Viewer under Windows: 28fps (*) In ALM mode, with shadows and SSAO on: Second Life Viewer 6.6: 20fps Cool VL Viewer under Windows: 22fps (*) In PBR mode, without shadows (and SSAO off too): Second Life Viewer 7.1: 27fps Black Dragon: 34fps Cool VL Viewer under Windows: 36fps Cool VL Viewer under Linux: 43fps In PBR mode, with shadows and SSAO off: Second Life Viewer 7.1: 20fps Black Dragon: 25fps Cool VL Viewer under Windows: 27fps In PBR mode, with shadows and SSAO on: Second Life Viewer 7.1: 17fps Black Dragon: 18fps Cool VL Viewer under Windows: 21fps (*) In this test, SMAA and CAS shaders were also activated in the Cool VL Viewer, to replace FXAA and provide a sharper render. As you can see, at no time any viewer has been capable, in this rather simple 3D scene, to render at 60fps with shadows on ! You can also notice how badly deferred rendering (ALM and PBR shaders alike) does impact the frame rates with this kind of old GPU (the same impact, or even worse, is seen with iGPUs, even newer ones). With the Cool VL Viewer (which C++ highly optimized code shines brighter when less time is spent rendering with the GPU), the forward rendering mode is about 60-70% faster, when compared to the shadow-less deferred mode (ALM and PBR alike, here as well). But even LL's poorly optimized pre-PBR viewer can gain 30% in fps rate by simply switching to the forward rendering mode... Here again, this is specific to old GPUs and (pretty much all) iGPUs, since for modern GPUs, ALM/PBR is almost always as fast or faster than the forward mode. Finally, there is the problem of the VRAM usage: have a look at the textures blurriness in the screen shots, and in the Linux directory, to the CVLV-*Params.png screen shots, showing the texture console (look at the Bias value): the ALM mode eats up a lot of VRAM, and PBR is even worse in this respect, sometimes causing texture trashing (even in such a simple scene) on old those GPUs with less than 3GB of VRAM or so... My conclusion is simple: for PBR (or ALM in pre-PBR viewers), you must have a modern enough PC and a discrete GPU with as much VRAM as possible. The minimum requirements for SL PBR viewers should be changed to: 4-core CPU, preferably with SMT. 16GB of RAM. GTX 960 or equivalent.

Well, I do have a PC (the ”fourth” one, in term power, among my still running PCs), with a Core 2 Quad Q6600 OCed @ 3.4GHz, and a GTX 460, and I can assure you that it won't run at 60 fps in ALM in any of today's SL scenes (clubs, scenic sims, or even just outside of my shop in Hunburgh, facing my little forest of trees) ! If you need proofs, I can do a few captures, to demonstrate... But not today and now, obviously (soon Champagne time for me !). 😜 Please, keep in mind that what you were rendering back in 2012 got nothing to do with what you got today to render in SL ! Also, on this PC, you can see the major impact of ALM (or PBR alike, with the latter not being slower, but using more VRAM, which in the end leads to blurry textures), compared with forward rendering, which is twice as fast !

But then, you should use EEK ! 🤣

That's what I meant when I wrote: ”it will still require months to reach a proper and acceptable status”. The current rendering discrepancies (compared to the old renderer) when rendering legacy contents are just unacceptable, just like is unacceptable the fact you need to change an EE setting (*) to avoid seeing legacy shiny contents rendering blue. This will need fixes: SL (and SLers) cannot afford throwing away the immense legacy contents base (it would mean restarting SL from scratch !). ---- (*) EE = Extended Environment. Loose the ”P”, people, the ”P” was for ”Project”, and it's now been years EE is no more a project... 😜

1.- My viewer is using a modified v1 UI: it is not a clone any more, but it is indeed a fork. 2.- It is amusing to see how the ”sucking” aspect changed over years... Back in v2-viewers days, v2+ sucked big time and v1 was wonderful. Well, indeed, v2/3 sucked big time, and v4+ (CHUI viewer) sucks (much) less... but you know, improved-v1 does not suck that much either... 😜 One word of advice, from a now old fart (woot ?.... six decades already ???... 👴 But I'm not that old yet, at least not in my mind ! ) : try before rejecting. You might be surprised, sometimes (not always, of course), how prejudices can blind you ! And to get back to the topic of this very thread: it also holds true for PBR: 1.- Yes, PBR is good, because it paves the way to the future of SL, with adoption of a standard (GLTF) which is already widely in use and will become a ”must have” in the future. It also will make SL even more beautiful... in the end. 2.- Yes, PBR, right now, is definitely not ready in SL, and has been hastily pushed to release when it will still require months to reach a proper and acceptable status. It also badly impacts residents with a ”weak” computer, who sadly got little options to keep enjoying SL with acceptable frame rates and usability until they can afford upgrading their PC. But point #2 is transitory (and, incidentally, I provide at least one option for the transition period), and #1 is what will count, in the end: let's make a deal and get back to the subject in two years from now (my bet is that PBR glitches will not be fully resolved before mid-2024, and it will require one more year before everyone can run PBR with a powerful enough PC), and see how things will have evolved (including our respective points of view). 😉