NiranV Dean

I know! Obviously FSAA and SSAA don't work when FXAA takes precedence in Deferred but as I wrote I expected it to work regardless of whether Deferred was on/off at startup. I would highly assume that it is a bug and like I said the very reason I've never seen FSAA work, otherwise people would have Antialiasing when they turn off Deferred (which almost everyone doesn't) since to have AA in Deferred they need at least 2x set (which doubles as FXAA with Deferred and FSAA without Deferred). I'll have to take a look into this at some point, I remember the RenderFSAASamples debug setting being input into the window creation so I kinda fail to see (in theory) why it wouldn't work. In any way, this means i can add 4x and 8x back as options (given Deferred is disabled) and add a warning to it that it requires a restart.

Which doesn't have a visible effect on rendering for me however. AA simply does not work beyond 2x (FXAA) for me and doesn't work at all without Deferred. This is how i've been able to tell whether someone runs Deferred or not for years and it was pinpoint accurate, this happens in FS, BD and LL Viewer. I doubt it's my GPU doing this, it wouldn't just be mine either, it would be a wide range of GPU's both NVidia and AMD for a lot of people. It wouldn't be surprising if it was AMD related but NVidia seems like a stretch. I have honestly no more ideas why its not working. Any and all code I can see that prevents it from being used is for Intel or AMD cards (and i mean the multisampling for selection wireframes work too, hence why they are so ass slow) EDIT Alright, I finally figured it out. Just took me 10 years. FSAA and FXAA are not mutually exclusive but cannot be run at the same time. MSAA and FXAA are mutually completely exclusive. Having MSAA (16x) completely overwrites FXAA and breaks it (as expected for something that is forced driver-side). That being said, in order to get FSAA to even work you not only have to relog but you also have to have Deferred disabled BEFORE you relog. You CANNOT have Deferred enabled at all, you will have to disable Deferred and turn FSAA samples to the desired value, then relog with Deferred off, Deferred must be off at the time of window creation otherwise it will not work ever. THIS is why I could never get it to work despite relogging many times. I always had Deferred on at window creation and turned it off after. The reason 16x looks worse than 4x is obviously due to a totally different AA being used, we are talking 4xFSAA compared to what seems like 2xMSAA. 8xFSAA on the other hand seemed to look very slightly better at certain angles but its hardly noticeable and hardly worth twice the amount of sampling. With this mystery finally being sorted out... settings above 2x is still really totally pointless. Because it A: requires you to have Deferred off at window creation time, which for someone who uses Deferred would be a pain to do and B: doesn't work while Deferred is running which C : is to be expected of any user nowadays (running Deferred that is, at least without shadows). Not even writing a big fat warning on the setting and requiring a restart would solve this solution. You'd have to explicitly tell the user to disable Deferred (and keep it disabled) in order to enjoy a normal AA.

Both global and application level don't have a profile for the Viewer (I know I had one specifically for BD back on Windows 7 a couple times to try a couple things after which i removed it because it kept reducing the framerate massively) but even if I still had one it wouldn't affect the official Viewer but I checked again just to make sure. Any AA above 2x has stopped working for me around Viewer 2.7 (which was around the time FXAA was introduced and replaced MSAA). As far as i can tell from the commits MSAA support was disabled completely: https://bitbucket.org/lindenlab/viewer/commits/2dd8ce53e4e0d14f2bc20796eb6bdf1ef12a65df https://bitbucket.org/lindenlab/viewer/commits/7ee10ae1def26708fa44c25355982aa56195d5f9 It should not be working, the Viewer has no other AA implementation either. I doubt that my GPU can't do true AA anymore, both old and new games with many different AA implementations (from original MSAA to FXAA, SMAA, TXAA/TAA, SSAA, CSAA all the way up to 32x) work fine, the only thing I can't get to work is driver-level SSAA in SL, works fine everywhere else. I'm using a GTX 1060 so nothing too fancy and far from top of the line, that's around medium range GPU. NVidia's 32xCSAA was really really nice and incredibly fast (I've only ever seen a single game make use of it, sadly it's no longer supported and has been dropped down to 16xCSAA).

Weird. It is obvious that this isn't FXAA (otherwise the fine floor detail would get blurred) but the real question is why does it even work for you and why does it impact the UI (which it only should if its forced via drivers). Did you check and make sure you have no graphics driver profile for the SL Viewer and also not globally set to "extend the application" for AA solutions? EDIT: Also oof, i just noticed that i posted (and apparently saved) the 2x snapshot twice... i had to do it via snipped tool and save it as external image because for some reason simply paste (CTRL + V) the image in clipboard is not working here anymore... lemme make new ones, i'll just take full snapshots this time. Disabled 2xFSAA 4xFSAA 8xFSAA 16xFSAA As you can see there is zero difference. Also the ground texture becomes more blurred starting at 2x and stays the same way (due to FXAA being used)

Weird, i don't see a difference... and without deferred AA doesn't work at all: Make sure you dont have Nvidia extending the Viewer capabilities in your drivers.

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.

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

Now i wonder how much it even taxes the GPU, with the GPU being highly unutilized unless using calculation intensive shaders (such as depth of field). 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. Interesting but not entirely unsurprising. Disabling water kills the entire water and reflection update code which solely runs on the CPU, by eliminating this we eliminate a massive CPU overhead resulting in the GPU being able to be utilized more now that the CPU can shove other things faster into the GPU to handle. Without Deferred however we hardly see a GPU utilization increase since without Deferred the GPU is basically just idling anyway, almost all the high GPU usage shaders are off in pre-Deferred.

Would that really mean an improvement though? You are still rendering the reflections and regardless of how much of the water volume is visible, you are still using a virtual extra camera and rendering essentially the entire world a second time, cutting out single parts out of the water wouldn't help there, if anything it would be completely wasted depending on how you implement it. Say you remove a single tile in the middle, you'd still have to have the camera render basically almost everything across the entire surface since it would still be visible somewhere on the surface of the other pieces, as long as the water plane still exists somewhere and needs water reflection updates we are still going to incur a massive performance cost, despite cutting out large areas of the surface. That is not to mention the bad culling we have...

For anyone wondering, its the log console, should be CTRL + Shift + 4 if i remember correct.

Sadly a limitation I COULD workaround but am not allowed to, the actual fix (server side sync) is up to LL, no progress on that so far though.

I have not specifically tried it but as far as i know avatars are excluded from collision, so i'd say 99% no.

Your camera can start moving if it needs to be pushed due to collision with terrain or objects. Not sure about Firestorm but by default your camera gets shoved around alpha objects if they are not set phantom, even if they are completely invisible (you can create invisible camera barriers). It's really annoying and i've had my camera repeatedly zoom in and out again to its default position because something invisible was moving between my avatar and my camera.

LL Viewer has Advanced and Develop menu both in menu and in preferences, absolutely not hidden. Also, still way too easy to access.

The majority? Certainly not. The majority ignores this feature, doesn't know it exists or doesn't need it like a good consumer/user. A very tiny minority of the rest uses it for an extremely limited and weak excuses of "good" uses, such as Firestorm for teaching their users. The rest are bullies or weirdos who think SL and the virtual area around them belongs to them and no one is allowed to move their camera even remotely close to them and let this stupidity out on other people. The amount of people who use this feature for anything good is so incredibly tiny we might as well remove this feature and there would be no harm done. But i say lock it for users, keep it for support/developers/betatesters/teachers. You mean like all the other issues we keep ignoring for over a decade now? Way to go. Just add it to the stack. I hardly care about data being collected (its LL's service after all and we use it) and this is the internet but there are valid reasons and concerns here (not saying the privacy thing is one, i find privacy or security a weak excuse in this topic).

Sadly it is not that easy. Raising the priority of the headtracking animation is sufficient but poses a different problem, you essentially completely overwrite the AO, which wasn't what I did, I have the animation still play but the headtracking is "added" on top of the animation, essentially you are nudging your head around while its still playing the underlying movement, this looks a lot more natural and less broken but comes with its own issues (such as some human avatars having spinning heads for some reason) So essentially what i read out of this is you agree to shooting down this thread now that it is coming back to the actual topic? Great. Way to kill a discussion, sounds more like trying to silence others. There have been a couple extreme statements here but that's no reason to kill the entire discussion which seems to be still up and well.

This wouldn't work unless you can rig the mesh in such a way that it moves normal despite being far off the actual skeleton. Animesh would work. Nametags are bound to your head so wherever your head bone is so will be your nametag. I've been thinking of reverting this to the old behavior (avatar position based rather than head bone based) or better yet use a combination of both with a distance limit which will make the nametag position fallback to your avatar position. I assume the reason the behavior was changed was due to tiny or huge avatars which had their nametags clip into them.

I was making a joke: Should i do it? Should i make it detach too? What's the point of it derendering if it detaches too...

What if i told you it detaches it too?

It happens in all Viewers. Just the nature of how meshes are displayed in SL. You can see the actual position with Develop - Render Metadata - Update Type. However there seems to be no correlation between the actual position and where a click will actually hit. I did notice however that clicking where the underlying LL body is usually seems to improve the chances drastically. What's more interesting to me is the Raycast toggle in there, the raycast is clearly able to properly raycast against the rigged and transformed mesh, why can't this be used to check whether we hit something or not? What's even weirder, with the raycast enabled every single of my right clicks hit perfectly... except, contrary to the above statement, when i click where the LL body is (its being highlighted too), where clicks seem to become like a 50/50 whether they hit the mesh or the LL body.

Wouldn't the solution be force updating the mesh to be in the position we see it (with transforms) when right clicking (potentially make it an option if it causes a massive framerate hitch)? Doing a full forced update for the mesh on a right click should be fine, its not like its done every frame. An alternative would be an implementation that doesn't attempt to check for the actual mesh but the transformed visual (possibly a copy of it?) that we see.

That's a common issue with selecting rigged meshes. I'm not sure why a fix for this has never been made yet (or has it?). Despite the click function having optional more expensive ways of raycasting, these still do not help right-clicking meshes most of the time.

Now that is an interesting solution. I didn't think of that! I should prevent attachment derendering too. EDIT: I should also totally still allow derendering your clothing and yours only so i can act like a random person, walk up to you, derender your outfit, IM you with screenshots and a torrent of negative commentary all the while standing naked right next to you so you can complain about me not wearing pants and having boobs on lizards.

Ohhhhno...nononono... *vietnam flashbacks* i've been taking quite some heavy flak (by the very same person who i banned from using my Viewer) about this feature and funny enough it is never mentioned that said feature exists in all Third Party Viewers, it apparently solely exists in my Viewer!

That is true I do not have anything that could be called a documentation. It is probably time to get started on that at some point. In the past I've delayed this due to the fast and massive changes to the UI which would often and quickly invalidate these documentations and would make editing them a constant thing, anyone who keeps a wiki updated knows this is a lot of work. However, I've made several attempts to have some sort of in-Viewer in-UI guide/explanation ready, most of the features give an explanation as to what they do and what they impact, I recommend reading them, they can be quite helpful and will usually be up-to-date and often warn you of any issues (they also sometimes give helpful insight into other features that they work together with). Apart from that there is the FAQ, a couple blogposts that go to explain a couple features and help with a couple common things, there is also a Forum post here with some very helpful little tips and tricks about the Viewer (link) and the Discord has a guides channel written by me and users alike who try to explain some of the more complicated things in the Viewer. Alternatively you can ask in the Discord, or contact me inworld or on Discord (or here if you just tag me or yell loud enough), given you do not fear interacting with me or downright avoid me like some people here claim to do.