Henri Beauchamp
-
Posts
1,179 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
3 minutes ago, Rowan Amore said:
This is just not what has been my experience at all. Was on the FS alpha all morning. Did a little test at a club with around 70 people. Rezzed in quickly. Where I would have many increased avatars on the normal viewer, I had avatars that simply did not show at all until they were complete. That was interesting. I was getting almost 60 fps (I have it set to 60 Max) without shadows on. Turning shadows on, I lost maybe 5 fps initially but it soon went back up.
No idea what they're doing differently than the LL viewer but it's encouraging.
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. 😛
-
2
-
-
23 hours ago, NiranV Dean said:
Before my GTX 670 died i had to jump down to my old GTX 460 for a bit until i got my GTX 1060 and (apart from the 2GB VRAM being far too little for SL) the 460 was churning out stable 60 FPS with Deferred and shadows enabled.
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:In ALM mode, without shadows (and SSAO off too):
In ALM mode, with shadows and SSAO off:
In ALM mode, with shadows and SSAO on:
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:
In PBR mode, with shadows and SSAO on:
(*) 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.
-
3
-
2 hours ago, NiranV Dean said:
Before my GTX 670 died i had to jump down to my old GTX 460 for a bit until i got my GTX 1060 and (apart from the 2GB VRAM being far too little for SL) the 460 was churning out stable 60 FPS with Deferred and shadows enabled. This was back in 2022. We are talking about a GPU that came out in 2010 coupled with an AMD FX 6200 which came out 2012. So were are talking 10+ year old hardware. Sorry but there is literally no excuse why after 10 years you shouldn't have something that can run at the very least Deferred enabled (now default) and even shadows if hardware from 10+ years could do it at 60 FPS.
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 !
-
1
-
-
24 minutes ago, Scylla Rhiadra said:
I've always liked ”EEP” because it so well replicates my initial reaction to experiencing it. As in, ”Eep! What fresh hell is this?”
But then, you should use EEK ! 🤣
-
2
-
-
19 minutes ago, Scylla Rhiadra said:
2) It's going to break stuff, despite the laudable effort not to do so. Some objects, and especially some clothing, are going to become all but unusable in the new PBR viewer because they weren't created with the new rendering system in mind. The ones that are no mod can go into the trash can immediately; and because most residents have only a pretty rudimentary idea of how to modify textures, a great deal that might have been reclaimed with adjustment will simply fall out of use. Shiny sweaters, objects that are too dark or too gleaming, are going to be a problem as the use of the PBR-enabled viewers spreads.
3) Among the things that I'm pretty sure, from my own experience, have been ”broken” are our current standard EEP settings. Many of my old EEPs, including the ones in the library, just don't look the same anymore, and not in a good way: they are in particular frequently washed out. SL is starting to look either too bright, or too dark. So either someone is going to have to recreate the standard EEPs (as they did with Midday), or people are going to need to get better at creating their own. People are also going to have to learn that they need to add interior lighting to scenes.
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
-
1
-
-
4 hours ago, Zalificent Corvinus said:
I could try Henri's viewer, it's a V1 clone and the UI therefore sucks
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). 😉
-
4
-
1
-
-
I see no problem with it, as long as the user (the ”resident”, in SL vocabulary) is properly (and prominently) made aware of the use of AI.
Also, there should be an option to opt out entirely from AI interactions (and that would be very wise from LL, given the upcoming regulations regarding AI and personal data).
-
1
-
-
Busy (viewer-coding-wise) !
-
1
-
-
1 hour ago, animats said:
Huh. What are you thinking is missing or mis-timed?
This is a pure logic deduction, I'm afraid... And I see no other possible reason for such an issue.
The problem is that there is too much ”noise” going on when experimenting in a full fledged environment (with sims full of objects) to detect the issue, thus my suggestion for starting with empty sims and see what happens then.
-
5 minutes ago, animats said:
I don't think we'll see this in the viewer traffic. This looks like a sim to sim problem, which we, as users, cannot see.
I'm pretty sure it's a missing viewer message or bad timing/order in message exchanges, on the contrary...
Unless Monty is pranking you and coded some specific server bogus reply when it detects Sharpview. 🤣
-
1 hour ago, animats said:
What's probably needed to fix this is to find four regions on the beta grid where there's a clear corner and very little activity. Then log everything the simulators do while an avatar on a vehicle is moved back and forth across the corner. Then look over the logs in great detail. Somewhere in the sim to sim traffic just before a stall, there will be something of interest.
Ideally, you'd need four neighbouring regions in a square, empty of any object, for a start: then you could try and compare your viewer logs with the Cool VL Viewer's with the proper DEBUG tags activated: you won't have all the objects updates spam then, and would only see those related with your own avatar.
Then, you could see what message is missing from your viewer, or what race condition happens...
-
8 hours ago, Candide LeMay said:
If we had 2K/4K textures, in proper hands
In proper hands, maybe, yes... Thing is, there is no such hands in SL ! 🤣
-
1
-
-
19 minutes ago, Istelathis said:
I think Henri is a witch!
Not a witch, no... A sorcerer, maybe ? 🧙♂️
-
1
-
-
22 minutes ago, Jenna Huntsman said:
So long as LL can nail the texture mipmapping system, the resolution of any given texture wouldn't matter
Thing is, after they would have nailed it (which would beneficial anyway), then you won't see those 2k or 4k textures rendered anywhere at that resolution, but on megaprims with repeats set to 1, or on normal faces with repeats set to 0.1 or such (and the latter would cause a huge memory consumption since then the texture highest LOD would need to be used to get that small part of the texture to render properly on that stupidly scaled down face)...
Frankly, and as I mentioned in my comment on github if you want a sharp 3D render, then you must first tend to the anti-aliasing shader which is currently blurring texture details !
FXAA needs to be replaced with a better shader (SMAA, as a minimum quality): see the Cool VL Viewer in ALM mode, and try the two shaders (not with a small 4K monitor, of course, but for example on a full HD 24” monitor): the difference is quite obvious and you get a sharp picture with pretty textures without any need for 2k or 4k textures !
-
5 minutes ago, Extrude Ragu said:
LL is also currently exploring the possibility of 2K material support, but they want to make sure texture LOD's work so it will still work on old hardware.
This is totally a bad idea !
Creators are already using 1024x1024 textures where a 256x256 would suffice, and now they want 2048x2048 or even 4096x4906 ?...
This would totally kill SL for everyone but people with 16GB or more VRAM and 64GB or more RAM !
See my comment on github about the corresponding commit.
-
1
-
-
5 minutes ago, Rowan Amore said:
The PBR is the one that looks like latex, IMO.
Ah, if you speak about the PBR viewer with legacy material vs legacy viewer with legacy material, then yes, the PBR viewer renders it much more like latex, but it renders the PBR material properly, like leather...
This is indeed the thing that annoys me most, for now, with the PBR renderer: it renders very badly legacy contents !
See: BUG-234816
It also recently broke shadows: BUG-234564
And finally renders water bodies like sh*t (artifacts when enabling water reflections, water is ”sky blue”, waves are not as pretty as with WL/EE, etc)...
But hopefully, these bad rendering discrepancies will get fixed over time... I just wish LL had kept the PBR viewer longer as a RC, until these bad issues would have been properly fixed.
-
1
-
1
-
-
6 minutes ago, Rowan Amore said:
Honestly? I prefer the legacy materials.
It depends if you prefer latex (the legacy render looks like it) over leather (the PBR one), I guess... 😛
But what would be interesting to know is whether this piece of furniture is supposed to be made out of one or another (or none of them, which would be rather embarrassing 🤣 )...
-
2
-
-
Oh, you mean that crash with the version checker ?
Yes, it always crashed for me under Wine... But, you can simply delete SLVersionChecker.exe (or whatever they call it exactly), and the viewer will then start just fine: it will complain that it can't start the version checker, but will keep running nonetheless.
As for the CEF plugin, it should work... It does for me.
-
1
-
2
-
-
10 minutes ago, Istelathis said:
it is crazy to see SL running over 200 FPS from my skybox.
Only 200 fps ?... I can reach 1500 fps (in forward rendering mode) ! 🤪
More seriously (and usefully), do make use of the smart frame rate limiter: it will keep your PC cool and quiet and will even allow you to rez faster (thanks to the ”smart” part) !
”Preferences” floater -> ”Cool features” tab -> ”Misc.” sub-tab, ”Frame rate limit” spinner.
-
1
-
-
32 minutes ago, Jenna Huntsman said:
Checking now, Second Life Release 7.0.0.580782 (64bit) seems to work under Wine on my system.
IIRC, the systematic crashes were seen with v7.1.1.something...
-
I warned @Vir Linden about this crash fest under Wine, at the last Open Source development meeting.
I suggested him to check what MSVC version was in use to build the viewer on github: MSVC1937 is the culprit for systematic crashes I myself saw happening with my own viewer (and I had to do an emergency update with a build done after I reverted my build system to MSVC1936, which Micro$oft exceptionally allowed in the VS installer, demonstrating they knew their 1937 version was bogus). MSVC1938 has since been released and does not cause crashes any more...
This is not to say that the crashes you are seeing are indeed due to this (potential) issue, since this could just as well be some code in LL's viewer triggering a Wine bug (it won't be the first time), but I now can run the latest official viewer I downloaded (v7.1.2.7215179142) without seeing it crashing every few seconds under Wine, so either LL updated from MSVC1937 to MSVC1938 on github, or the new viewer version is not triggering any more a Wine bug...
-
3 minutes ago, Qie Niangao said:
I'm not sure I understand what ”replacing default diffuse” is doing, as distinct from ”always replacing diffuse” unless maybe a bunch of these glTF textured surfaces (walls and ceiling especially) have something other than a default diffusemap.
Default diffuse = plywood texture, which I also extended to default blank texture (since I saw many such blank textures on PBR objects in Aditi Rumpus Room sims).
When replacing default diffuse is selected and the viewer renders in ALM or forward modes (i.e. not in PBR mode) and notices that there is a PBR material with a base color map (texture), and that the diffuse texture is a ”default” one, then it picks up the base color map (and its color, scales, offsets) to render instead of the diffuse texture.
When always replacing diffuse is selected and in ALM or forward render modes, and the face got a PBR material with a base color map, then the viewer systematically uses that base color map to replace the diffuse texture, even if the maker of the object did provide one as a fallback: you can see in this post why I added this mode/feature (which would be useless if only the fallback diffuse texture (and color) was always properly synced with the GLTF material, but such a thing is sadly not guaranteed to happen especially because of BUG-234896, which will make it hard for creators to keep things in sync when they update or modify their builds).
-
1 hour ago, Love Zhaoying said:
I am reminded of all the threads with people butthurt that SL wouldn't run on Chromebooks..
For ARMv8-A Chromebooks, and provided you run Linux on them, you might actually be able to run the Cool VL Viewer aarch64 Linux build (which is designed to run on ARMv8-A SBCs)...
-
1
-
-
1 hour ago, LipstickAndDreams said:
Oh my, you were able to do it. I will probably end up stealing some of your code for my firestorm fork, if thats ok.
As usual, as long as proper credit is given, any viewer can (and is welcome to) reuse my code in theirs (this includes my permission to re-license my code as LGPL when needed).
Be warned however that this hack supposes your viewer already implements GLTF material support (i.e. it can fetch the said materials from servers), which is not the case of current non-PBR viewers...
-
1
-
Facebook
Instagram
Twitter
YouTube
Flickr
PBR WOW!
in General Discussion Forum
Posted
Too much Champagne...