Henri Beauchamp
-
Posts
1,208 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
30 minutes ago, NiranV Dean said:
No, i'm basing it on the fact that 4/8/16x makes no difference and AA doesnt even work without Deferred at all in both my Viewer and the Official one, also checking the code there is no indication of FSAA samples option being used anywhere else other than inside Deferred. Like I said anything else is an extra implementation. Your Viewer came from V1 so i'd assume you kept MSAA which was removed around 2.7. If 4/8/16 actually made a difference i'd have kept these options.
There is NO MSAA support in my viewer. Only pure FSAA/SSAA. Just like in LL's official viewer (mind you, my code is not just v1 code: I kept backporting v2+ code !).
Relevant code is in llwindow(sdl/win32/macosx).cpp. Just look for the mFSAASamples member variable usage (and see how it is passed at the OpenGL window/context creation).
And I do see a difference between 2x/4x/8x with LL's viewer... Of course, if you override AA setting system-wide, at the driver level, you will not see anything.
-
1 hour ago, NiranV Dean said:
Firestorm as far as i know uses FXAA (when setting AA to 2x) whereas it switches to the oldschool MSAA that we had years ago when going above that. The difference between forcing it through the NVidia Control Panel and doing it in the Viewer is that as you already noticed, forcing it will apply it to the UI as well but will most likely result in better performance due to a better implementation, the in-Viewer implementation however does not include the UI and should give you similar results.
BD (like the official Viewer) unlike FS does NOT have any other AA mode, people falsely assume that setting AA to anything but 2x makes a difference, it does NOT. All Viewers that do not implement an extra AA (as far as I know almost all of them, except FS, Alchemy and possibly Cool VL Viewer) only ever use the 2x setting which is FXAA. BD only uses FXAA and nothing else, the only reason I see why BD's AA could be slightly better is because I modified the FXAA preset to force the High Quality ”39” preset and made some minor adjustments to the edge detection settings, they might or might not be better at times.
Coming back to your question however how to get a ”better” AA like BD apparently has, you could take the FXAA shader from BD and copy it into FS, have it replace FS's FXAA shader, this would give you the same FXAA preset and settings BD uses but you'd have to repeat this every time FS updates. The shader file can be found in:
Black Dragon\app_settings\shaders\class1\deferred\fxaaF.glsl
I am afraid you are mistaken with FSAA (AKA SSAA) modes and the post-processing FXAA shader of the viewer (which is only used when deferred rendering, AKA ALM is enabled). Your confusion might stem to the fact that in their (not so) great wisdom, LL's coders are using the same AA setting (RenderFSAASamples) to govern both FSAA and the enabling of the fxaa.glsl shader (enabled in ALM when RenderFSAASamples > 1).
The viewers (AFAIK, all of them) use the FSAA modes for 2x to 16x (the ”fsaa” samples parameter is passed at the OpenGL context creation, and this is an OpenGL feature dealt with at the GPU/driver level without any need for a shader). However the 16x mode is in fact faked by most (all ?) drivers (for NVIDIA it triggers full screen MSAA, which causes the blurry fonts). Unless your GPU/driver does not support 4x and 8x true FSAA modes (in which case it might switch to MSAA), 2x, 4x and 8x modes do give different results (but it might not appear they do when ALM is on, because of the FXAA post-processing shader).
Again. For the viewer, use 4x AA mode (it's by far the best and will not tax your GPU): you can observe its effect with ALM turned off.
It might be a good idea to allow disabling the FXAA shader entirely (I really don't like the blur seen in ALM mode)... I'll try that for my viewer...
-
Using FXAA or MSAA (AKA pseudo 16x AA) will cause blurry 3D and UI.
I do not recommend using any pseudo AA methods (FXAA, MSAA, CSAA, EQAA, etc, etc).
Only SSAA (super-sampling AA, AKA FSAA = full screen AA) properly works and avoids any blur. The rest are approximations used to try and alleviate the load on the GPU while approaching the ”true thing”, i.e. SSAA.
4x SSAA gives by far the best results (keeping the image sharp, not affecting the least the UI fonts, and properly smoothing out the jagged edges), while not costing you much in performances (modern GPUs can do it at almost no performance loss, especially in SL where modern GPUs load is rather modest).
8x SSAA does not give better results (I personally find them even slightly worst, actually) but would cost you some FPS.
”16x AA” is not SSAA (it would load the GPU too much) and actually triggers FXAA or MSAA (depending on the GPU). It is far worst than 4x AA because of the blur it introduces (especially on the UI fonts, but also in the 3D scene).
For the viewer do not set the AA mode from the driver control panel, but instead choose ”let the application decide” (or whatever it is called by your driver), then set the AA mode from the viewer graphics preferences, and avoid the 16x (pseudo) AA mode. Remember to restart the viewer after changing the AA setting (it might not tell you to do it, but usually won't properly switch to the right AA mode until restart).
-
2
-
-
1 hour ago, NiranV Dean said:
With Deferred Rendering and Shadows and full water reflections enabled: 70-75% GPU usage. ~55 FPS.
With Deferred Rendering and Shadows and without water: 83-85% GPU usage. ~71 FPS.
Without Deferred Rendering and full water reflections enabled: 23-24% GPU usage. ~56 FPS.
Without Deferred Rendering and without water: 24-25% GPU usage. ~88 FPS.
Beware ! The more FPS, the more GPU usage, so you must make the usage figures proportional to the frame rate:
ALM and water: 72.5 / 55 = 1.32% per frame
ALM no water: 84 / 71 = 1.18% per frame
No ALM and water: 23.5 / 56 = 0.42% per frame
No ALM no water: 24.5 /88 = 0.28% per frame
However, this does not properly take into account the CPU main thread (non rendering tasks) overhead (which slows down the frame rate).
Still, this shows off the weight of the water rendering on the GPU side.
-
6 hours ago, Barby Seda said:
Recently I have not been able to teleport myself anywhere, and also the profiles of my friends and contacts are empty. I have restarted my PC several times, and there is no change.
Probably a failure to retrieve the region capabilities (look at the viewer logs for such warnings as failure to retrieve seed or capabilities)...
Try to log in in a different region (from the location combo on the login screen: use another region name than the name of the region you are trying to log in from). If it solves your issue, then poke support for a region restart of the non-responding region.
-
2 hours ago, NiranV Dean said:
Would that really mean an improvement though? You are still rendering the reflections and regardless of how much of the water volume is visible
This is why I did not mention skipping reflection updates in the 16 tiles case, but just the rendering of the said tiles.
True, it won't help much on the CPU side of the code, but would still make things lighter on the GPU side (less things to render, and water shaders applied to less pixels).
-
1 hour ago, KjartanEno said:
Notice that there's no water around,
.../...
Setting the viewer to opaque water gave a ~20% improvement in framerate with the shadows turned off. Similar results were obtained with other viewers and my AMD Ryzen/Radeon computer.
Does the Performance Project viewer give similar improvement by changing water to opaque in this location?
Ideally, the code should automatically skip entirely water rendering (and reflections updates) when the water body (which exists in all sims, even when it is under the land surface) is fully culled... This would indeed give a fps bonus in many land-only sims.
Once this is done, another possible, finer grained, optimization would be to split the sim water surface into, say, 16 surfaces and render only the ones that are not culled (thus also covering the cases of sims with a few visible water surfaces).
-
21 hours ago, dd Temin said:
Any comments by Henri Beauchamp would be greatly appreciated. Thanks
Err...
Oh yes... Maybe: I didn't do it !
-
8 hours ago, Andred Darwin said:
We could share some standard settings to be used for the fps readings, with and without shadows... ( which could allow us learn a thing or two as well )
For a neutral scene, could maybe use some at Bay City, Nautilus, Horizons... with some water around..., whichever would include a bit of all components within rendering... maybe @Patch Linden could work his magic and donate / build a small area for that purpose.
For 100% reproducibility, we'd rather need a dedicated sim (an island to avoid ”noise” from neighbouring sims) on Aditi, with a ”typical” setting (possibly copied over from an existing sim in Agni) and, most important, one or two dozens of bot avatars staying immobile in that sim (here again, preferably wearing ”typical” mesh bodies and various attachments). Then, useful data could be gathered by LL and TPV developers alike to try and optimize their viewers...
-
2
-
-
10 hours ago, Andred Darwin said:
I have never seen a viewer running at 170 fps looking at a scene ...
It depends on the scene, and on your hardware, OS, graphics drivers...
Under Linux, on a 9700K @ 5.0GHz + GTX1070Ti @ 1900MHz-9200MT/s, with the Cool VL Viewer (DD 256m, all other settings to the max), in my skybox, with 3 avatars (mine + 2 alts), I can see figures ranging from 600 to 940fps, depending on what my avatar is wearing, with the WL renderer without ALM, or 250fps with the EE renderer + ALM + shadows (whatever my avatar is wearing, because 95% of the overhead is then in the shadows rendering).
Frame rates over 150fps are also a common occurrence for me (with 256m DD, in regions with neighbouring sims, or 512m in islands), even with ALM on (but shadows off) in many places... Especially if you are using Linux, then give it a try; you might be agreeably surprised.
I will likely open a new experimental branch of my viewer with LL's improvements once their ”performances viewer” goes RC (for now, it still got too many render glitches/bugs).
-
1
-
-
See this (last) post on my forum: a recent commit to LL's viewer (backported to mine) seems to possibly be a resolution to this issue (I did not experience this issue myself, but one of my viewer users already reported the new release solved it for them).
-
25 minutes ago, Qie Niangao said:
These are simply incorrect. Other than a very old bug causing momentary miscalculation (which mostly affected sculpts and which I haven’t seen for years)
This miscalculation is the bug and unlike you, I encounter it very frequently when converting old builds to the LI system.
6 hours ago, Count Burks said:As I wrote above. After setting all the prims to Convex Hull starting with the Root prim first I ran into another issue with the boat. When trying to enter the boat I was walking on top of it because of the Convex Hull issue. Then I needed to switch some of the prims back to prim in order to be able to enter the boat again.
Ah, yes, indeed, for ”tortured prims”, the physics convex hull is extremely coarse (simplified to a cube or a sphere, apparently) and as its name implies, hardly suitable for a concave prim... In this case, it might be advantageous (for example for your boat floor) to add an invisible (simple/non tortured) primitive set as ”Convex hull” (that will count for 0.5 LI only) and keep the tortured prims as ”None”. The LI system most often (not always) brings a benefit, but it implies some modifications in old builds or in how you conceive new builds to get the most out of it.
-
41 minutes ago, Count Burks said:
A negative side effect is that I could not step into the boat anymore because of the Convex Hull shape. It was needed to switch back a couple of prims to prim type to enable this again
You do not need to use the ”Prim” type any more: ”Convex hull” does have the physics shape (unless you make the object ”Phantom”, of course). Only ”None” removes entirely the physics from the primitive (making it cheaper), but is (for this very reason) not available for the root primitive.
-
7 minutes ago, Theresa Tennyson said:
It's not a ”bug”,
It *is* a bug, because if you do not change the root primitive first (but a child primitive instead), the object LI will most often inexplicably sky-rocket to several hundreds, while if you change the root first, it does not...
-
30 minutes ago, Profaitchikenz Haiku said:
it's been around for a while now.
There has been a recent commit in LL's viewer (not yet released) that might well fix it... I backported it to last Saturday's release of the Cool VL Viewer (v1.28.2.56), so you may want to try it and see if it solves your issue...
-
1
-
-
It's a well know bug encountered when converting from the prim-based to the land-impact based accounting for objects. Old objects and objects made only out of ”Prim” type primitives (and without materials) are using the primitives count as the LI.
To convert (relatively) safely such an object to the land impact accounting, first convert its root primitive as a ”Convex hull” type (this should avoid seeing the sky-rocketing of the LI), then convert the other prims as needed. Be aware that each ”tortured prim” (any prim using Twist/Taper/Shear/Slice) in the link set will cost dozens of LI unless you convert them to the ”Convex hull” or ”None” types.
I recommend doing such conversions on a parcel with a lot of available primitives (in a sandbox sim for example) to avoid the auto-return it would potentially trigger on ”full parcel” event.
-
1
-
-
Normally, when the web search (or the Marketplace) floater is opened from the viewer, the OpenID cookie is automatically set and ”logs you in”. This however was changed recently (September 2021), so if your viewer version is too old, this might not work with it...
-
My home region (Hunburgh) is currently running 2022-01-06.567269 and I noticed (it has been lasting for a few days) that when logging in it, the friends list is not updated (online friends appear as offline in the list), while when logging in in a neighbouring region with a different server version, everything works fine in this respect.
Anyone else noticed it ?
-
12 hours ago, Toothless Draegonne said:
I cannot recommend and will not use any viewer that is not on the TPV.
If you please could stop spreading FUD... To cite my web site:
QuoteThe Cool VL Viewer is itself TPV-policy compliant (and for people wondering why it is not listed in LL's TPV directory, it's simply because I don't want to provide private data to LL about myself, data which is illegal to require for such a purpose in my country. Being listed in the directory is in no way a requirement for a viewer to be considered TPV-policy compliant anyway: see the paragraph 6 of the TPV policy).
The Cool VL Viewer has been (publicly) around for over 14 years and not a single day pin-pointed by LL as non-compliant. It has in fact been the very first TPV to fully implement and comply with the TPV Policy. The listing in LL's TPV Directory is totally optional and in no way a guarantee that the listed TPVs are policy-compliant, just like not being listed does not mean the viewer is not compliant (see the paragraph 6 of the TPV policy).
-
1
-
1
-
-
40 minutes ago, Testicular Slingshot said:
Mind if I snag your version of it?
It is Open Source. Feel free ! 🙂
-
2
-
-
3 hours ago, Toothless Draegonne said:
As someone who uses Linux as a daily driver, I would not recommend Linux as an SL machine to someone who just wants to switch on and have fun. The stock viewer does not support it. Firestorm has SLVoice issues.
.../...
Granted, the amdgpu stuff built into the kernel is lovely, but that's not going to matter if you're using an Nvidia card and end up downloading the Nvidia blob to drive it, and you'll still end up whacking Vivox with a mallet to make voice work.
Try the Cool VL Viewer... It is primarily a Linux viewer and works perfectly in all aspects (including voice, via Wine 32 or 64 bits, if you really need it: it even provides an install script for Wine-SL-voice).
The ”Linux = geek” old cliché does not stand any more, nowadays. As for the ”NVIDIA blob” it is just as cliché as the rest (mind you, even so called ”Open Source” drivers do use a closed source firmware blob from AMD: each and every modern (i)GPU (NVIDIA, AMD, Intel) use such a blob anyway).
Nothing prevents you either to dual-boot your PC (*). The 20-50% increased FPS rate is worth at least a try !
(*) Oh, wait... Micro$hit tried hard to make that impossible with Win11 and its ”secure” boot requirements and such... But Windows geeks solved that and you can actually install or upgrade to Win11 even on an old PC with ”unsupported” CPU, in BIOS mode or on an MBR partition, without secure boot, without any TPM support at all, with less than 2Gb of RAM, etc... And yes, it does run (and update) just fine; I personally did it on multiple VirtualBox VMs and 3 different ”bare metal” PCs, all of which without secure boot, without TPM, in BIOS/CSM mode, on MBR partitions, two of which with unsupported CPUs (2500K & Q6600)...
-
OpenJPEG v1.5 and newer got totally crippled for SL usage purposes. The JPEG2000 level of details plain does not work with those versions (they can only decode textures successfully at full LOD), and JPEG2000 encoding is also bogus with them.
That's why I kept OpenJPEG v1.4.0.635, fixed/improved with many patches, either backported from newer versions for security fixes, or created by me (and recently from Kathrine Jansma for an AVX2 optimization) for the Cool VL Viewer (the patched version has been made part of my viewer sources for these reasons)...
However, please be aware that the ”rainbow textures” you are experiencing may also be the result of bugs in libcurl's HTTP pipelining code (the only 100% working and safe version of libcurl with regard to pipelining is v7.47 with LL's patches, as used by default in my viewer)...
-
1
-
-
1 hour ago, Kathrine Jansma said:
The second RAM module is more important, the actual speed is only a big concern if you used a non dedicated GPU or try to get to really high FPS.
+1
The viewer itself is not really sensitive to the RAM speed, unless you are using an APU or iGPU (i.e. using the integrated graphics unit of your CPU), in which case the ”VRAM” is actually the system (CPU) RAM...
When using a discrete GPU (even as old as a GTX460), your bottleneck will be at the CPU level: the better the single-core performances of your CPU and the higher the frame rate (it's almost exactly proportional).
As for the OS, you'd better go for Linux to enjoy a +20% bonus (minimum, for NVIDIA GPUs, probably +50% or more for AMD GPUs) on frame rates with the exact same hardware, with the caveat that new Intel heterogeneous CPUs (with their poorly performing ”E cores”) can induce some bad decisions in the scheduler (this is also true with Windows 10 or older): in this case, you may use the CPU cores affinity settings of Linux to solve the issue (the Cool VL Viewer can even do it for you, if you specify the proper CPU mask in its settings), or even its core hot-plug feature (you can enable/disable cores usage on the fly in Linux, and decide to disable all E-cores when running applications that suffer from them).
-
I am paying enough already, as a premium user and main land owner (around $450 a year), as a Marketplace merchant (10% of the sales: it used to be 5% in the past, and 0% when I joined SL since everyone was shopping in-world and not on a web site), as a creator (L$10 per uploaded texture, anim, sound, and a variable amount for uploaded meshes), and every time L$ to $ conversions happen.
This is not counting the free (”free” like in unpaid) time I am giving up to the community at large as the only developer/maintainer of the Cool VL Viewer (15 years of continuous work on it, i.e. worth over 10,000 hours of an experienced programmer work).
So, no, I will definitely not pay more for anything else. Period.
Instead of a ”premium plus” addition to try and suck up even more money from us, poor (”poor” like in definitely not rich IRL) cash cows, I'd have hoped for more (useful) benefits given to long time premium users who are indeed helping to improve SL, be it by their contributions (and not only the financial one) or their creations. Why not free texture/anim/sound uploads, for a start ?...
-
5
-
1
-
Facebook
Instagram
Twitter
YouTube
Flickr
Firestorm: Anti Aliasing
in Second Life Viewer
Posted · Edited by Henri Beauchamp
Well, here is what I get. To be sure the upload to a third party site won't degrade the snapshots quality, I uploaded them to my site:
No anti-aliasing
2x FSAA
4x FSAA
8x FSAA
16x MSAA (the viewer asks for 16x FSAA, but the driver switches to MSAA)
All snapshots taken with ALM off (so that LL's FXAA shader does not interfere). Looking at the edges of the primitives, the differences are obvious !
Notice how 4x is indeed the best (jagged edges start to reappear at 8x: my theory is that the super-sampling is so high at 8x, that it becomes much smaller than a single pixel and starts to differentiate the jagging as if they were different edges, not smoothing them out by averaging their colours properly as a result).
At 16x, the blur appears, quite visible also on the background texture (while there is no jagged edge to smooth out there): this is the result of the MSAA algorithm which is just a kind of pondered blurring. Also (not seen in those screen shots), with MSAA the fonts and UI get blurry as well (and the fonts are distorted when compared to their normal aspect).