Henri Beauchamp

What signature ?

You know, using the debug settings floater to set huge numbers serves no purpose: the number of particles is limited (clamped) in the viewer code to 8192, because they must fit a single vertex buffer, which size is also limited... Most other render settings are also clamped (if they were not, you'd get magnificent crashes): use the graphics settings sliders and spinners to set the parameters. And 64m DD now ? And still no info about your hardware...

With what hardware ?... I always had them set at 8192... Never experienced particles-related crashes either, even during griefings. If your PC cannot render 4096 particles, then you have a problem... And particles are important, for chains, ropes, etc (with this clue you can tell what places I frequent 😄)... OK, so here is what I get at the exact same place as yours, but with all graphics settings pushed to the max, including Classic Clouds on (something other viewers do not have), meaning even more (giant) particles, mesh boost factor to x3 (again a Cool VL Viewer exclusivity), no impostors, no limit on avatar complexity (and one other avatar in close FOV), all shadows, etc, and 512m draw distance: 46fps, i.e. over twice your figure, but since we do not know what is your hardware (mine is listed in the About box you can see in the screen shots)... And with 256m draw distance: 118fps... But like Rowan remarked, since there is almost no objects to see there, this is largely non-significative a benchmark !

Glad to see linsket data back to the RC sims this week, however the release notes page for this release is missing:

A well known race condition bug (between the receival of the interest list sent by the server, and the viewer pipeline spatial groups refreshes/rebuilds after an agent sim change)... The Cool VL Viewer got an automatic ”objects visibility refresh” feature, that gets triggered a few seconds after login, each TP and each sim border crossing, to work around that bug; you may also toggle it manually with ALT SHIFT R (sort of an ”objects rebake”). Another known bug (or rather ”odd feature”, put into place to fight griefing objects, most likely), due to the maximum node size (in number of vertices) of a spatial group: when it overshoots the maximum configured value, the whole group is skipped from the rendering pipeline; this is seen in mesh-heavy places, when too many highly detailed objects are grouped together. You may increase the ”RenderMaxNodeSize” value to fit them into the node and get them to render. Try 65536 or even 131072 KB. Of course, the Cool VL Viewer also got a workaround for this (via a ”mesh boost factor” setting).

You could actually script that, using Lua, with the Cool VL Viewer... 😛 For example, I have a a small bit of Lua code that I can activate (via a Lua side bar button in the UI) to automatically adjust the draw distance (between 256 and 512m, by 32m step) to keep the fps rate between 60 and 120 fps: I use it while sailing/boating so to get the optimal draw distance and see as far as possible when along coasts or sailing across a channel (with few objects in the FOV), without getting a bad fps rate when sailing towards and approaching coasts close.

OpenGL and Vulkan do not do things exactly alike... I'm pretty sure it would be possible to achieve a better AA quality in deferred rendering with OpenGL, but the current shaders (be it FXAA or SMAA) just cannot do it...

Pictures and videos are better than just words, since most people (and me among them) will only believe what they can see. Let's first deal with the anti-aliasing problems in deferred rendering mode (ALM), which is the main reason why I (and likely many other SLers) am not using ALM, most of the time (while my PC is plenty-powerful enough): Here are three pictures, taken in Port Babbage, where you can see the masts and rigging of pretty ships disfigured by ALM: ALM + FXAA (LL's AA shader) ALM + SMAA (Alchemy Next's backported shader) Forward rendering (native 4xSSAA). As you can see, only forward rendering is capable to render properly the thin edges that make up the masts rigging... FXAA is also so blurry, that it is right out unacceptable (it blurs the details in the textures themselves), while SMAA only blurs the edges (which, sadly, also blurs a bit the edges inside textures with transparency, such as tree leafs in a foliage texture, for example). (*) Now, here is a video that also demonstrates another extremely annoying artifact induced by anti-aliasing (both with FXAA and SMAA) in deferred rendering, and which appears when you move around; I call it ”edges wobbling”, and it is right out ugly, like you will see by watching this video (note: since it's hosted on my ISP's site and I have to respect a quota, it will likely be removed in a few weeks). As long as LL will not come up with a solution for these annoyances (TAA, perhaps ?), I am afraid ALM will stay off 80% of the time for me (I only use it where it makes sense, i.e. where there actually are some interesting materials to see). ----------- (*) Users with a high DPI screen (120 dpi and over) are of course less likely to see/notice the blur, but with a 92 dpi screen (such as for a standard Full HD 24” monitor), the blur is obvious (and unacceptable).

It is not more ”outdated” than turning off shadows !!! This is just a graphics setting, damned it ! Do you realize how totally illogical and nonsensical (and egoistic) is your reasoning ?... Basically, you say: ”hey, I'm creating super nice shiny stuff with materials and all, so I demand that everyone runs with ALM on because I want them to see all my shinies, always, even 150m away, even if they can't actually see them because they are outside a building in which my shines are, and I do not care if their Second Life becomes miserable as a result, because they would run at 8 fps instead of 25 (1) !” This is exactly like if you were a mesh trees creator who had worked very hard to obtain super-nice shadows and were demanding that everyone turns shadows on to be sure everyone will see your pretty shadows, even if they are actually never using SL in outdoor settings (where your trees are), and even if they run at 3 fps as a result !!! Beside, and mind you, I rarely ever use ALM myself, and not because it would run at lower fps rates (it actually performs slightly better in some scenes), but simply because I rarely use SL in places where there are materials around, or where they would actually matter or make any visible difference, while for these use cases (outdoors in main land, for example), I really can benefit from a better AA (2) and a lower texture memory consumption to increase the draw distance, and this by using the forward rendering mode. I turn on ALM only in places where it does matter (a club, for example, where a lot of avatars are wearing stuff with materials, or some scenic sims making heavy use of ALM in their buildings). It's just a matter for me to type CTRL ALT D to toggle it on or off in my viewer, and I can immediately see whether it is desirable or not. It's my choice for my various use cases, and I deny you or any one else the right to impose me how I should setup the graphics in SL ! (1) And yes, that's exactly what you get with an iGPU or an old card. (2) ALM's FXAA is just plain sh*tty, and SMAA which, AFAIK, is only available in Alchemy Next and the Cool VL Viewer, is just acceptable for textures (it does not blur them, unlike FXAA), but is no better than FXAA for anti-aliasing objects in the distance and/or while you move around. You have to understand that some people just cannot afford to upgrade a 5 years old computer (no need to go 10 years backwards to find GPUs that run ALM like sh*t, not to mention iGPUs), or even to buy anything else than an entry level computer without a discrete GPU (that, too, will run ALM like sh*t, even with a ”modern” iGPU). You also have to understand that no, ALM does not always look nicer than forward rendering (AA is sh*t in ALM, period), and that some use cases (that are far from being ”niche” ones) benefit from turning ALM off. This is true even with a modern gaming computer. Should LL manage to raise ALM quality and add a toggle to turn off materials in the distance to save texture memory, for example (since they don't matter when seen from far away), then it would allow me (and many others with good computers) to indeed keep ALM on all the time; it's simply not the case for now ! It's tough as well for users, if they can't run with decent performances and/or good rendering quality with ALM on. You are not in control of what people can afford as a computer to run SL... And I'm pretty sure that you'd rather see them buy your stuff instead of using that money to upgrade their PC... 😜 You must understand that the ”choice” they make by turning ALM off is not a true choice, but the result of a compromise; if the drawbacks for enabling ALM are just unacceptable (be it because of the PC power or because of a particular use case), I do not see why we should impose them.

This is selfish because, by removing the choice to turn off ALM in order to be able to run the viewer better (or at all) for a particular use case (or for everything, depending on your PC), you simply exclude people from SL or degrade their experience in their particular use cases, and this just because you (and some others) think that everyone shall see the same thing on their screen: this is visual dictatorship ! I also do not see how leaving a simple choice (just like you have choice to turn shadows on or not in ALM) could be at all harmful or holding back SL's development !!! You know me better than that, and you perfectly know that I am an eager early adopter of all new shiny features (just look at the Cool VL Viewer and how fast I backport every new feature to it: no other TPV is updated faster to integrate new stuff; the last one was Puppetry, that I released only a week after LL got a RC viewer out !). However, I am also totally unforgiving towards regressions (for example, the anti-aliasing quality in ALM, even with a SMAA shader to replace LL's FXAA, is just too poor for my taste: it looks plain ugly when compared to genuine 4xAA in forward rendering). I also am very worried that raising the bar in terms of computing power (*) will just reduce the SL users base. I do not demand to stop developing SL (much to the contrary), but I demand freedom for everyone to use SL as they see fit, with the PC they can afford to buy ! As it is, removing the forward renderer is an impairment to SL adoption and user base growth. --------- (*) and on an especially bad timing, with computer parts having reached astronomical prices during the COVID and not even returning to their ”normal” price now, as well as with the inflation and the energy crisis, that will deter people from buying non-essential goods such as a new computer or video card to play in SL !

Failed, apparently... Still no trace of LSD on the main grid (I just tested the RC sims sandboxes too, in Agni, just to be sure)...

So, basically, you tell people not able to afford a gaming computer, or simply having a different usage of SL, where materials do not matter the least (and no, sailing and flying are not ”niche” activities in SL, by far !): sorry, but SL is not for you ! Congratulation, for the most selfish contribution to this thread !!!

The problem is about both, but yes, even looking forward and ”forgetting” about ”poor” existing SLers that cannot afford upgrading, what LL must take into account is how to broaden its user base, i.e. attract more users, including non-gamers who do not own and cannot either afford a gaming computer, thus why I think the forward renderer is important to keep around... Unless proven wrong by Dave Parks, in case he would succeed to code a deferred renderer that can outperform the forward renderer even on iGPUs (but seeing the first alpha PBR viewer, and even accounting for the fact ”poor performances” and ”missing occlusions” are among the ”known issues”, I very much doubt the final version will come close to what the current forward renderer can do).

This got nothing to do with preserving the forward renderer, even though the latter would allow an easy path towards ARM and mobile support thanks to the fact it does run with OpenGL v2.1. Reread this. Note also that OpenGL v1.x and 2.0 are not supported any more, even in current viewers: it has been years their support got dropped. OpenGL v2.1, on the other hand, is what most ARM64 platforms support (including Chromebooks)... Preserving the compatibility with it would be an opportunity to get a real viewer (and a free viewer too, like in free beer) running ”soon” on mobiles, and even perhaps under Android... AGAIN, the forward renderer advantages over ALM are: Easy on GPUs: it can work decently on any modern computer, including notebooks without a discrete GPU. This keeps the entry level for SL as low as possible, and prevents people without a gaming computer to give up on it on the first login. Better, even on modern gaming computers, for moving around SL (flying, boating, driving) across sims, with a waaaaaay better AA quality, less memory used (important when you need to push the draw distance to 512m, while flying or sailing, for example), most often better FPS rates (yep, even with a modern GPU, in these circumstances, i.e. with a large DD and few close avatars around), faster textures rezzing (less textures to download while moving around: super-important, when you move fast !). Lower power consumption (= larger autonomy for notebooks), lower heating (= no throttling on cooling challenged notebooks, e.g. Macs M1/2), lower fans speed (= much less noise).

I shared it already in several links that you will find in my above posts, in this very thread...

This makes no sense to maintain two different branches of their release viewer for LL. And no, it's not just about old computers compatibility, but also about most modern (non gaming) notebook computers (that only got an iGPU or APU to render, not a discrete GPU, and are therefore no better than a GTX460, or even weaker), as well as future mobile support (think ARM-based devices, Chrome-books, etc). The cost for simply freezing the forward renderer as it is and keeping it along the evolving PBR renderer is close to zero: just a matter of keeping some shaders and adding some branching in the code to cope for C++-level differences. I know first hand, since it is exactly what I did for the v1.28.2 branch of the Cool VL Viewer which had both the WL and EE renderers (and switchable on the fly, by just checking a box in the graphics prefs too) !

This has been the case, for years, in TPVs, which all increased the VRAM usage beyond the 512 MB LL stubbornly kept as a limit in their viewers for years...

And from the release notes: Just one word: OUCH ! I am afraid that, despite my warning ( ”I do really hope the same mistake will not be done with the future PBR viewer, i.e. do take your time” ), LL will be trying to push PBR too soon to ”release” status, with the same ill effects seen as when they pushed EEP while its renderer was still full of bugs that only got solved with the performances viewer, months later... 🙄 Dave Parks replied to my worry with: Seeing as they release a ”public alpha” now already, I have some doubts that only six more weeks will be enough... *sighs*

I suppose that this body got several (onion) mesh layers, one used for the ”diffuse”, and another for the ”material” (which itself would have a diffuse texture, of course). This would be an alpha-sorting issue with rigged meshes and I'd rather suspect an issue (bug) with a reverted commit LL pushed last week. The (now reverted) commit was supposed to fix alpha-sorting in the performance viewer to restore the ”legacy” alpha sorting, but it caused other issues due to a bug in its implementation (seen with some mesh heads). I fixed that latter bug, and proposed that fix to LL, but it was not yet picked up, so far... The Cool VL Viewer should render your body just fine (like Firestorm which did not yet pick up the revert from LL, but without the bug that likely impacts the latter with the said mesh heads).

You should read again what I wrote about progress and regressions. I am in no way adverse to progress (this is actually the exact opposite, being an eager early adopter), but I cannot stand regressions and should some new shiny feature appear that got drawbacks, then I want to be left the choice to enable that feature or not, depending whether the said drawbacks are becoming unacceptable in some specific conditions or use cases. I am not asking to hold back ALM and PBR changes, but just that the final user is left a choice, since the picture quality and the required computing power are both drawbacks that can impact badly the said users... I want choice, and will never, ever accept being shoved negative things down my throat. That's why I made the Cool VL Viewer, by the way... 😛 Oh, and about: Please, re-read: ”when you move around in a sim or sail near coasts, or fly over land”... That is, with a ”normal FOV”... Not zoomed out 200m away !

Yes, because you choose a scene with many spot lights and then zoom out in a way that nobody would normally do, to encompass even more spot lights, meaning the difference between deferred and non-deferred modes becomes ”dramatic”. What I am pointing out is that in normal outdoor scenes conditions, (e.g. when you move around in a sim or sail near coasts, or fly over land) ALM is more an annoyance than anything else; first and foremost it blurs details in textures themselves with LL's FXAA shader, and even with SMAA (which fixes this issue), it causes ugly artifacts in (sometimes not so) distant grillage meshes, rails, windows, etc. Then it causes a higher memory usage for textures (since it loads the ”normal” and ”specular” channels textures in excess of the ”diffuse” texture), which in turn can cause the viewer to use a degraded level of detail on the objects textures to fit them all in VRAM, causing even more blur (and the annoying alternating blur/un-blur effect on some objects). Do not take me wrong: I am not against progress and would definitely love to see all the ALM shinies without all the blur and artifacts, but it is just not how things (currently) work, thus why I almost never use ALM myself while my computer renders it even faster than the forward render mode in most scenes.

Then without ALM: Notice the much sharper picture (the sign, the lanterns, the leaves on the ground, etc). True, you got less (spot) lights than with ALM on, but frankly, the difference is not as dramatic as what you pretend !!!

Quite dishonest snaphots... Here is what I get over there, First, with ALM & FXAA shaders (LL's shaders): Notice the blur on the panel (you can hardly read the sign with ”Game room”, ”The barn” and ”Train station” so much it is blurry). (next screenshot in next post, because there is a 4MB limit on attachment, and we need full resolution PNG pictures, not JPEG-degraded, or downsized screen shots, so to compare properly).

It is barely passable, but bear in mind that I purposely pushed the graphics settings way beyond the ”recommended” ones for that hardware (which, again, was weaker than the one that was supposed to ”run modern SL like garbage”), on a large screen (larger than standard ”full HD”, since mine is a 16:10 screen, i.e. 1920x1200) and with a large draw distance (256m)... The idea was to see how far I could push things while keeping the frame rate over 25fps. I never said that I would recommend running SL on such a hardware (neither would I on any iGPU-based system, which are even weaker than a GTX 460) if you can afford better, but if you can't, it still can do the job ! I beg to differ... Windoze is a PITA !!!! It is slooowww, vulnerable, unstable. Today's Linux distributions are not harder to install, configure and use than Windows; they are also far easier to maintain (updates are so easy and take only a couple minutes every month when Windows needs half an hour and breaks almost once every three updates). Here again, I beg to differ. Read my prose here, especially about anti-aliasing, which is plain ugly, unless you run Alchemy or the Cool VL Viewer with the SMAA shader to replace FXAA, and even then, it's much less pretty than native 4xAA with the forward renderer.

Good news ! This bug got (finally) fixed in Wine v7.20 (tested with a Cool VL Viewer binary linked against boost v1.80).