NiranV Dean

I heard about that bug too... i wouldn't know whats causing that tho. Nothing has changed in the way controls work, at least not for keyboard. Controller however has been completely reworked (and was infact inverted) but thats completely separate. Guess i'll have to do a clean settings run and press all the buttons. If you do find it let me know so i can fix it... i have a slight suspicion that mouse invert (or worse even the controller invert options) might be doing something stupid.

Change the controls! Preferences - Keybindings. Do be aware that keybinding in the current release might be tricky. There is currently a bug that if you select an action from the dropdown the leftclick to select will pass through and be set as new bind, because mouse clicks and keys are separate and they don't clear each other, you will end up with a mouseclick being bound in addition to anything else you pressed. The solution is opening the dropdown and going through it with the arrow keys and selecting it with Enter. It's already fixed but i'm looking to make some more changes. 1-2 little bugfixes are a little bit too few for another release so soon when its not an emergency.

Yes. The double-click action is hardcoded and needs a code change and recompiling the entire Viewer.

What? No. If i figure this ***** out you can be sure that i'll smack LL on the forehead a couple times. This is essentially what i wanted for the Poser for 5 years now and whats amazing is everyone can see it and it looks like you can use it for ANY bone in the skeleton, this means the Poser is a GO. Live posing here we come! You can be sure that i'll not just abuse this system for the Poser. I'll revisit my headlook improvements, with this i can make them not only play on top of other animations for yourself but visible for everyone, avatars are finally going to look more alive. I can extend this to mouselook so you can see your head movement looking around even while other animations are playing. The new IK system might also be useful to make make something better that also plays on top of the current animations, heck we can use this to go all the way and make our hands PHYSICAL so they can't click through things, with surface raycasting we can check if something is in the way, and have the hand stop on the surface, then sync it to others... my head explodes just thinking of all the ways i could use this...

I was just recently looking into the VR Viewer code and thinking of implementing it... with the twist that you can actually move your head and hands.. now with THIS i could make these sync to others. This ACTUALLY gives me reason to do this. Niran experimentation time inc. Fred not, as far as i understand i can absolutely abuse this system to sync the poser in exactly the way i always wanted them to add to begin with. Now they are LITERALLY giving me what i want, except not with the goal to support the Poser but i can make the Poser use this system. Theoretically i can not only abuse this for my Poser but i can also abuse this for LIVE animation sync, guess it IS time after all to implement the animation editor i've always been wanting to make. If i figure out how to abuse this server side sync for my stuff expect me to vanish for a while, i'll be sitting in my basement creating dasdardly evil things while laughing maniacally.

Only then are you concerned with common mesh creators? That's concerning. Common mesh creators don't even know how to optimize their stuff, let alone how easy it is. God forbid you want to make mods/clothing for them.

Why do people change the default font on this forum, or the default background color or the default text color? It makes it hard for me on dark mode to read, sometimes straight up impossible. Leaving the default color simply makes it adapt to whatever skin (dark or light) we chose and everyone can read it.

Which means you added/modified code. The whole point i was making is NOT doing that because you said "adding more color options would add even more code bloat".

No via preferences. The baseline preferences window has color swatches hooked up to a function to retrieve colors and set them already (for nametag colors for instance). It looks as follows: <color_swatch can_apply_immediately="true" follows="left|top" height="40" layout="topleft" left_delta="-49" enabled_control="NameTagShowDisplayNames" name="mismatch" top_pad="7" width="44"> <color_swatch.init_callback function="Pref.getUIColor" parameter="NameTagMismatch" /> <color_swatch.commit_callback function="Pref.applyUIColor" parameter="NameTagMismatch" /> </color_swatch> Pref.getUIColor and Pref.applyUIColor can be used on any color swatch inside preferences and filled with the name of the color in colors.xml we want to target in the parameter slot. This allows targeting any and all colors as long as they are defined inside the colors.xml, which in turn means any color that is set somewhere in any of the UI files since we can just set any UI widget to use any given color defined in colors.xml (or define our own directly). This means the entire UI is recolorable, by simply creating an override skin. Since the skinning system is intelligent enough to take any missing parts from the base skin we can simply write a very basic override for any part of the UI by navigating down the folder structure inside the file and targeting whatever parameter (in this case color) we want to change. For the above color swatch inside my panel_preferences_ui_colors.xml this could be as simple as the following file: <panel name="UI Colors"> <scroll_container name="ui_scroll"> <panel name="ui_colors_panel"> <color_swatch name="mismatch" can_apply_immediately="false"/> </panel> </scroll_container> </panel> This would change the attribute "can_apply_immediately" to false for the color swatch named "mismatch" inside UI Colors/ui_scroll/ui_colors_panel panel folder structure. We can do the same with say color, text_color, bg_alpha_color and so on to change the colors and ONLY the colors of something. Doing so would save the changes past updates and using the color swatch to change a defined color in colors.xml allows us to save the color changes past sessions and updates too. This is why i love V2 skinning, its so wonderfully dynamic and infinitely extendable... and i hate it because LL abuses it to do bad UI translations, constantly redefining width and height of buttons they translate when they REALLY shouldn't and the translation fits into the button just fine... or they could... you know have the base button (english) immediately be laid out to fit for ALL languages, in fact why can't the entire UI just be laid out to fit them all. It grinds my gears when you change something in the english UI and suddenly a polish, russian, spanish or whatever user comes up and is like "my UI looks completely *****ed" because in the localization they redefine a lot of layout parameters turning the UI into a freaky amalgamation of the localization and the original and if you don't know that you look around trying to figure out why its breaking.... THIS is why i got rid of all languages besides english and german. My Viewer still has no reset for color swatches but that's actually a good idea, resetting colors either involves manually deleting the entry from your colors.xml file in AppData, deleting the entire file (which resets ALL colors) or using the menu entry buried somewhere in advanced/develop i think (which also resets all). The user friendly color swatches don't need any extra code, at least not in V2 where color swatches can be easily added via XML only and preferences has a generic retrieve and apply color function that can be used (as described above). But i wasn't talking about your Viewer. Baseline the script editor defines its text colors in the keywords.ini file which makes sense as it allows us define a separate color for every single LSL command or data type but has the issue that we cannot change them easily via the UI unless we specifically code it to use targetable colors (from colors.xml for instance) or separate debug setting colors (which would be stupid to do if there's colors.xml already offering a much better solution free from our settings file). While yes the script floater is at its core just a text editor and we can change its background color (since its just a text field widget) we cannot change the text inside it without editing the keywords.ini file making a lot of the text potentially unreadable or very eye soring depending on the chosen color. Also editing the keywords.ini file is not saved past updates either. What you should do is make a dynamic system that lists all available script commands and allows you to sort them into color groups, so people can recolor every single LSL command dynamically to their liking, the system would be infinitely extendable, anyone can create a new group for any commands and give them a specific color... well or you could just hardcode the... what is it? 12 colors?

Sounds like glow quality is set to 8. Not sure if FS has the option in preferences but its something along the line of RenderGlowResolutionPow i think. Might be worth searching for all RenderGlow debugs and finding it, setting it to 9 (which is what Ultra preset is supposed to do) will allow you to set width much higher and improve glow quality alot

That's glow width being set too high. With glow quality 9 your max should be around 6.9 any higher and you start seeing this.

Is it possible in the official without editing the keywords file? I was referring to Henri saying that it requires extra code to set it up, giving an example how it doesn't with notecards and most of the UI and another example how it does require code for the script floater specifically because it isn't using the colors.xml. Also, i forgot to mention that any color in colors.xml is saved meaning any UI part using them will survive relogs.

Funny enough Nirans Viewer had this.

BD uses the same code for profile feed uploads, i've checked. No idea why it fails but it does on the LL Viewer too for me.

That sounds awfully familiar...

At least in V2 you do not need to add any code for color options. All colors found in colors.xml can be changed and hooked up to a color swatch UI widget without a single line of code. HOWEVER. You cannot change script floater colors, notecard colors should be fine though. To add to what you wrote: Changing the notecard colors will require you to go into the notecard floater file (preview_notecard.xml) and change its text field colors to either a different one found in the colors.xml that are already existent or added for this purpose (which can then be targeted via color swatches). Otherwise you'd have to change the global colors for all text fields, this may have unintended results as some text fields may be set up to use a certain color, changing them might make the text unreadable. Back in Nirans Viewer i did offer a host of common UI colors to change via the color swatches to recolor the total UI to your liking. I have long dropped that idea, while it was cool it was... too subtle and ultimately not supported anymore with Black Dragon's new skin that was made to offer a very specific look, changing the colors would impair readability and destroy the overall look. BD uses the default font LL uses. I have not touched fonts and i don't recommend changing them either because the UI is absolutely trash when it comes to fitting itself to different fonts. The entire UI is designed for a very specific font, replacing it would break large parts of the UI. (also why is it scaling this image slightly up rather than showing it in its original size, its making it blurry...) (also hhnngg why is that edit button one pixel off to the left... *insert Heavy "who touched my Sasha" meme*)

I'm using the old framerate limiter (that LL removed because it had adverse effects on Intel GPU performance), sadly it is very broken now and only allows limiting in certain amount of steps (didn't look like 10 it was seemingly random but also somewhat linear). With it i can currently only limit the framerate to super weird targets like 13/17/24/33/66 FPS. It is surely better than nothing but i'd consider it one of the number one things to remove if anything happens. If i saw that correct its simply sleeping the main thread, thus having the same effect as VSync... i wonder if all the people who complain about super slow loading times are limiting their framerate and are experiencing these because of that, tho i've seen pretty fast loading times even with low framerates.

I'd highly recommend not using Debug Settings, Preferences has all settings you will ever need for pictures and has extensive tooltips for all of them, Debug is going to circumvent all of that ultimately making you end up with problems on my doorstep again because you didn't read the big fat warning the Viewer smacks through face when changing certain settings. I'm not sure how sophisticated the search is but you can try searching the debug settings to help finding the settings you want. Tooltips commonly also include the Debug setting being used. The reason not all EEP presets appear in the dropdown is due to permissions, i have not yet implemented a way to protect the horrible decision of making settings an IP, so for now non full perm settings dont show up since you could edit and save them which according to LL is stealing

I'ma stop you right there. I had a good laugh. What you describe sounds like an utopia. You do realize that apps, games specifically to which SL counts very much do not simply "back off" and free up their memory again? especially not to make space in a low memory situation! SL would rather crash than free up memory. SL and many other apps will simply continue allocating more memory until your OS gives in and explodes (or the app crashes, whatever comes first).

I have seen plenty nice pictures of avatars with hair (my own included) but i do not use rigged, alpha blended hair. I'd probably change it to alpha masking to get soft shadows but that is probably out of question for most people considering that a lot of human content is simply no-mod. You also cannot have both and i much prefer much more accurate shadows that do not cut away half my legs at 2m distance from my avatar. I'd go as far as saying that this is a very small portion of content (very specifically rigged, alpha blend meshes) that is not looking good and mostly not for the reason alone that shadows are more accurate, it is a combination of SL's alpha rendering woes and the accuracy of shadows, one reveals the issue the other makes it magnitudes worse. With the shadow offsets currently being completely broken and having returned to how LL does them this should (at least for now) not much of a problem anymore. When i bring back the offsets i might look into finding a better solution that minimizes this issue while allowing to fall back to something similar to LL style precision in case my attempt isn't enough.

Shadows on hair get nasty due to the vastly improved shadow precision and resolution in BD which will have you see shadows on smaller (and closer) objects that other Viewers normally would not include in their shadow rendering. The way Viewers render shadows essentially creates a "depth" map for shadows, essentially a 3D map for where shadows should be, this is then tested against in shaders to apply shadows to the world according to your view. The problem is that applying shadows as-is would overlap them with the underlying image or world/surfaces the depth map is based on (sometimes more or less due to precision), this causes shadows to "flicker" and Z-fight (just like alphas or objects that are overlapping each other perfectly) which is an undesired effect, to combat this the Viewer has a small "offset" that shadows or their checks are pushed back, essentially ignoring the first tiny little bit of a surface and starting the shadows right behind them. This offset is quite big and imprecise in other Viewers, its a very generous set offset which works everywhere without ever causing flicker issues but it also means it generously cuts away shadows, most noticeably a lot of objects close to another surface, such as a necklace on your neck (ever noticed if they are too close they don't cast shadows at all?), depending on your camera distance and shadow resolution and the set offset this can become so apparent that the entirety of your hair stops casting a shadow on your face when it should. A downside of the vastly improved shadow precision in BD is that it is... "too accurate" for things like multiple strains of hair that are alpha (thus allowing you to look through or behind them, revealing the shadows they cast onto the rest of the hair beneath), this creates the ugly "self-shadowing" that you see on a lot of hair. On top of that most hair uses the Alpha Blending mode for soft transparency which sadly doesn't allow for softened shadows due to the way shadows and alpha work independently from each other, unsoftened shadows appear pixelated amplifying the ugly self-shadowing effect (whereas softened shadows would still look somewhat ok). Other than lowering shadow resolution or the "offset" options and thus destroying shadow precision to the point that you will most likely see your entire hair shadow vanish (and other things, like tight clothing pieces, necklaces etc) there is sadly nothing you can do. You can either have generalized allrounder shadows that miss a lot of detail or precise shadows that are too accurate for some of the ways content is made in SL.

How does that matter? All you need to know from the OS (or your GPU) is your total VRAM and scale the maximum amount of texture memory being usable according to that, set it to 90% (to give 10% spare to anything else) by default and give the user a very simple direct (unlike the current one) non-convoluted option that gives you absolute and precise control over how much VRAM you want to allow SL to use and you're set. Don't see why its complicated really. I've been smashing my head against a wall forever, ever since i added automatic memory usage and allowed all memory to be used i was worried about AMD (and their nonexistent VRAM reporting) to screw it over and cause issues, its not. Most issues still come from users who don't understand a simple "Max Texture Memory" option and for some reason turn it down to unusable small numbers (like 512MB) and then act surprised when they see texture thrashing happening... or alternatively those who turned the automatic memory management off and didn't touch the setting at all (leaving it at low values), despite the clear warnings of the Viewer that turning it off is bad. The Intel users i had didn't have any issues with memory either, just with Deferred not working (because some unknown shader is unsupported on almost all Intel GPUs). https://git.alchemyviewer.org/NiranV.Dean/blackdragon/-/blob/master/indra/newview/llviewertexturelist.cpp#L1474 Here's the very simple function to do that. I hooked it up here: https://git.alchemyviewer.org/NiranV.Dean/blackdragon/-/blob/master/indra/newview/llviewertexture.cpp#L584 And modified the rest a bit to give the Viewer a small grace timer so it doesn't immediately go into texture thrashing mode the split second memory usage goes higher than the automatically calculated max, this was done because the calculation update doesn't happen with upmost priority and only after textures are already allocated, so texture memory usage rises and THEN a new max is calculated. It's very simple and has been doing the very job LL has failed to do so for a long time now and i'm sure it could be dumbed down a lot and simplified to the point it literally just takes whatever it can take minus a small margin. This is including an option to set a max manually currently.

I was gonna say. That's total BS. Every goddamn game manages to do this, you can't tell me we can't. Also why would "other" systems stop LL from implementing a solution that works for one system, its better to have a system that works for some rather than something that doesn't work at all. Also reading the total VRAM isn't exactly hard nor a secret unless you are using an AMD GPU, on windows at least, been doing this for years now and it has been a really good solution.

I think what you are referring to is something usually described as "turn off" the opposite of something that turns you on, but yes, it will do that too.

This is going to absolutely destroy your performance and introduce major artifacting in textures. I'd highly recommend not to.