Henri Beauchamp
-
Posts
1,295 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Everything posted by Henri Beauchamp
-
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.
-
Second Life updater fails on Linux under Wine - cause found
Henri Beauchamp replied to animats's topic in Second Life Viewer
Good news ! This bug got (finally) fixed in Wine v7.20 (tested with a Cool VL Viewer binary linked against boost v1.80). -
You said a GTX 600 won't be able to run SL. I demonstrated that even a GTX 460 (with an old quad core CPU) can. Period. I won't loose any more my time with you since, obviously, you cannot admit it when you commit a mistake. 🙄
-
Come on... Can't you admit you are plain wrong ?.... Do I *really* need to post more screen shots for proofs... 🥱
-
Wrong ! With the Cool VL Viewer and under Linux, I can run SL just fine on my second computer (2500K @ 4.5GHz + GTX 660) and even on the third (Q6600 @ 3.4GHz + GTX 460)... Of course, not with ALM for the latter (too slow), but still at 256m DD in main land. Here is the proof: Picture taken on main land (at Horizon info HUB, that is a HUB with neighbouring sims) with that third, super-old computer and its GTX 460. Draw distance is 256m and most graphics settings maxed out (4xAA + anisotropic filtering too), 16 avatars in the FOV, all 16 as non-impostors. Look at the FPS rate in the upper right corner: 27 fps. Of course, ALM totally kills that frame rate (down to 8 fps in this setting), thus why I am advocating for keeping a forward rendering mode for the future PBR viewer: ”weak” GPUs, such as even modern Intel iGPUs will need it !
-
But those garbage Intel iGPUs would be incapable of running SL at decent frame rates, be it under OpenGL or Vulkan... That 30% figure you cite also seems largely exaggerated (or more exactly, skewed) to me, and probably due to the fact that LL relies on a (relatively) new stats info transmitted by the viewer, which is supposed to detect whether the Vulkan driver is installed (and configured) or not... Many of the viewers reporting ”no can do” are probably fooled by the lack of proper driver on an otherwise perfectly Vulkan compatible computer (GPU), not to mention viewers that do not report any such stats. But even 10% of SLers loss would be devastating for SL, especially among ”old timers”. As I already wrote elsewhere ”we need old timers to stay in SL and newcomers to find a renderer mode in the viewer that works with their computer, even if it is a little too weak for “comfortable SLing””. I (and LL alike, you can bet) would also rather see SLers spend more money in SL than in buying a new computer just be able to keep SLing !
-
I doubt very much, that once ”those 30%” would have left by lack of proper hardware to run SL, you could grow the remaining user base by 43% to compensate the loss (100 * 30 / (100 - 30)). Come on, we are not in 2006-2007, when SL's growth was skyrocketing. Well, the current prices that go with ”appropriate” hardware are not exactly cheap (especially in the GPU department)... Not to mention the two digit inflation figures in most countries... You can bet that many people will save money by prolonging their current computer life, so you can expect even more ”old computers” in the coming years ! This said, a dual renderer viewer (OpenGL + Vulkan) would be doable...
-
There are two kinds of scripted sound sources: llPlaySound() ones, which are ”linked” to the object running the script, and llTriggerSound() ones, which are still triggered by an object but not ”linked” to it. Sounds linked to an object keep playing for as long as the object stays in the viewer objects list, while triggered sounds keep playing as long as the trigger gets received from the simulator. Both sounds are subject to the relative position of the auditor (when it gets ”far enough”, the sound is faded out), but the ”linked” sound is also subject to the field of view (FOV) of the auditor: when not (or no more) in the FOV, the object is not (or may get removed, after a delay) from the objects list kept in the viewer, and when the object is not in (or vanishes from) that list, the ”linked” sound is not (or no more) played. This may happen for playing ”linked” sounds when your avatar turns around, for example; after some time, and depending on the object size, the object (which is no more in your FOV) may get removed from the objects list (so that the viewer got less work with that list and can render at a higher FPS rate)... That's why some sounds keep playing, while others may stop until you get their ”linked” object back in your FOV...
-
Not an issue for SL viewers, but there are differences, especially in the highly threaded applications department (such as parallel compilation, which I do a lot every single day), where the RAM usage is very high on every CPU core... Frankly, I won't invest in a DDR4-only MB or even in a dual DDR4/DDR5 one, the latter also meaning you ”loose” two RAM slots when you want to increase the RAM in your system when compared with a 100% DDR 4 or 5 MB.
-
I am, too, planning to upgrade my main PC (9700K @ 5.0GHz on all cores, 64GB DDR4) for a newer CPU (and motherboard, and RAM, since these will also need updating to match the new CPU socket and memory controller)... This means a very significative investment (CPU + MB + 64GB DDR5), with hardware prices still very high (much higher than in 2019, before the COVID)... So far, I had planned to go the Zen 4 route, especially since I do not like at all the mixed cores (P+E cores) architecture of Intel's newest CPUs. Also, given the high price to pay for that upgrade and for it to be worth that price, I need a large improvement on performances when compared to my existing system (and not only for SL, but also for tasks I do daily, such as compilation of very large software), so I need at least a 12-cores (true cores, not SMT ”threads”), meaning a 7900X is what I first had in mind... But given AMD's new CPUs prices (+100 euros or so for a Zen 4 compared with an equivalent Raptor Lake), I am starting to consider a 13700K. The 13900K is nice too, and not much more expensive than the 7900X, but it consumes (and thus heats up) too much for my taste: the 13700K will be easier to cool down and thus will offer a better ”OC” (read: all cores locked on turbo) potential... Since Raptor Lake just got announced, I will however wait (maybe until next year) and see how AMD reacts: competition is good for prices... 😜 True. But if you go the P+E cores route, do make sure your viewer can be configured so that it runs on P-cores (the Cool VL Viewer allows to set the CPU affinity for its main thread, using all other cores for its child threads).
-
Second Life updater fails on Linux under Wine - cause found
Henri Beauchamp replied to animats's topic in Second Life Viewer
1.- You could run natively, under Linux, a viewer with puppetry support. Namely the Cool VL Viewer v1.30.1 experimental branch. Running a viewer under Linux+Wine leads to a massive performance loss... 2.- It is indeed sometimes useful for me to run LL's RC viewers under Wine (this helps in backporting new features since I develop my viewer under Linux), but I have no trouble doing so without bothering with Python stuff. Just delete the version checker executable from the viewer installation directory (the viewer will also likely crash on exit, so better deleting the bugsplat reporter executable as well, since LL cannot care less about Linux+Wine). 3.- Wine people do not seem too eager to fix some bugs when they affect SL; I already have reported a couple that do affect the viewer, but without any result on the bugfix front... One bug is a bad file pointer position reporting on writes without a flush; it is automatically worked around by the Cool VL Viewer which is capable of detecting when it runs under Wine. Another affects boost libraries from v1.79 onward, and it lead me to keep v1.78 for my viewer Windows builds so far (Linux and macOS can enjoy the latest boost libraries); since LL's viewers are still using boost v1.78 as well, they are for now not affected either, but as soon as LL will update boost, LLDiriterator will break (and this cannot be worked around), meaning you won't be able to run the viewer any more under Wine... -
This right is for real persons and identities, not for avatars... At least, LL offers true privacy, i.e. unless you reveal your RL identity yourself to others, no SLer can know who exactly you are in RL.
-
Each avatar got an unique identifier (UUID) associated to it (like every object, item and asset in SL); changing the avatar name won't change the UUID. That UUID is used as an item creation marker (each item you create in SL is marked with your agent Id, the ”agent” being your own avatar, in LL's viewer code jargon). The UUID of your avatar will also be present as the ”last owner” field marker in every inventory item you give away to others. It means that anyone can find you (by UUID) via the items you gave to them (and not only via calling cards that used to be given by servers or, now, created by viewers, when forming a friendship). This is how the whole SL database was designed and works (UUIDs as keys), and LL cannot do anything to change this. Your only option to evade a stalker in SL is to use an alt avatar. But before using that last measure, you may use the mute/block feature, the ban lists, and abuse reporting if they do not prove to be deterring enough for your stalker...
Facebook
Instagram
Twitter
YouTube
Flickr