NiranV Dean

A relog sounds like an overkill tho (unless you are having fundamental issues such as inventory/outfit corruption, login difficulties, lists not loading due to a faulty login etc)

Turning off SSAO is a bad advice, it is a fundamental base feature used for better/realistic lighting. It will vastly decrease lighting quality, remove subtle shadows and lighting differences on everything and make the world look a lot flatter. I'd rather recommend lowering the SSAO Factor setting instead, it controls the "distance" between two depths to be taken into account. The higher the number, the further away objects will receive subtle shadows from objects in front of them, i'd recommend keeping it around default (or slightly smaller), a different approach would be lowering the SSAO Effect, as in increasing it towards 0. Negative values mean its black, positive values mean its white, i'd recommend somewhere between -0.5 and -0.2 if the default is too strong.

I'd highly recommend not touching text colors unless you know what you are doing. As it stands right now its hard to read. Leaving it on "Automatic" is the best option as it sets the color automatically depending on light/dark mode.

I mean apart from it looking like a car driving by which you could totally sell it as. If Motion Blur bugs out simply turn it off and on again, it should reset all motion vectors for objects. I'm not entirely sure why this happens in the first place but i'd assume it has to do with objects not being properly tagged as no longer moving.

I think you skipped a point in my post. It IS already fixed. It's even shown in the video. Not to mention that my avatar shown very much fullfills the requirements for not so "great sex experience" in first person with that long snout clipping through your cam. In addition to that, the Viewer already enforces rotation limits, although only for up and down, left and right could be enforced in addition that that theoretically very easily.

Well imagine instead of a gun, you have a bowling ball on the right and your hand on the left showing you where you are aiming with two fingers or a thumb. How about a bow with the tip of the arrow to aim. Stonetossing, one hand a stone, another to aim. This could even be used to do proper aiming through a scope, binoculars or over iron sights. Actually now i want to animate all of these... looks like i know what to do next.

So recently more and more people have been getting my input on several things that LL seemingly deemed not worth investigating. In the past i've already been fixing and improving little things that seemingly don't find much use, some more experimental, others to actually improve experience and sometimes also as a direct reaction to someone asking me to investigate. One such pain points has always been the Mouselook we are given. It has many flaws, weird quirks and generally isn't very good, only fullfilling the bare minimum of a first person view. Realistic Mouselook To improve these i've added a "Realistic Mouselook" option years ago that does away with how the Mouselook works. Instead of placing the camera at eye height center on your avatar root and offsetting your avatar to match up with your camera, which can and will depending on your avatar lead to really weird things where things don't line up, as example because your avatar is being made fit for your camera (rather than the reverse) your avatar might actually stand "behind" its actual position, or clipping into a wall behind you. Realistic Mouselook fixes this by placing the camera into the avatars eyes and making it follow your head, whatever your head does, so will your camera. This doesn't just fix the weird offset but also allows animations to have an effect on your camera. Most commonly it will be perceived as "headbobbing". Head Scaling Another issue often reported, especially with whole-body avatars (commonly furries) displaying their head and/or eyes in Mouselook, just a couple months ago i adressed this issue with a Head Scaling feature that will scale down your head and all its bones to 0, effectively "removing" the head, this is in addition to another fix to allow rigged meshes to be hidden in Mouselook when they are attached to the head. First Person Aiming Just a couple days ago i was asked to investigate whether it would be feasible to add something that allows first person animations to follow your look direction to improve first person shooter games inside SL. I implemented some experimental body-tracking that makes your chest look at whatever your camera is aiming at, given a nice aim/gun holding animation you can see the gun aiming at wherever your camera is aiming. I've made a video to showcase this below. Mouselook Linkset Animation Fix Another user reported that this is all fine and dandy but linksets in Mouselook break apart when animated, so i investigated and fixed this as well, allowing linksets to be animated in Mouselook without them lagging behind. Bringing all these together i think this is a vastly improved Mouselook that makes for a better experience. I still have a couple more plans but what do you think? Should i look more into this? I'm fairly happy with these experiments, they have proven to be very fun and transformative for the experience.

BD has been in a PBR alpha for almost a month now btw.

Now that would be controversal! We can't have LL or TPV's guide us what is and what isn't good, how dare you even imply such a horrible thing. I'd like to keep my 3 million polygon necklace thank you, i get 60 FPS on lowest settings in my skybox with a GTX 4090 just fine so it can't be that bad! I'm not sure if its still genuine love after 10+ years. Sure, vocally complaining about things could be seen as genuinely caring about the product and wanting it to be better but after 10 years i think it has simply settled in as a "normal" thing, i know it will never happen, it would require LL to actually grow a pair which looking at the history of LL hasn't exactly been something LL has ever been able to figure out how to do. It feels like ultimately it always comes down to me. If you look at what the others do and then what i do you'll notice that the other TPV's often strictly follow LL's rules, never mess with LL and generally hold back. The only person i sometimes see giving LL the finger is Henri (once again) absolutely destroying LL's implementation, showing them how bad it is and that it could have easily been done better, sometimes even warning them before they do it. From what i have seen from the others it comes down to either them not caring anymore (because they tried and failed to convince LL themselves) or because they have something to lose, if Firestorm is to be believed they always fear getting the big bat from LL if they tried anything however small. Then there's me, constantly pushing the limits, breaking the rules and straight up ignoring LL and "spitting in their face" so to say. Why has no one changed the complexity formula? Because there is a warning in the complexity function telling us we shouldn't touch it otherwise.. there might be repurcussions, maybe because it would upset users? I don't care! I don't care if it makes people upset that everyone gets jellydolled by default because their complexity finally represents their awful optimisation, i don't care if LL wants to clap my ass for changing the formula, i will tell them right to f off, heck if i hadn't experimented with the formula back then and hijacked one of Oz's meetings making everyone talk about how ***** complexity is and how much it needs some rework they probably wouldn't even have considered ever looking into it again. It feels like the others have given up but at the same time secretly root for me that i have success convincing LL to do something better, all i want is LL to not do what they do best: screw everything up for the X time, i want things to be done right, make them fun and actually useful. Why else did Whirly call me into the EEP feedback thread to, what i can only describe as "hoping that i'd ***** all over LL's absolutely bad windlight controls" and that's exactly what i did, i shat all over their UI, showed them in under an hour that i could do it better and proceeded to absolutely destroy any and all hopes that EEP is even remotely "ready" let alone RC worthy, in a matter of 30 minutes i made a huge list of issues. Sometimes i question why i'm even still putting any effort into this.

Hehehe, is it a Vendetta or am i just doing the sensible thing and giving avatars their much deserved complexity.

SL could have relatively cheap "clothing physics" or physics for bones at all. Unity for instance has a paid asset called "Dynamic Bones", these components can be added to any object (yes object, not just bones, bones are just objects/folders for Unity) and then configured to behave a certain way according to the settings. Dynamic Bones is not magic, all it does is create a chain from its contents -> Bone1 -> Bone2 -> Bone3 for instance and simply do some physic calculations to solve bone movements via rotations to make them react to movement. It also comes with collider settings allowing you to define collision shapes, this in combination with their other component, the Dynamic Bones Collider, allows you to "touch" and interact with these Dynamic Bones by colliding with them. Simple example: your boobs have Dynamic Bones and are set up with a collision radius, your hands have a collider, your hands touch your boobs, your boobs move and jiggle around, very simple. Its a very simple system, could be implemented EXACTLY like that 1:1 in Second Life and could easily run on top of everything, all we need is an extra asset type that allows us to set a root bone or a bone chain. Infact if i knew more about math and physical calculations i would have added baseline tail physics to my Viewer already. Now what SL uses collision bones for i don't know, i have never seen them being used for anything outside of animations to move certain rigged parts such as for boob physics. Which is absolutely NOT what they should be used for, instead we should have implemented and used actual boob bones and animated those because if we did we could have given them proper physics AND i could have snagged and repurposed that code for bone physics everywhere. Heck it would have been easy for LL to extend the feature to be used on every bone via the physics asset. Now if we want real cloth physics however we'd have to implement something akin to UE's cloth physics or Unity's cloth component, effectively what you do is you define a mesh (or submesh) or parts of it to be used for cloth calculations... and thats it, the game does the rest, in our case the client would do this... but honestly i'm highly against an actual cloth component, it's super expensive in Unity and UE already and seeing as how absolutely unoptimised everything in SL is, applying cloth calculations to these millions of polygons you can immediately say goodbye to any frame per second, you'd have something like frame-per-hour. I'd much prefer the Dynamic Bone approach, its much much faster, much easier and does exactly the same thing the Viewer does anyway... transforming the mesh via weights according to running animations, Dynamic Bones would just be another "animation" animating certain bones, except this animation is dynamic (like the headlook for instance). Super fast, super cheap and super extendable. VRChat for instance makes extensive use of this, so much that they made their own system called "PhysBones" which not only improved the biggest pain point of Dynamic Bones, its insane performance cost due to bad coding, it also makes them more accurate, allows for better collision shapes (spheres, cylindrical spheres and everything inbetween) and allows for even deeper interaction with them like squeezing, stretching, grabbing and posing them, which can send parameters to trigger effects, they can even be hooked up senders and receivers to do special things. All of this, running on the GPU and being multithreaded makes them insanely fast even with thousands of them being active at any given time.

I probably didn't make it clear enough, i was talking about Viewer settings, not the famous attachment revert. I've been adding what i believe are a lot of paranoid checks all over my stuff where things either already crashed once or could crash (based on other crashes i had, or simply due to copy-pasted code where i already added those), but this is solely in my own code (and i mean my own-own code, not altered stuff in the main Viewer, just my own stuff i wrote from scratch such as the Poser) but i've also usually commented them when i believe that they might be unnecessary (or were caused by some weird shenanigans, so people would understand why i'd put something weird there that doesn't look necessary)

You may not care but for the Viewer developer it is a crucial distinction. Crashing, as Henri very nicely explained means the application shut down unexpectedly due to the illegal execution of code, be it inaccessible, corrupted or otherwise. When this happens you do not properly log out from the server, this can lead to problems such as a faulty login if you restart the Viewer and reconnect (forcefully dropping your previous session), this in turn then will come up here for instance as another complain that the Viewer is buggy and faulty and logins do not work, inventories and friendlists don't load etc etc while leaving out the crucial bit of information that you previously crashed and did a quick-relog which is ill adviced as it can cause these things to happen. Another issue is that crashing will often lose you your settings and changes (although technically it shouldn't since settings are immediately written periodically, often times even immediately on change... so why the Viewer reverts it (and how) is beyond me...) What pisses me off personally the most is when people say "crash" but they are talking about a disconect that is simply masked by an immediate crash on disconnect, making it look like a normal random crash to the user. It starts me into a frenzy of trying to find the problem and wasting my time trying to troubleshoot what i broke, when and how... just to turn out that the person was reffering to a disconnect, which just happened to result in an immediate crash due to illegal read/write attempts to now stale data. Even worse if they don't crash but still report it as a crash despite the Viewer very clearly telling them that it disconnected. Crashes on TP are 99% of the time simply disconnects during the teleport sequence coming from stale data still being used when it shouldn't. When someone says "they are crashing" i ask them what they are doing and often the answer is "nothing, just looking around" which sounds like a nasty random crash, when i look at their logs it turns out its just a disconnect due to connection issues or a faulty login, which often also explain the additionally reported "staying gray" issues. Additionally i also never get these random disconnect crashes, the Viewer shuts down perfectly fine for me and displays me the "Disconnected" screen when it happens making it impossible for me to take a look at these disconnect crashes, they could be caused by anything everywhere and its not realistic to expect them to have a debugging environment installed just for this. I doubt they will ever listen. Anyone who played a couple online games could tell them that the way they handle teleports is incredibly fragile at best and i can't imagine it being that hard changing and fixing this, i mean come on, just have the client be connected with two regions until the teleport is done but i bet that would cause weird shenanigans like you popping up twice in friendlist or on both regions while transitioning, hahaha....ha... i shouldn't be laughing... that's probably what would happen.

Haven't yet looked at the rezzing specifically, especially not transparent, they didn't seem noticably different? But then again i'm currently much more focused on getting the Viewer back in working shape, as of right now everything is broken.

Mh. Interesting. I'll see how it goes, currently in the process of getting a usable GLTF Release done, it looks like this will need some major refactoring all over the place. OpenJpeg2.5 seems to work fine tho, if i'm all done with this i might take a look into your openjpeg.

Interesting. C-can i even borrow that? Isn't there like different licensing shenanigans going on? No? Or is openJPEG just using whatever their licensing was and it wasn't changed? Windows 11 got rid of Defender. That is probably the only good thing so far i've heard about Win11. The others are problems. A lot of problems, similar to yours. A picture slowly starts painting. I'm beginning to feel like the Viewer isn't exactly running well on Win11.

Well i can see that BD is objectively slower than say the Official Viewer or FS, that shouldn't come as a surprise considering that BD has 0 optimization in regards to loading/caching/decoding and neither does BD have KDU, OpenJpeg (1.5 which i'm currently using) is a good bit slower and probably always will. So in bare theory you should never ever see BD outperform any other Viewer unless they are having a bad day for some reason. But from my experience the past 10 years using my Viewer the difference between Official and BD have been barely noticeable at best, i don't sit there and time loading times exactly but i've never found them to take too long, a minute at most. Unless i do some whacky shenanigans like rapid-fire relogs (which will break your outfit, get you stuck, make you unable to move, stops stuff from loading all the way up to breaking the entire Viewer to the point you can only relog) which as far as i can tell is due to the shutdown and start routine being so insanely fast that the cache isn't properly "done" writing causing you to potentially corrupt it with a too fast restart. It might also be server related, generally speaking even with slower relog if i relog before the server has actually disconnected me properly (you are still online and will now be disconnected error) it will break a lot of things.

Yea linear color space is fine but what i mean is using linear Tone Mapping post process to artificially "boost" the colors even more to make them "pop". Tone Mapping is originally supposed to be used for HDR to compress the color range back into something non HDR monitors can display properly, something like Rheinhard Tone Mapping does this, it also naturally desaturates colors a bit (turning white a little less blinding and pitch black brighter, tho these two can be fixed or worked around with, at least pitch black can be kept, pure white isn't as important as rarely anything in real life is truely blinding white). I don't understand why they haven't given us options, now that they made Tone Mapping an official thing, they could have given us a bunch of Tone Mappers to choose from (certainly something i'll try to implement). Pretty much every game i've ever played that has the option to enable Tone Mapping also comes with an option to switch Tone Mapping styles. Warthunder and Escape from Tarkov are two examples of such games.

Welcome to why i hate most Linear and Linear-like tone mapping styles, they take the artificial colors and boost them, i hate it, real life isn't colorful, its desaturated, thats why i prefer Rheinhard or similar styles.

Oof. It's this topic again. You won't like my answer but: No one knows. Debugging what exactly is happening here and why the Viewer is choking for one person and not another is... impossible. You can't even establish a reliable baseline when you take into account that both SL and the Viewer may or may not refuse to work properly at any given point in time for seemingly no reason. It could be a setting, it could be the server, it could be your connection, it could be your OS, some software or the Viewer. It could be a random bug that leads down a rabbit hole and causes a chain reaction to go off, locking the Viewer perpetually in a loading state because a single texture is iffy. This type of report comes up frequently, frequently enough to be annoying and a serious issue but not frequent enough to say that it is an issue with the Viewer itself since a lot of people have a completely different experience, myself included. And all of these reports so far have only ever ended in no fix or in the very very rare occasion that it was fixed it was never found out what fixed it, it just suddenly stopped. All i can say is that 10 minute loading time is certainly not normal. A full scene with 50 people should be loaded in 2-3 minutes (depending on the scene, the avatars, their textures and meshes and how many of them you have visible). Increasing the amount of avatars being fully rendered will increase time it takes to load by a good chunk... but i've also seen the opposite where keeping them jellydolled keeps them perpetually in a half-loaded state and thus the Viewer in loading for much longer. Generally speaking i'd highly recommend using "Max Avatars" over "Max Complexity" anyway, jellydolls are incredibly slow, tax your framerate a lot and cause stuttering, they also look ugly af. Max Avatars is much more consistent and causes a lot less frametime spent on them (sadly). It's also normal that you have to turn up Max Complexity first, the Viewer is set to allow a reasonable amount of complexity by default and since practically next to no one has a reasonable complexity, they all get immediately jellydolled a sight that should come to no surprise to you knowing that SL is user-created and virtually nothing here is optimized.

Make sure you are on the latest update 4.3.2, there was an issue with poses not saving when the folder doesnt exist, should be fixed tho.

Oh i thought "gross, no" for you as the hugger not the hugged. You'd only give them a hug if they wanted one of course.

As long as they don't argue with me why a lizard has boobs i'm fine.

The only thing you can thank me for is the "new" snapshot floater, that is the only thing LL actually approached me about and went all the way through into their Viewer (and then was abandoned despite offering many improvements and fixes to the reported issues a week or two later)... are the improvements now in the official viewer? i thought they were supposed to come with 360 snapshots...

Ohwow hold your horses right there. That's not entirely true. I'm not sure if you are joking about the GUI part but that is certainly not what we do. Firestorm aims to improve usability by arranging things for easy access and making it easier to use for the average SL user, that includes renaming options to sound like they are explaining what they do (i call it dumbing it down, you could also call it hand-holding). In contrast to that i have a completely different approach to the UI focused on grouping things logically, setting up, rearranging and building an UI that follows some level of industry standards (in other words what you'd see in common apps and games), this also includes renaming/relabeling things to fit their correct names (a common example here would be choosing "Deferred Rendering/Shading" over something like "Advanced Lighting" which is more of a descriptive name what it does rather than the actual name of the feature it is, whereas Deferred Shading is the correct name that has been given to the technique and can be looked up/read up on the internet or wikipedia). In comparison to Firestorm i don't focus on handholding people, i put descriptions and explanations into tooltips where they don't use up precious space and clutter the UI more than it already needs to be to house all these options. Our two entirely different approaches to what we want the UI to be and what we think is a good UI leads to two entirely different ways the UI is laid out and presented. While commonly you will find the same options in roughly the same place their exact position and name will change. This has nothing to do with us trying to increase the gap between UI's for the sake of doing so. We simply have completely different requirements. I find FS's UI absolutely atrocious and ugly, LL's UI a big waste of space and even my own UI at times not meeting the requirements that i have for a "good" UI (mostly due to the UI simply not being capable of doing the task or not having the widgets to do so... or in some rare cases the UI simply being absolutely terrible at what it does, like UI scaling). On the topic of features and development, that is also not entirely true. A large chunk of SL's development can be attributed to the fact that it is open source, a lot of big projects and a lot of features and improvements have been made by the TPV's or Community members... and some others wouldn't even have made the cut if we TPV's had our hands a bit more on their development.... if i had anything to say in EEP's developmend it would have never released to begin with, A, it wouldn't be called EEP, it would simply be Winlight 1.5 (2.0 would actually be the ORIGINAL windlight before it was aquired by LL) and B, all the devastatingly stupid decisions that have been made, such as getting rid of local presets, making presets subject to intellectual property (aka allowing them to be marketed and permission'd), getting rid of the easy full environment editors (local sky/water/daycycle) and the new excuses of an editor they call the new windows that waste half your screen on 1080p would have never made it to release on my watch, the person responsible for this would have been fired and at the very least in regards to the UI part i would have personally taken over the UI to make sure it stays the way it was (infact in the EEP thread i did EXACTLY that, i literally told them how bad the windows are and quickly jumbled together a working windlight-like EEP editor window just to show that its a matter of less than an hour to fix this mess). We have a lot more influence than you are attributing to us but certainly not enough for my tastes. Also if LL's open source development environment and getting our improvements to them wasn't so long, annoying and tiring to deal with there would be a lot more stuff contributed. I would have already contributed half of my changes to LL years ago but every time i tried they just sabotaged or straight up declined all of them (or in the case of the Poser made stupid requests) because "no one complained" when in reality there aren't any complains because no one can use it with how broken and bad it is.