NiranV Dean

I've had reported cases of this before where someone couldn't save depth snapshots but was able to turn on Depth of Field (which absolutely needs depth information, like pretty much most of deferred rendering). It's important to note that the depth snapshot and the actual depth map the viewer uses are two entirely different things. We did not find a solution but that case was also an AMD GPU user and also had exceptionally low framerates for no reason. I'm led to believe this is just another one of AMD's poor openGL driver support issues.

Any and all baking in SL is bad, especially model-level baking. It's a leftover from PS1/N64 times where textures were limited and rendering wasn't fancy, baking some shading/lighting into the model itself for instance was a good way to get depth into the model without doing it on a texture, which essentially allows using smaller, repeating textures for greater detail while having the model itself handle the shading which you'd usually supply either by realtime rendering or via prebaked textures (like ambient occlusion maps). No one is SL really knows how and when to properly utilize baking since most content is made by entry-level modelers or users who barely managed to get a model done. Real good texture usage and proper materials utilization can make a scene look absolutely incredible (but will also quickly highlight where SL's rendering fails and lacks horribly) and i say can because whether said good looking content actually looks good also depends on your client side, you need to have the settings and features enabled to boot with and you need to configure them properly to make the most of it. SL unlike other environments isn't pregenerated, creators get very little control over how their stuff will look for each and every user as we have full control over how everything will look for us at all times.

Short answer: Yes, yes you can. BD supports both old style local XML presets (pre EEP) and the inventory based windlight presets (introduced with EEP).

The blue tint is caused by graphics driver issues/incompatibility. You'll need to update (or downgrade) your graphics drivers to a working version. It's weird that no one recognizes this issue when it has been absolutely rampant for a long time (especially on AMD).

Updating them? Maybe yes. But to something like AnaLutica which essentially neutralizes any and all realtime lighting? No thanks. These presets are horrible. I'll have to agree with Ansariel here, screw baked lighting and shadows and finally make use of proper advanced lighting. Baking-less textures would also allow using more atlased texture UV's and/or lower resolution for textures as they do not need to have a high resolution anymore for those baked shadows. Baked lighting is something that should be used very carefully and with how Second Life is setup that lighting is essentially baked into the textures (instead of dynamically while running SL, similar to pathfinding) it's hard to justify it.

That's what you say right now but wait until i manage to turn it into a transformer which is going on a world tour to kill everyone just because i typed in the wrong commands

Well that's why i said "apparently". I do not compile for Linux i can only go by what i see from the developer mails i get and what i hear from other developers and all i hear is a lot of issues and a major headache with collecting the right library packages and having to have very specific setups in combination with the aforementioned libraries. I wouldn't even think about compiling for Linux as i hate terminal/cmd interfaces not to mention i was too stupid to install several of the big linux distros, i'm pretty confident that i wouldn't be able to compile a linux version of the official viewer (god forbid of my own viewer, that's apparently broken) unless there is a very clear step by step guide that explains everything down to the way i have to sit on my toilet and what rythm i have to breath in. And yea i know Linux isn't all terminal/cmd, it has fancy GUI's too but before long you'll find yourself back in cmd to do anything the right way (not to mention compile the viewer, i hate compiling the viewer via cmd, i've never done it outside of Visual Studio... in fact it wouldn't even compile simply because the packaging process at the end fails which for some reason cleans out the entire project after it compiled everything)

Well the OS plays a major part in how well any program runs and if anything we would choose one platform to migrate everyone to (one solution for everyone) and that would either be Windows (due to popularity, easy-to-use and compatibility) or Linux (if we chose performance over everything else). Making a single program run on multiple OSes is one thing, making it run well is a whole different story. Mac in this case isn't even mentioned due to its generally bad support, low userbase and generally bad hardware or in short bad compatibility (though the same could be said about Linux which is mostly just hampered by its small userbase in comparison to Windows). Mac is essentially what AMD is for GPU's when it comes to SL with Linux being a close second (at least in SL, compiling SL for linux is apparently hard, requires a lot more steps and preparation, a lot more very specific things and still has massive issues with the voice service SL uses). The only "easy" solution i see here is having everyone on Windows and forgetting about everything else but then we are running into the issue that not everyone wants to use Windows. Even as Windows user i have to admit my defeat that if you are a niche user you will get next to no attention... Windows has had window focus issues and taskbar (set to autohide) issues since Windows 7 and they never fixed them because who the ***** uses an autohiding taskbar right? Same happens with less common OSes. And its often easier to bash on the OS (i do that too because Mac/Apple really deserves it with their infinitely overpriced hardware, bad hardware and notoriously bad customer support... not to mention them reselling old features as new revolutionary things... thinking of when they introduced a feature that allows you to finally call people... like a PHONE) simply because it often actually IS the OSes fault (again mostly Apple... Linux just wants to be more sophisticated for advanced users which inevitably changes how things work and thus deviates it from the expectation that we call the norm). It's sad but there really is no solution, this is an unwinnable fight.

Idk? I don't have sub folders in my outfits... i simply have outfits for all avatars and outfits and that worked fine so far. If i really ever wanted to go crazy on outfits i'd take my own advise and start dividing my avatars and outfits into separate outfits so i can just mix and match them via right-click (add/remove to/from outfit)

I'd assume that she's talking about the original outfit window, not an inventory based one. Essentially what you did there is an inventory view that filters by the system folder "Oufits", at that point you could as well just use the inventory to begin with and when using the inventory... you can just make folders and sub folders... i fail to see what the actual "improvement" is other than having a tab that is forced into the outfits system folder at all times, you could do that in the inventory window itself and at that point... what is even the point of the outfit window... what even was the point of it to begin with other than slight QoL?

Did you try switching to a different shape after you're done (this will prevent a potential logout save failure and force it to save immediately)?

This should indeed be an LOD issue, if cranking object quality all the way to Ultra does not help then your mesh (the ears i guess you are talking about) are a very special case of too small (having an incredibly small bounding box possibly unrigged) and possibly also a very bad LOD (3 out of 4 levels are just single triangles to save on Ll). Either way you'll want to turn Avatar Quality higher (in case it scales with that for some reason, rigged mesh sometimes does) and set Object Quality to Ultra, then turn off Dynamic Level of Detail (this in combination with Object Quality Ultra should force it to render at full LOD at all times). If that does not help then this might be a rare case of mesh (LOD corruption) where you are seeing the one good LOD and as you zoom out/in you get an LOD that got borked for you somehow, in this case only a cache clear will help.

Sounds like the sort of thing where the Viewer's hardcoding will break its own neck or worse your inventory gets corrupted, given that this implies you can't create normal folders (thus sub folders) in the outfit folder i'd expect the Viewer to burst into flames when you open the outfit window and it tries to make sense of a folder with several subfolders inside your outfit folders. Allowing creating folders inside any folder is quite easy actually but there is probably a reason LL prevents you from doing so after all the Inventory has to have a certain... layout. And with how Outfits is based around accordion tabs that fold i'm unsure how you'd even realize a sub-sub... folder structure... accordions inside accordions? (that was horrible) Fold out folders like in the inventory?

Hahaha. Yea. No.

Is what exactly a thing? The console-style chat? No. Chat has been long replaced with a proper window-based chat system that allows you to close down messages and properly splits between nearby, IM and group chats. I have never understood the appeal of the old console-style chat, it is in almost every way inferior (except in size and technical terms). Speaking of the technical aspect, the only reason i see why you would prefer the console style chat (from a technical side) is because it is faster (or should be at the very least) since its just straight up text with a background, no fancy window and widget creation shenanigans but that's highly negligible considering that it almost pretty much no perceived impact, is just one of million things that slow down SL and trades the ability to close down messages (or open the conversation if you click the message itself). It would probably be better if they offered a couple more options like chat width so you can fill your entire screen like so many people seem to like or possibly some visual customization (like you can switch between different fonts and header styles) but that's rather miniscule QoL. I'm personally more pissed that they got rid of the V2 separated chat windows and instead made this abomination of V1/2 tabbed IM chat called CHUI. It is by far the worst chat system i've seen in any application that has online and chatting capabilities and i've seen many.

Its funny how every time im nice to FS someone else is less so. Well i never said its the finest of things, that is what happens if you spread your focus.

I'm not sure about the Furry community thing but given that the Viewer is developed by a Furry i'd say it kinda sounds logical i guess? People who are/think alike are often drawn together, using a Viewer made by someone who has similar hobbies increases the chances that this person understands you better than someone else might. I suppose you could describe it as "feeling more home-y". Apart from that its not even that rare or unique, given that several Viewers have Furry developers (Singularity, Alchemy, Black Dragon, Firestorm and even the official Viewer (((yes there are/were furry lindens too)))). But i'm pretty confident that Firestorm is still the most used Viewer by a wide margin and i doubt that's going to change anytime soon. Firestorm had the fortunate luck to be a successor (actually a chain of successors) to wildly popular Viewers which gave the Viewer a massive head start and put it in everyone's mouth so to speak... just like i had the fortunate luck to have my Viewer essentially become the successor to the niche Kirstens Viewer which was known for photography, also photography is still a niche activity (although with all other activities in SL grinding more and more to an halt over the years, it has become more and more popular) and not something most want to (or can) focus on. I'm sure if Firestorm were to make a photography/visual focused Viewer it would be immediately a big hit, if they were to put their heads to it, similarly i could start turning my Viewer into a Firestorm-esque jack-of-all-trades Viewer to appeal a broader audience at the cost of my sanity (or whats left of it) and with some time and "advertisement" i could probably get close to Firestorm's userbase at some point. Neither of us however is interested in doing so and it also is kind of ... well a bit of a dick move and something of an "unwritten rule"? silent agreement? that we don't do that and leave other Viewers to their stuff. I mean common, do we really want to have one single Viewer for everyone to use? Nah. But on a serious note, if you were to pool all developers into a single kitchen and have them cook up the ultimate one-for-everyone Viewer it would probably end... very very badly. What happens if you take several developer groups with different interests, different goals, different focuses, different skill levels and different ideas of how and what the Viewer should do and put them all together? Armageddon. When it comes to the colors, different Viewers do have the same renderer but may change or alter how certain things look. Both BD and Alchemy will look different than the official Viewer, not necessarily because colors themselves are touched but other features can impact how the final image is ultimately displayed (tone mapping is one such example, using different precisions for certain buffers might also change how things look, see high precision specularity in BD). Apart from what Wulfie and Henri already said, your monitor can drastically alter how even the exact same image is displayed differently and that is not yet accounting for the fact that each and every person perceives colors differently. Adding on top of what Coffee said, it might not just be LOD (for the mesh/object) but also for the textures. Your own textures are always shown in their maximum quality whereas they may not use the full resolution for others, your own textures can also look better for you than they do for others (not exactly sure what it is but it seems like most of the time other people see it more compressed)

Alright. If its already set up to be masking (assuming it is set up correctly) there are two things that could be happening here. For centuries SL has had this weird issue that sometimes the alpha mode is set wrong (corrupted) and defaults to alpha blend (because thats the default alpha mode) making objects that are not supposed to be blending use blending. This can usually be fixed by a relog but might require you to reattach (detach and reattach) the object in question. The other thing you might be seeing is that the object (your eyes) are fullbright (are they?) and you are using Volumetric Lighting (which will shine through your eyes. An indicator for this is that your eyes only seem to be alpha wherever they do not have your head as background (blocking volumetric lighting), every single picture you are showing your eyes in an angle where they are in front of either something far away or the sky, giving Volumetric Lighting enough space to be added and shine through from behind your eyes, you can use "Include alphas in depth" checkbox in the Depth of Field section to force alpha being "opaque" for Depth of Field and Volumetric Lighting (default SL behavior) or you can turn off Volumetric Lighting. To be 100% sure what it is i'd have to see it inworld though, we could meet up inworld to have me take a look at whats is up with that.

If one is the back (the eyeball or pupil) and the other the front (specular transparent face) then this would be as easy as setting the back to none and the front to alpha blend, this would also fix lighting and make the eyes immune to any possible alpha blending issues with glasses for instance

Good old alpha blending issue. Love it. First things first. If one piece has alpha blending the entire object will not be blended, assuming you mean one prim out of multiple inside an object (linkset). Same goes for faces to some degree. If all of them use the same texture, they are all flagged as blended (by default) which if they overlap will cause this issue. However, both with faces and individual prims they can be individually set to either use blending, masking, emissive or none regardless of one another. I'm not sure about these eyes in particular but i'd assume they are not split into faces (one for the outside, one for pupil etc, you can check this by switching to face mode and swapping through faces via the menu, there's a face count in the object info display in your tools window) and they are obviously not made out of multiple pieces, killing these two options. This leaves only the hacky fallback option of turning back on Automatic Alpha Masking (Dragon - Develop - Rendering), it is disabled by default because since the introduction of materials it has done nothing good but give people the false impression that their content is properly designed (when as shown here) it clearly isn't. Lots of furniture, heads (sugarcult and kemono for instance) and other things use textures containing an unnecessary alpha channel, flagging the face as alpha which not only increases texture size, but also reduces performance (because the object is now rendered as alpha which is super slow) and has a lot of sorting issues (which aren't often immediately apparent) but will fail and break apart under many circumstances and can easily be distinguished by the absence of SSAO, wonky DoF interaction, pixelated shadows, weird light interaction and straight up weird or broken lighting. Automatic Alpha Masking usually does a decent job to mask these issues because not everyone runs around with shadows enabled (and often times entire buildings which house said furniture are in shadows, hiding the issue) but if you turn on Highlight Transparent you will see a lot of things in regions that are alpha which really shouldn't be.

Well this is the very reason i've kept BD to a single skin, just a single skin can be a tremendous amount of work, having multiple (if they aren't just recolors) can multiply this amount of work especially when they require extra code to function due to their fundamentally different functionality. I've always wanted to do extra skins but i'd be limited to color changes only unless i want to double my work. Now add localization to this whole fun and RIP. I wish LL wouldn't constantly finger the UI like crazy when theres hardly any need to, instead of one massive sweep to overhaul the UI.

Let me blow your mind then. You can actually walk with AWSD and type at the same time too.

You can't. Random eye movement cannot be disabled unless you mean disabling looking at things (aka LookAt beacon). This can be done via the official guide: https://wiki.secondlife.com/wiki/Show_Look_At Also in a post above i explained that preferences offers the option to limit the eye look in degrees, essentially netting you the same effect as turning it off.

I'll be adding a "re-pose" button that will recapture all inactive bones, this will allow you to toggle off bones, modify them with your animations and then have the poser recapture the current pose for those bones. The poser does NOT necessarily overwrite all bones, just active ones (you can disable them by double clicking for instance although it was reported that this doesn't seem to be working properly as of right now, i will have to investigate that)

That's simply not true. Any and all 3D games should be able to use all your GPU's VRAM (given a little buffer for windows of course). How they do it is a totally different story though, SL in particular is incredibly inefficient when it comes to GPU VRAM, effectively allocating every texture twice into memory which massively bloats the VRAM usage and effectively lowers how much VRAM we really have. 6GB easily become effectively 3GB. With how many textures we frequently see in SL it's quite normal to assume at least 2-3GB usage. More if we are talking about big textures (although 1K really isn't big). Not to mention that the texture memory setting is misleading and doesn't even represent how much the Viewer actually uses, 512 is roughly 1GB in reality (split roughly 700 / 300 for both memory pools).