NiranV Dean

Certain animations will not be blocked by the Poser due to how it works, the Poser only effectively blocks movement and rotation on all main bones, if your animations do special things (such as deforms) to animate it won't be blocked by the poser. SL is a really hacky place and so are animations.

If the poser wasn't overriding all your animations it wouldn't be working at all, which can sadly sometimes happen with some very very specific unknown animations on pose stands that i can only explain as being super hacked priority somehow. The poser uses an internal priority higher than any animation can ever have and it is still sometimes overwritten by some random pose-stand animation. This however gives me a new idea of a "recapture" function. Since you can disable individual bones to allow them to be animated, i could use that to have a function that allows you to take another snapshot of the current pose of all currently deactivated bones.

Sounds like light softening is off, in FS its included in Ambient Occlusion, make sure its enabled.

See there is a probably that is too vague for my tastes. There is still potential feedback to be had.

Any specific reason for this if i may ask or just generally along the lines of not wanting to use other Viewers?

I don't seem to be able to reproduce this: I expect it to be fixed with an upstream code merge but for now i can't reproduce it, i'd need that windlight preset you are having this issue with to test

EDIT: On PC now, reformatting. Known issue that happens under various conditions, usually one of these fixes it, it's most commonly an issue of a leftover shader or xui file from a specific older version that had some shader level 3 files removed. Remove the entire Viewer installation folder and reinstall the Viewer to make sure there are no leftovers from previous versions. Cleanly uninstall all 2013 and 2015/2019 Visual C Redistributables and reinstall those coming with the Viewer. Cleanly uninstall and reinstall your graphics drivers.

See that's the whole point i want the Poser to get server side sync, it would immediately and fully solve all issues and add functionality that can be reused by other functions too. Serverside would also allow as you rightly suggest using the permission system to "ask" people to animate/pose them. Like I said, all of the issues and abuse cases I am fully aware of already and all of them I already have a solution for, yet everyone insists on the Poser being evil and must be stopped or at the very least changed drastically. My particular solutions for the pose "stealing" thing aside from my opinion that at this point single-frame poses would simply become worthless presets and no longer eligible for full blown IP items (which we know LL really doesn't give a crap about seeing that graphic presets and shape presets are IP protected still) are: A) A mode split. There is an "Edit" mode which is the default mode, it does what the Poser does currently, take a snapshot of your exact current pose and allows you to edit them, exporting them only as local files to be reloaded to be used for private stuff (and in the case of server side sync would also allow you to keep poses around for when you are sitting on objects and make tweaks to those. You could then simply reload those and there would be no way of "stealing" poses, they can only be exported locally. The second mode being "Create" mode, starting you from T pose and allowing you to create a pose from scratch and export it as item, this mode does not allow you to load local poses as it would allow "stealing" poses. It is solely there to make new poses from scratch for people to export and sell/share. It has to be specifically switched to and the "Edit" mode will also warn you beforehand that you cannot export your tweaked pose unless you are in "Create" mode. Both modes use the server side sync to be visible to others, both modes can use it to ask others for permissions to animate them, both can animate others. The difference is solely that one allows you to export, the other only tweaking and saving as local file for personal use while one starts you in T pose, the other in your current pose. Pretty simple. This would keep full functionality of the Poser, with server side sync it would fulfill all my goals for the Poser and it would be capable of replacing HUD based implementations completely. This is definitely my personal choice. B) As you already suggested an offset based export. HOWEVER an offset based export would be largely unintuitive and useless, it would often require almost exact conditions/poses to be played beneath in order for the offsets to achieve the desired pose. Option A would be a much better implementation of this and would work regardless of your initial pose or animations playing beneath. As I see it currently, all possible problems anyone has brought up so far, including missing things (like not being able to see poses) and abuse cases can all be fixed with 3 simple words that I keep repeating to LL like it is some mantra: Server Side Synchronization. That's why I bring it up every single meeting, everything literally hinges on this one thing, the entire Poser rises and falls with this very request and so far LL hasn't been very cooperative and I am NOT going to allow bringing a gimped Poser into official just to meet some artificial "first implementation" goals, I'm not taking compromises again. Look at my snapshot floater improvements, they still have NOT been implemented, even now after 360 snapshots are in which they were supposedly stuck in. See: https://jira.secondlife.com/browse/STORM-2118 it has now been 6 long goddamn years. 6!!! For something that was done a mere week after! I AM NOT going to implement a gimped Poser just to have it sit there in its sorry state for 6 more years before it gets forgotten as just another one of Niran's *****ty little failed experiments. I will either deliver the Poser in FULL with all its features and MORE or not at all. Also cutting off Rowan here: The main advantages from a technical level are: No HUDs needed (this frees up an attachment slot, script count and script memory as well as texture memory) No artificial limitations (script memory, bone targets, usage speed) No lag No precision limits - the Poser can be as precise as you want it to be given I don't clamp the values. No angle and rotation limits - the Poser can rotate any direction as much or as little as you want thanks to the theoretically infinite precision No cost - the Poser is completely free, always will be and any improvements or extensions do not require uploading anything anywhere No build requirements - the Poser does not need to rez anything and does not need scripts to function, it can work anywhere, any time on anything, anyone and as many as you want, you can create entire 60 man group poses if you wish. Potential future improvements - the Poser UI is completely client side, can be completely customized per Viewer or skin and anyone could make minor or major improvements to any part of it, this includes proper bone rotation widgets. Availability - the Poser is available to anyone, not just people who make pictures and pay thousands of Linden Dollars for a HUD. In short the Poser has everything posing HUDs have except more, better, more precise, faster and more reliable at less cost and less requirements. If it wasn't for the missing server side sync it would be a straight up AnyPose on steroids. The Posers goal is to replace posing HUDs completely.

I didn't even know Moisture level has any impact whatsoever but i'd assume it's probably because the Viewer is currently not up-to-date with the latest changes. It has been lacking behind several many versions, several of which are most likely EEP fixes and improvements. About the remember login and fly state I'll have to take a look into. As far as I can tell it remembers me just fine i can just hit login whenever the login screen comes up but that might be because my details are already saved and there is no issue reading them, just saving them might be broken. EDIT: Both remember login (and remember password) as well as remember fly state on login work fine. Are you using the latest version? Black Dragon 6.4.18.48191 (64bit) 4.0.5 - Refreshing Dragon

I'm not a fan of the slider controls either but i'd have made bones editable via the Build/Edit tools already if I knew how. I'm still thinking of and exploring alternative ways of adding better or at least faster (or more precise) controls for the Poser. If it was that easy it would have been done 2 years ago already. It was a major pain to even get the slider controls where they are now. The original purpose of the Poser as its name implies is tweaking poses, this automatically includes the ability to make them from scratch (obviously), the Poser has also been extended to allow some basic animation making and with some proper key-frame editing tools can be turned into a full animation editor (already planned). The poser has much more use than just simple pose tweaking. It's required serverside functionality alone opens the doors for a lot of functionality down the road, such as synced IK (if IK ever becomes better to begin with) which could even be extended to be used for VR body controls (yes, actual VR movement could be achieved with this). We're merely scratching the surface. Being able to pose others via scripts would be a logical extension and would immediately obselete AnyPose (which was the original goal to begin with). That is simply not entirely true. I made a very specific comment that i find it incredibly unfair of LL to judge the Poser this hard due to potential abuse when there are other features going around being nothing but abused that includes a very extreme example of being able to derender people's clothing in places they shouldn't be naked, such as around child avatars, one of the worst and probably easiest ways to get you banned. As you already implied, someone could set up a scene and create a fake abuse report that could in theory easily get you banned, especially with a hot topic such as child pornography. I'm sure a Linden wouldn't even look twice before they hit that big red button on you. But once again everyone seems to forget the obvious here. You can create fake abuse reports? Well block abuse report while the Poser is open and/or in effect. You can't create fake reports if you can't report at all. Everyone seems to act like the only thing coming from the Poser would be abuse and then going on and on about it how bad said abuse would be and how nothing could be done about it, when there is plenty that can be done about it (all of which i've already spent a lot of time thinking about) and there are even more features elsewhere that are being abused and we can't do anything about. But hey, the Poser, the Poser, the Poser, its always the evil Poser, it always gets the shaft, over and over. The Poser is the tool of the devil and will surely do nothing but evil. I'm sick of hearing it, I'm sick of hearing all these stupid stories about great features that could push SL forward being gimped or downright dropped because they are judged solely by what some ill-minded people could do with it. I've been hearing this for 4 years now and its tiring and my patience has simply run out, it's the same thing over and over again. If they want to cut down on abuse why don't they start killing off derender. LookAt names. LSL take controls over your balance. RLV/a. The reason I haven't started working on the pose exporter is exactly the above mentioned bull****. LL wants me to implement an exporter but then they complain that this would open the doors for stealing poses via the Poser so their solution is gimping the Poser and putting you into T pose so you'd have to recreate the entire pose, essentially defeating the purpose of tweaking one, this will make the Poser just harder and slower to use, especially with the finicky controls. The reason I haven't started working on the animation editor? Same goddamn reason. LL will immediately tackle me "oh no abuse abuse abuse" because people could essentially steal animations, heck they could even take an animation and edit, turn it into something else, mod permissions on animations would finally make sense. The reason I haven't been working on any of my big plans lately? Because I'm wasting my goddamn time doing so, they will get rejected or some shortsighted uncreative individual will say something that LL doesn't like hearing, red-flagging the entire project and putting it at risk of being shelved just like everything else I've tried offering to LL so far. And I have plenty of awesome ideas aside from a full animation editor, server side posing (including VR motion, free motion, IK syncing), animation/bone remapping on upload and dynamic bones (jiggly/flexi ears, tail... anything really).

In addition to the above, make sure Render Projector Image Reflections and Spotlight Light Refractions are on too, they are for the receiving end of projector lights (e.g the actual light and texture being projected ontop of something as well as the light reflection it creates on light reflecting surfaces). Also make sure Global Light Strength is NOT set to 0.0 is affects ALL lights.

Since your questions have been generally answered already i'll be going into detail. Video/Avatar detail I assume you mean the object and avatar quality settings which can be found in Preferences - Display, pretty much right at the top you'll find the Quality options section. You can find Avatar and Object quality there, note that Object quality cannot be set higher than 4 (the widely accepted new maximum). Setting this higher via debug does not work and will be ignored, the Viewer hard caps you at 4. This was a design choice. Windlights Since EEP Viewers do not come with windlights anymore (exception being Black Dragon) any and all windlights can be found (or imported) via the inventory library where most common ones have been exported to. Black Dragon specific however you can still load and save old windlights directly just like you used to, they still go in the same windlight folders in the user_settings or app_settings folder. This is in addition to EEP settings being supported from inventory. Note that old windlights will look different than they did before or might straight up break due to the differences. Controls Go into Preferences - Keybindings, make sure you are in Third Person mode (at the bottom dropdown menu), find the entry that says Move Left - slide_left - Left, remove it. Find the one for right and remove it as well. Now find the Turn Left - turn_left - Q and double click it, hit Arrow Left and confirm with "Bind", repeat the same with Turn Right and Arrow Right. Camera I assume you are looking for an option to turn off the left-click on your avatar putting you into steering mode. There is no such option but as others suggested, turning said option off does the same as Alt-Camming on yourself instead. You can resume orbiting your camera around at any time by holding and dragging right-click, you don't need to Alt-Zoom again on something. More specifically LL prohibits posing others. I have made them several offers that i want some sort of synchronization through the server so everyone can see you pose, one that isn't an animation export. I am very adamantly against implementing an exporter as it means not only increasing the complexity of the Poser's surface functionality, it will undoubtedly also cause a lot of trouble and a lot of headaches, specifically an exporter would mean i can no longer offer the Poser to put you into a snapshot of whatever pose you currently were at the time of hitting the Start Pose button as LL sees this as possible copybot/abuse tool for what would essentially become worthless assets at that point (single frame poses). I'd have to force the poser to put you into T pose every time you start posing, which eliminates one of the key features the Poser was meant to be used for, fixing poses. Being able to make new poses from scratch was merely a side-effect of being able to fully edit your pose. See the whole conundrum about EEP and its settings being pointless intellectual property and being protected by a broken permission system and how much trouble it has caused us, the same would happen for poses. There is no reasoning with LL and there is no common sense with this kind of thing. LL wholeheartedly believes any and all assets must be protected, no matter how pointless, stupid or useless it is. The moment i'd add an exporter, single frame poses would become essentially worthless asset, anyone can create them at any given time directly inworld, perfectly fit for their avatar and any and all situations. Selling them or even considering them sellable items would become pointless. But look at windlights... they are graphics settings for the lighting system... look at shapes... they are "graphic presets" for your avatar shape... and they are both still being sold... sometimes for up to 1000L$ and no mod. LL is lucky i'm not in control, i'd stopped this nonsense over a decade ago, don't care about lil whiney people "but muh IP" -> "Dude any and all content uploaded to SL belongs to LL and we just decided that you need to stop selling 2 minute no-mod DIY shape presets for 1000L$"

Debug Settings are called Debug because they are meant for debugging purposes, they are internally used in the Viewer code to toggle things and these settings are not meant to be used directly, they are solely there so the Viewer has a bridge (in this case the debug setting) to allow the user to interact with it in a user friendly way, say the interface via Preferences for instance. The reason most of these options don't work is because in fact most of these options don't work, they were deprecated at some point. Many options were either replaced by dynamic functionality (like the Build button debug for instance) or they were outright removed (like the Pie menu debugs). I do not know why they are still kept (possibly backwards compatibility?) but the Viewer does not crash (and hasn't been crashing the past 10 years) when a leftover setting is in your user settings file which doesn't exist in the Viewer's default settings file, it will simply complain about it being a debug setting that doesn't exist and continue on. Same when the code toggles a debug setting that doesn't exist. Note that the Debug Settings window also displays all debug settings that you still have as leftover, if you were to create broken Debugs somehow they will be added to the Debug Settings window (given they were written into your user settings file). The Viewer can also dynamically create settings on-demand (it does so for window sizes and positions).

That is either the fault of the light blur pass or the post process FXAA both you could disable (although disabling the light blur pass while making everything sharper will also inevitably kill soft shadows and SSAO blur, both of which will look incredibly ugly). You could probably separate out the light blur pass in such a way that it would only blur SSAO and shadows instead of the entire lighting... or straight up implement separate shadow and SSAO blur both of which weren't considered due to their performance impact i assume. Doing one single blur pass that governs absolutely everything is cheap in comparison to doing it twice (or three times) for shadows, ssao (and lighting).

The important key here is that disabling range requests for meshes only, textures are one of the slowest downloads, they can take minutes to download, whereas meshes only take a couple seconds most of the time. Best case the difference between range requests and full downloads is we send less requests and have faster access to all LOD's at any given time. Worst case, downloading the mesh will take very slightly longer and no visual change is detectable (while still sending less requests). I'm currently in the process of going for some test runs and mesh downloads seem extremely fast every time. Disabling texture range requests obviously leaves me staring at grey for a long time due to so many requests being done at the same time and the textures only appearing after they have fully loaded (all mipmaps). But disabling range requests for meshes so far seems quite good and fast. But I'm also trying to find a very mesh heavy place.

And metrics have always been what has mainly controlled the direction of SL wasn't it? Everything controlled by numbers, metrics not by what feels good to the user. You mention the "curtain", hiding loading from view for instance. Everything factors into what people perceive as good and so far LL has been often driven by metrics and statistics which is what has lead to the sad state SL is in right now. Big numbers but they are meaningless, SL can handle thousands and millions of dynamic assets, does so many things at the same time without exploding (most of the time), but does it feel good to the user? No. It feels like we are playing something meant for developers, developers who never touch their software, we aren't using consumer software. This has always been SL's biggest failure, failure to develop SL FOR the consumer, not around it. This is why SL always fails to gain proper popularity, this is why SL always fails to keep people when it finally gets some attention, this is why SL is just running in circles and has been for 10 years now. Every single big thing that you'd now count as a major step forward was a disaster, lead to more problems or just revealed the problems with the previous system, just like the next system is going to reveal the issues with this current system because it is never done proper or at least future proof from the get go. Industry standards are there for a good reason, they work well and a lot of them would help SL if SL finally adopted them. We had this sad talk after the last two TPV meetings and I'm sure we will have it many more times. Most of you Lindens are simply not connected to your own software, to your own customers, you tell us you want to help us, want to make things better for us and I believe that most of you really want to but every time you actually get to do it (if you do that is) you do it wrong because you do not listen to us, you do not understand us. You do not understand the most common issues your platform has and the most obvious solutions for said problems need to be explained to you many times over with little effect, often a lot of confusion or even outright denial of its necessity. This has been going on for many years. Staying with the TPV meeting as example, we wasted two entire meetings to explain the simplest feature request anyone who has spent a tiny little bit of time in SL and seen LSL work and has some basic grasp of how Viewers and Servers work would immediately understand or at least not need such a long and massive explanation and reiteration several times over. Yet Vir failed to understand and got confused what was simply a request for a simple way for the Viewer to request an animation replacement (a request similar to requesting textures or meshes), a request that does exactly the same thing as llSetAnimationOverride, just from the Viewer directly. This this wouldn't be so bad if it was users getting confused or maybe 1 or 2 developers that have absolutely nothing to do with this might not immediately see how this could work, but from the meeting it felt like the users/TPV's immediately understood the issue and knew what was being asked for without them even needing an explanation, they were even offering future additions to said request, while the Linden side was confused and all over the place, as if they had never seen or heard of LSL let alone a simple request message. It is generally known that you Lindens often don't get around the "industry" or look into other products much and this comes from what you have given us over decades, it's not an assumption anymore, it's the sad truth and I wish you'd just go out a bit, explore other platforms, play some games, look at other applications but most importantly start using Second Life like a consumer, actively using it, exploring, scripting, talk to your consumers, get an idea what your software actually does and what it does good and what it doesn't do good. I'm sure you'll quickly find a lot of people willing to tell you a million things that aren't exactly good. I'd want you to start playing some common games, play online games, go try other virtual worlds, try Neos, try VRChat, see and experience with your own eyes what makes these so special and how they have solved similar issues. Just from playing VRChat alone I went all over the place, learned a lot about Blender, about optimization and content creation, i learned some Substance Painter, learned new things for GIMP, tidied up my sound editing skills a bit just to put all of this in use in the Unity Engine which offers an incredible amount of elegant solutions to so many of SL's issues, many of which could be implemented in one way or another in SL, some of which I'm already planning to bring over myself and some of which I already brought over with still so many being far out of reach for my coding skills or accessibility to the platform (no control over the server). It saddens me deeply that all we do every single time is just talk talk talk talk so much about it that at the end of the day nothing gets done or we get to the point that we (YOU) drop it. I have so many great ideas for improvements of SL, many of which will never see the light of day because either I can't or you won't let me. I've come around in so many games and platforms I could probably easily come up with a solution to pretty much any and all your problems and could most likely even give you an example game or platform that had the same issue solved in a good way. Go out! Look around. The solution to all of SL's issues are everywhere around us, you just choose to ignore them, even if we tell you them. I'm just repeating myself here but I'm running out of patience with this running in circles for eternities. SL could be more, far more. SL could be already the first step to a real metaverse, not this wanna-be nonsense. My twenty cents.

Oh? Good to know, i'll have a look at that. Now see, this is the kind of answer i want. Simply give me the option. Thanks Monty.

With a non-max LOD forcing value (which everyone has anyway) just zooming your camera or simply walking through the region once should already have you download 2-3 out of 4 LOD's easily (including the max LOD and the probably the lowest or second lowest with in-betweens usually being skipped, hopefully due to how fast you might be closing in, at least when using your camera). I highly disagree. Every other similar platform does it too, VRChat, NeosVR... and avatars in VRChat can easily reach hundreds of megabytes (if they include sounds, *****loads of 4k textures and many big rigged meshes with many blendshapes), and they don't have a problem doing it. Why do we have to split from the industry standard again? This kind of weird non-standard behavior in so many places is why SL is so ... lackluster, has so many issues, makes so little progress and often shortly after implementing such a behavior runs into problems (or later down the line when we realize that what we build was bad). We already split all asset types (meshes, sounds, textures) into their own parts, this makes SL incredibly modular and allows us to download only what we need but doing this for mesh LOD's is simply going too far for the sake of going to far.

We are downloading gigabytes worth of textures. A couple more megabytes per mesh don't matter. You're essentially cutting down on potentially 75% of the amount of requests needed to be sent, this both helps the server and the client having to process less messages and like I said, if you only ever download a single LOD you are expecting this LOD to stay for a while which is never the case unless you outright disable dynamic LOD and force a certain quality level. It's completely pointless downloading fragments of a file when you'll ultimately and quickly end up downloading almost the entire file anyway shortly after, especially since lower LOD parts are the much smaller fraction of the file, downloading the highest LOD (which is what is most often desired anyway) already takes the lions share of the file. Not to mention our cache isn't infinite so we'll end up recycling our cache at some point requiring us to re-request potentially 4 parts again, this for every single avatar in the entirety of SL, for hundreds and thousands of objects, every day, this adds up. I can understand that this may have been necessary at the times of UDP messages where they weren't exactly reliable and having only one part fail wasn't that bad or where they would have to save on bandwidth due to the limited amount of bandwidth per user (when downloading) but this time is long gone. Content download really isn't that slow anymore but is artificially slowed down and spread for no good reason, it only hurts the Viewer and the Server. I'd rather prefer to download a couple extra megabytes but get the entire file right away putting LOD handling entirely on the Viewer side right away without having it potentially be stalled for long periods because some LOD changed somewhere that hasn't been downloaded. Optimizing this process to be faster is just polishing a turd to be a shinier turd, it's never going to be a diamond. Everything ever does this and for a good reason but once again SL has to be a special snowflake. Add an option to force the viewer to always sent a single "get me the entire file" message. I'll gladly use it. It should also speed up my Viewer loading meshes tremendously.

That is a major oof. And they say I'm a pessimist always imagining the worst. This IS (almost) the worst. I mean i'm not surprised i was kinda expecting something along the lines but... wow. Just wow. Why? This is so incredibly inefficient, why would the Viewer request 4 separate pieces of the same mesh file when .... oh this is Second Life i forgot. Right... right. Seriously why request essentially the same file 4 times just 4 different pieces of it, that's 4 times the amount of requests and 4 times the chance to fail/bork something. ESPECIALLY considering that the Viewer is expected to switch between LOD's quickly at any given time, the point of requesting them separately is completely mood, you should straight away download the entire asset. This explains why some LOD's of meshes fail sometimes.. for apparently no reason... and all this time I thought it was a failure on the Viewer side somewhere in the mesh rendering/decoding or something... It's as if you expect the Viewer to only ever see only a single LOD ever for a long time... as if you wanted everyone to turn off LOD's... One of these days I'll have an heart attack ...

That is... i think not true at all. The Viewer cannot request certain LOD's of meshes. A mesh is a single file that contains all data for all LOD's, the Viewer always requests that single mesh file which will give it all information required to display all LOD's. If the Viewer had to re-request the same mesh over and over in different LOD's that would be... beholyjeebuschrist. I know LL does stupid things sometimes but that would be downright evil.

I'm kinda out of ideas then. I don't use any of the human bodies so i never get the experience the wide array of issues people seem to be having with these. I suppose all you can do for now is wait and hope that the next update with the latest LL code is going to fix this.

In that case i need more info, sys specs, viewer version, any particular things to notice (are you using alpha layers or tattoo layers? i've been reading that these seem the be the root cause)

You should be able to use Bootcamp to use any Windows Viewer on Mac, there is no need for official Mac support (although it would obviously be better).

This might be related to an issue that we recently found. Try the official viewer if your feet do the same there too.