NiranV Dean

Im very much infuriated by Firestorm because its made to dumb down people who still have mental capacities above or around average and handholds those that do not instead of teaching them to get better. The way FS spells out every obvious option as a sentence explaining what it does is so much worse than what LL does with their obvious "idiot proof" labels that assume you are a mental retard. This is what tooltips are for, when the option label explains the option in greater detail than the tooltip which at that point could just be "^this" or "what the label says", then something is wrong

Excuse me what? How are shortcuts annoying? You don't have to use them, they are completely optional. How are shortcuts more steps? The whole point of a shortcut is that you can directly access a function at any time, there is only a single step. Also CTRL + Alt + T is THE common Second Life basic shortcut anyone should know. It's like the global Copy (CTRL + C) and Paste (CTRL + V) and Search (CTRL + F) functions. These are things absolutely everyone must know. They are like knowing how to put one foot in front of the other to walk.

I very much do not agree that reset skeleton in any capacity is a poor choice. I'd never ever recommend anything other. Others having to reset skeleton you is but a mere minor inconvenience. One i'd see being fixed but its LL we are talking about, in the meantime simply jump 1000m up and back down (if you HAVE to undeform yourself for others and can't be assed to tell others to do the obvious reset skeleton for you), the "Back" navigation button is very handy for that.

I did mention that it is local only and i did mention that undeforming for others simply requires "poofing" for a moment.

It is CTRL + RMB for default. You might want to correct that.

I think i might accidentally be unable to merge the latest 7.1.1 code for a bit longer. Covid really got me bad and i think its suddenly getting worse again...

Pretty much this. Undeformers get you "close" enough that people normally don't notice. Also you cannot test this with a single bone, it is highly deform, undeform and shape dependent, i've most commonly noticed it on shoulders which usually end up being slightly wider than usual. Also there is no point in using undeformers, thats why we have the reset skeleton feature to begin with it is infinitely superior to deform animations, respects all active deforms (such as for your attachments) and systematically reconstructs everything back to how it should.

Note: While it is out of Alpha, i still don't consider it a "full release" worthy update hence why Beta. It still has quite a bunch of issues (and i'm not talking about PBR), the merge with PBR has left a lot of completely random parts broken or wonky. Before i can even try looking into PBR itself i'll have to work down the constantly growing list of bugs that people keep finding. After that i can start looking into PBR and what is and isn't official behavior. I think i've added the HDR Scale slider to preferences in 5.0.1 (with a bunch of others to fine tune the sky auto adjust thing and an option to turn it off completely). In regards to the clean install: Generally speaking it is almost never required to do a clean install of the Viewer unless it is a massive update that reworks caching (or in this case basically the entire render pipeline), on my local builds i generally do not require to clear cache or settings so whether it is actually required is usually for the poor testers to find out... and sometimes i simply just forget to mention that you should. Although a version jump from 4.3.2 to 5.0 should be indication enough that it would be a good idea especially when facing problems. Also oof at that shadow issue. However if i see that right and this is for 7.1.1 i do not yet have these changes. I'm still pre 7.0.0 (missing a couple idk maybe like 20-30 or so)

That was in the first version, it has since been fixed, the Viewer only saves keyframes you actually added now. Per-bone priority is also coming, now knowing that its actually working. That was posing others

Hey good thing you remind me. Since intel has finally managed to catch up and their latest GPU's were finally capable of compiling the shaders required to run Deferred Rendering (which is now completely obsolete since PBR gets rid of any pre-Deferred and forced me to revert to LL's shaders which run fine on Intel) i can finally get rid of those limitations (until i reimplement my rendering changes and Intel refuses to work again. It also wasn't nonsense, it was only logical to disable Deferred (and thus 99% of the Viewer's rendering features) because it simply wouldn't work on Intel (until their latest GPU's) due to unknown shader compiling errors on Intel GPU's only. Leaving these options enabled confused users because they thought these options were working (because they were ticked) but in reality they weren't. Users couldn't tell the difference because there was none, it was simply not working leaving users to believe everything was fine, they would then turn up to me complaining that they can't see shadows, depth of field, materials and so on and with bad indoor shots and super jpeg compression it was hard to tell if Deferred was even enabled.

I'll have to check it out when i have time. Currently in preps for the PBR Beta.

For those buttons to be detected, specifically the D-Pad which is currently not possible with what we got, they would have to implement something that can detect these, so clientside there has to be some extended support too, which means i should probably joink this as i've been wanting to support the DPad for a long time

You might be high up, if so move below 10m altitude for the maximum math precision. As you go up in altitude, precision of positions slowly become worse as you shift decimal digits. -> every tenfold you lose one decimal digit precision.

Interesting, i suppose this answers a couple of my questions i could never figure out about both BVH and ANIM both which are incredibly undocumented in SL. So what i get from this: Yes, bone priorities actually work (good to know so i'll add it to my animator) AND BVH not writing any of the crucial animation information explains the upload dialog, tho in my Viewer .ANIM has the upload dialog now too, to allow changing any value before upload. Though this does not explain why my Poser animation is overwritten by a select few face pose HUD's since the animation is created internally with priority 7 which simply shares its priority down to all bones automatically.

Again this doesn't seem to be the case when used in AO's. I have a particular case where my running and turning animations overwrite priority 5,6,7. Everything else however doesn't. I'm using a serverside AO. All animations are priority 4, standing too and they do not overwrite them. It seems very particular.

According to the Viewer code it goes up to 7, technically 5 and 6 don't exist. They aren't defined, although since 7 is defined as the last they technically exist, just not specifically defined in the list (they are still automatically counted though). 5,6,7 are all overtaken by Priority 4 in an AO maybe i should have clarified that, playing a priority 6 does overwrite 4 and doesn't allow it to take over the 6, however using these in an AO does seem to be buggy. Even my Poser which uses ADDITIVE_PRIORITY (7) is still overwritten by some cheeky face posing HUDs.

Nothing you can do about that sadly. The Viewer treats priority 5,6,7 as 4 and animations with priority 4 that come AFTER will overwrite it. Something i might want to look into and fix.

If you don't use shadows you are throwing away most of what makes Black Dragon good for photography (graphics wise), if you now turn off SSAO as well then there's no reason anymore to use BD at all.

The most recent release can always be found via the Download section on the right sidebar on my blog. (Direct links are bound to die as i remove old versions) https://niranv-sl.blogspot.com/ Note that it does not include the above improvements yet (that would currently only be in a test-test-super-test build but will soon become part of the PBR alpha build if i get some time to work down the still (surprisingly) quite small buglist)

I've not heard about a lock mouselook to head rotation option yet, locking your view direction to your head's will absolutely cause you to keep rotating infinitely if not used with something like the option to turn up the rotation-degree. This can and will only work properly while being stationary and locked in your rotation, aka when sitting down.

BD doesn't need a restart and neither should Catznip (where my Borderless Mode is coming from)

The issue is obvious. 8GB is not enough to run any decently modern Viewer. Anything starting from the Performance Viewer or 64bit will require every little bit of those 8GB... and windows... and you can't even use all of it either! You will crash before you even get that high.

You mentioned making sure they look like yours. I gave specifics, specifically i recommended not to set SSAO Effect to 0 like you did, 0 is close if not outright the same as "off" and thus wasting resources that could otherwise be used for improving the lighting.

You are using light mode. As Quistess mentioned this is a formatting issue. One way would be copy pasting the text again and clicking the "Copy as plain text" notification that should appear a the bottom. If you can't edit your post anymore make sure you are still properly logged in.

Shhh! Don't jinx it. It took LL years to get here.