NiranV Dean

Can't really? Your GPU is only important for the basic rendering and shader effects as well as keeping textures loaded, pretty much anything else solely depends on your CPU and if your CPU can't handle BD then it can't handle any other Viewer either. If your GPU can handle any other Viewer it will handle BD just fine.

Black Dragon is BOM (has been since the release week)

Necro and thats not a fix, this tiling issue should be fixed soon, its an issue that came with LL's changes of a few months ago, i've submitted a fix for it and its going to be in future updates.

The upper limit of the view distance slider changes depending on your window aspect ratio, different aspect ratios can only handle certain amounts of field of view before they break completely, the viewer automatically limits the slider to the appropiate maximum.

But Facebook is no toy... its cancer, don't let your kids play with it

Why would there be any crying, Facebook's time is over, even my mom doesn't use it anymore... was about time.

That really isn't a solution and neither the answer he was looking for.

I doubt it. Facebook, Twitter and Flickr are being removed because LL can't keep up with the constant API changes they are doing for a feature that is probably rarely used and was kinda unnecessary to begin with (you should be uploading them manually anyway). Postcards don't rely on API changes and they are generally just glorified mails.

I've had this too. I was in the middle of investigating what's the cause for this, apparently it seems to be something related to the CoF (outfit/appearance folder fetching). I was not able to fix it as this is an integral part of the Viewer login and works the same in BD as in any other Viewer, there was nothing i could do about it so my only guess is that it is something else doing this, possibly a setting i borked. Maybe something in my cache, maybe one of my misc-settings or generally something that can be found in the Roaming folder (where your settings, poses, presets and so on reside). Before i could test this and confirm whether doing anything there fixed this i was forced to reinstall to Windows 10 (for my Ryzen upgrade) and now this issue has never happened again, but i have to say that my cache (even if started from the old HDD) is located on my SSD, which might help with that (if it was the cache), my settings are completely gone too (since this is a whole new windows), i only copied over the logs and windlight presets. I can only recommend you trying something i was going to do but didn't get to do in time: Go into your AppData\Roaming\Black Dragon folder and delete it completely (make a copy of it to save your settings, logs, presets and so on before you do). See if something in there is causing this behavior. If nothing helps all i can tell you that staying patient will help you, the issue usually only happens on the very first login, attempting a log in in right after the first failure results in a normal login (for whatever reason). If you do find a solution to this issue or if the above mentioned solution works it would be great to tell me so i can keep this in mind in case anyone else has this in the future (so far it has only been me, with you being the first person to report it to me, which leads me to believe that it is user-error, hopefully). Note that the Viewer might freeze but do NOT close it, simply wait, this CoF fetching just takes super long for unknown reasons, wait it out, the Viewer is not completely frozen as you might think, its actually working hard and will bail out into the login screen when it stays there too long.

Because the Viewer is downloading gigabytes worth of textures and data with people coming and going, idling at a place and not doing much besides talking with the same people around will basically cost you next to nothing. These extras are not necessary for SL to function though, SL prioritises the bandwidth it needs to stay alive over additional things like downloading stuff. So the moment you have logged in successfully you're safe unless you lose connection for ~30-60 seconds in a short timeframe.

1. Black Dragon can use up to 8GB VRAM. It's fairly normal to see uses of 1-2GB, unless you are on empty places but your TPV parcel alone eats like 500-700MB easily. Add a bunch of 100MB avatars and a bit more than just 1 small parcel and you'll quickly get your 2GB full and this isn't even counting the fact that there are two memory pools, one for semi-permanent memory (UI textures and region stuff) and the scene memory pool (used for what is actually on screen at this very moment), the scene memory textures are in the system memory too, they are being mirrored so you're using twice as much memory for no reason.

No. The moment your internet connection would result in not being able to connect with multiple sessions at the same time is the moment you'll not be able to stay online in a single session. SL uses incredibly little, next to nothing when not currently downloading stuff. Really the only limit in almost all configurations will always be your RAM, no more RAM no more Viewers.

I'm no expert, just someone who's very interested in and around SL, specifically pushing it as of lately. There are quite a few things i don't know, starting with precise instructions on how to optimize content like mesh. I can only give you the general idea and tell you what it has to be in the end and possibly some hints how to get there, how to do it in the actual program is beyond me, that is something i assume people who can mesh know much better than i do and i'd also assume telling them what the end result needs to be considered optimized is enough for them to work it out. You usually only see me appear when mentioned nonsense appears and if i know something about it i'll usually chime in. This sadly is such nonsense and the reason i'm posting here. Black Dragon is hardly more intensive than the LL Viewer is (in fact some parts need even less considering that i improved and optimized a few things here and there over LL's Viewer), that is unless you pull the settings up beyond what is labeled as "Ultra" or activate the additional graphical features BD offers, even those are considerably low cost even for a low-end card. I have developed Black Dragon for 7 years soon and i've spend almost all of that time with an AMD FX 6200 and a GTX 670, neither of which were high end or even good and i was maintaining a good framerate all around and i've never resorted to disabling Deferred Rendering or toggling off shadows like so many people do to squeeze some fps out. Even a 10 year old Intel in a laptop could beat my FX in raw power in SL (due to SL only using most the first two cores) and the only thing the GTX 670 was lacking was simply more memory because everything SL nowadays eats multi-GB texture memory for no reason. If i was let loose at the controls of SL you'd see a lot of big changes (as much as a team could probably get around to doing in such short timeframe), one more controversal than the last. I wouldn't be so lenient with backwards compatibility (graphical objects from 10 years ago would now either look semi broken or wouldn't work anymore) and i would be high busy setting up guides, documentations and some actual guidelines + limitations on things like the mesh uploader, 2 million triangle avatars wouldn't even exist if i was in control, infact if someone managed to seriously get a 2 million triangle avatar running he'd get a single warning before i'd pull the banhammer. Almost-zero-tolerance-policy. But yes i'd surely start fixing as many old things as possible, while working on expanding on things that i deem overdue that have been an industry standard... namely rebindable controls would be a start, many of my tweaks would also immediately go into the Viewer (such as the real-camera based Depth of Field defaults so people don't get their entire screen completely blurred the moment they enable Depth of Field just to turn it off immediately in disgust, which is a tad shame really) I don't know what i'm doing. I just do it. As third party Viewer (and fairly small on top of that) i'm quite free in regards to what i'm allowed to do and what i can get through with. I'd be stupid if i didn't use this to try new things. Sometimes people like them, sometimes they don't but unlike Linden Labs i don't leave something as is for many years unless i either can't fix it, have much more important things to do or am convinced that this is the way it should be. So when people don't like something i either improve based on feedback (if there is any) or continue experimenting (if there isn't) until i find something that works and aligns with my envisioned goal. Sometimes its easy, sometimes it takes months, years even. Niran's Viewer was my first actual dive into programming and it was a very helpful learning experience which i used to start from scratch with a much better foundation in Black Dragon, which still is a huge learning project. You can't win without trying and most don't even dare, so they already lost before they even began, at least i can say that i died trying. People's experience with me vary wildly but could be simplified and grouped into two sets of people: Those who met me anywhere not a forum or blog, like inworld, discord or in games... and those who met me in forums, blogs and other social media. Those who meet me outside of social media generally have a very nice and helpful experience with me as i take the time to adress each and every individual case and help people wherever and whenever i can, if you met me there you will generally see me as a nice and helpful person. Those who meet me on social media platforms will generally hate my guts because i am direct, unrelenting and generally don't mince matters, i will tell you my open opinion without regards to your feelings, most people can't stand this and i can relate, if you met me here you will most likely either have a neutral opinion or more likely a very bad opinion about me because i come off as complete ***** for no apparent reason. A few things: As far as i remember the lindens designed the old ARC to include as much different hardware as possible, ranging from old to new, this is, what i think was their biggest mistake and made ARC ultimately useless. Second: Their revision of ARC is just as useless as it is right now, i'd highly recommend not holding out for it or having any hopes, Oz has already confirmed that they are not intending to punish or "shame" bad content in any way, this would imply that most if not all current biggest offenders of broken ARC values are still going to be broken with the new ARC values which ultimately makes them useless, no matter if they are simply higher, the very fact that they "look to remedy the issue of possibly higher values" should worry you. They are not looking to offer you realistic or informative values. To put this into perspective, the reason i even started disregarding the warnings of Oz in the code and started modifying the ARC calculation is because if a 2+ million triangle rigged mesh monster with more than twice the memory usage than my own (i think 150k polys, most of it simple flexi prim hair and a bunch of sculpts which are locked to 64x64 points) can have half my ARC, something is super off and no one can tell me that this is in any way realistic or even remotely accurate. When i spend my entire evening optimizing my avatar i can guarantee you that you can easily put my avatar a few times into the same place one of these multi-million monsters are and still using less resources. Remember that the very reason ArcTan has even been a thing (as far as i can tell) is because i relentlessly bashed ARC and made the entire meeting talk about how ***** the current ARC is before Oz's arrival on an open source meeting which made him finally listen. Seeing that ArcTan is going to be wasted and biased again towards "a wide range" of hardware is a personal disappointment. I feel like going all these lengths and having to deal with pissing people off with my complains about everything being broken is wasted here, i don't do this for fun. I know i complain about everything but i have legitimate concerns and i'm not taking all this flak so LL just tosses it into the fire for the sake of "not shaming bad content". Which brings me to three: I don't "think" its more realistic, i'm extremely convinced that it is more accurate (although the numbers are quite high but for simplicity and transparency remained like this for so long) than anything that will possibly ever come out of whatever LL is cooking up if they don't drop their "protect-all-content" mentality. Bad content needs shaming, bad content needs punishment, nothing is going to change if we ignore it and continue looking through pink glasses. LL NEEDS to intervene there, they absolutely MUST put limitations on this otherwise they are just going on a wild goose chase forever. I can tell you i will continue cracking skulls when ArcTan arrives until they give up and actually do something useful about it. Four: How much of an impact polygons are obviously depends on the hardware, some hardware does certain things faster than others, ultimately we can agree that polygons aren't the sole cause for all our performance problems but they CERTAINLY are a big part of it as a lot of graphical rendering hinges on it. Polygon complexity carries its impact upwards and gets worse. While a million polygons might not directly kill your framerate (because our hardware are monster calculators and can deal will billions of these) it doesn't mean that they won't create a bottleneck somewhere. Shadows for instance, most people recommend disabling them, you know why? Polygons. Your million polygons don't impact someone without shadows as much as they do to someone with it enabled because that person basically has to render them twice (if not more). When rendering a particular item multiple times, impacts quickly multiply and get out of hand. Textures on the other hand, i'm not a graphics expert, i can only tell you from what i've seen with my own eyes but i'm pretty convinced that textures themselves have little to no impact on your framerate itself, allocating, decoding and loading them is what makes the big hit in performance, this hit however is temporary. When everything is fully loaded your framerate will stabilize because textures have been loaded into memory and just need to be rendered and possibly transformed on screen most of which should be the GPU's work anyway. Unlike the CPU the GPU is much better utilized in SL and more raw power on a GPU can be used although mostly just as "buffer" for when you turn up GPU related rendering features (depth of field for instance), which is why i say a GTX 670 was far more than enough (when it died i even used my old GTX 460 for a few days and... you'll laugh but even the 460 produced the same framerates, GPU requirements are reeeeally low in SL). BUT. Textures cause a different problem. Texture trashing, when the alloted memory for SL is full, the Viewer will attempt to clear out textures in an attempt to make space for "more important" textures, if there are none it will result in what is commonly called "Texture Trashing", e.g your textures will repeatedly go blurry and clear. One solution is obvious: toss more memory at it. Another... and the real solution is optimizing textures. Reduce texture sizes to a minimum, a necklace doesn't need 128 1024x1024 textures for every chain a different version of the same texture. A single 64x64 or 128x128 texture is way more than enough if you reuse it for all chain parts and it looks the same but in the extreme and unlikely case of 128 1024x1024 textures would save you 512mb of texture memory minimum, taking into account that each texture is 4MB (5MB with alpha if you believe the texture console to be correct). This texture trashing is also useful for another thing other than making space for newer textures, it prevents what games often don't do, overloading your texture memory. Should this ever happen (and you can test this by enabling fullrestextures) you will see your framerate drop into completely unusable rates because (as mentioned before) the GPU starts doing whats possibly the worst (and slowest) thing to do, it deallocates textures to make space for other textures, allocating the new ones, repeatedly allocating and deallocating textures will bring any GPU to its knees, no matter which and that's something you want to prevent with all means necessary.

According to her she didn't see the issue in BD which i assume is either due to implementation differences or because the tattoo she might have been wearing (if she did) or whatever texture was still applied might have been a "temp texture" hence why its grey, but then the texture should become grey in Firestorm after relog as well.

So, after some inworld investigation we found out that the issue is (like with all current quickly cobbled together BOM bodies) a tattoo layer. I'm unsure why it is grey, it might be due to it defaulting to a missing texture if you are not wearing a tattoo or no texture is set, it might also be "missing" because the creators used a tattoo that you don't own/wear or it might just be the default behavior i really don't know. The fix however is quite simple, all you have to do is hide the tattoo layer or apply a tattoo, either by wearing a tattoo layer clothing piece (preferably one with an empty 100% alpha texture) or by applying it however it is done, you probably know this better than me as i don't use any human bodies and i don't know their HUDs. I don't know why Firestorm doesn't show it grey by default but i wasn't able to test it with the LL Viewer as it was already fixed when i arrived with the LL Viewer.

Never.

Well first things first, make sure you're on the latest version. Also judging from the picture (its a bit hard to tell) but it seems like you are not using Deferred Rendering, you should enable it if it isn't enabled, BD is known to have rendering issues without Deferred enabled, especially texture problems. When those two are done you might want to make sure you've logged in properly, are in a SIM that is not currently dying and/or on the way to do so, go to an empty place, make sure your notifications are emptied (the green button at the top right) and do a relog, clear your cache if necessary and log in again, when inworld take note whether your inventory loads (kick it by typing something into the filter if necessary) and your friendlist shows up (if everyone shows offline even when you know some are online it might indicate that you didn't login properly and might experience issues like not getting offline IMs, inventory not loading, friendlist not loading, not getting IMs at all, not being able to teleport...all the way up to simply getting a disconnect a few minutes after you connected). You can check whether the Viewer is still loading textures if you open the texture console (CTRL + Shift + 3), you'll see a lot of bars showing the progress of textures being loaded at the bottom, if there are none anymore it's done. If your AV is still not loaded then you might want to get back to me. Also, as @Clover Jinx mentioned i'm always at the top of your friendlist (if you are on BD) in case you need help, there's also the inworld help group (which i don't recommend since it is mostly used by users now that i'm primarily using discord to be able to respond to offline messages aside from offline IMs) and of course the Discord Channel (which is probably the most effective way of getting help), you don't need to have an account to access discord channel and you don't even need to install Discord to use it, it can be used from the website as web app.

Missing clouds happens on two occasions: You are coming from older versions/settings that used differently labeled cloud textures, this might confuse the Viewer as it tries to load the "old" cloud file which does not exist anymore. For some reason the cloud texture is not set or unloaded, this can rarely happen for unknown reasons. I assume however that it is again due to old settings, it's the only time i've actually managed to see this happen. It could however happen if you rename, delete or move viewer files (possibly because you are trying to replace them with others from other Viewers or windlight cloud packs). To fix this you simply open the sky editor and select a cloud noise texture. The Viewer automatically lists all textures found in the folder.

Doesn't matter. The issue happens regardless of your settings post Deferred Rendering. Post Processing effects that are screen dependent like DoF and SSAO just make it more obvious due to the harsher light-tiling. Additional note: The reason you don't see it happen with SSAO is because SSAO in all other-than-Black-Dragon-Viewers is basically non existant and could as well be just off when its clearly enabled.

Goddamn i told you high res snapshots are broken on the meeting! I told you and Linden Labs that higher than screen resolution snapshots got broken with BOM, this was over a month ago. PAH. Goddamn i told you even RIGHT at the beginning, i LITERALLY opened the meeting with it. At that point i had it fixed already even. GRAA.

We all do this at no cost. Check. I do offer live support as well to anyone who simply contacts me, at any time, given i'm online. Otherwise i'll help whenever i'm back online (not SL but in general not afk or asleep). You must ensure nothing unless we're talking about not violating the ToS/TPV rules. You don't owe anyone anything. And you, like anyone else can release an update anytime you want. You (or your users) are pissing their pants over a 100-200mb download they have to do (which with your 3 version system they wouldn't even have to do immediately) occasionally, but no one loses his ***** over the gigabytes of content SL is live-downloading all the time. In todays standards it is totally normal to push updates frequently, infact this is even better than pushing them with big pauses inbetween as it gives you way more interaction with your userbase and valuable feedback and testing than any of your betatesters could ever provide to you in even the lenghiest of QA phases. "Wen we do that, well over 70% of SL users have to update their viewers and THAT is extremely disruptive" ... so what about the rolling restarts constantly? What about the official Viewer which updates every 2 weeks or so? What about the other "30%" of SL that updates frequently. Those aren't disruptive to you but pushing more frequent updates is? Wow. You even have an auto updater and a way to block old versions, people don't have to do much other than clicking a button and wait. Every day Discord has an update, every day i start Steam some game wants to download an update... and don't get me started on Early Access/Alpha/Beta titles who frequently push multi-gigabyte updates, no one cares about that. Don't give me that crap with luxury of snappy releases, of course you do. You just chose not to use it because you fear your users complaining about stuff they shouldn't be complaining about in the first place, maybe you should rethink your strategy, maybe you should give people reasons to update, like telling them that their very issue is fixed in it. I haven't had anyone complain at me yet that they had to update the Viewer when they LITERALLY just updated it, they were happy that whatever problem they just had was fixed in the latest version. People love that, people love when you show them that you care about their problems, when you fix them or at least show them that you are working on it. Your burden is your own inability to work with your users to find a good solution that doesn't compromise everyone else. But hey, what do i know, i'm just a small viewer developer, i can do whatever the heck i want and no one will bat an eye because as you kinda implied certain rules seemingly don't apply to me. I'm not obsessed with Firestorm. I just love Ansa. Jessica is just trying to take my Ansa away.

HA. HA. Certainly you otherwise you wouldn't be delaying the entire development cycle of SL because of your release plans that never pan out as planned as we've seen countless times. You wouldn't even set up these stupid plans and back them up with cheap excuses like "our users don't like updating". I've seen smaller groups of people push less broken stuff in smaller timeframes and with less testing than your releases. You clearly don't know the most important thing about development, which i already stated above. No matter your testing, users will always be users, they WILL break it and you can't do anything about it. Your rigerous testing is a rigerous waste of time that could be substituted with each developer testing their own feature as much as necessary and having a release when everything appears fine. Users will break it for you and find bugs you would have never though are possible, then you can actually start fixing your ***** and push fixes. Your long release cycles push you into this "we need to test this stuff as much as possible" mentality because you've set yourself these pointless "an release only every X months" limitations that force you to do it "right" the first time which is impossible with software as complex as this. Worst case you end up pushing the release further and further because it needs constantly more testing which at the end won't help because the moment users get it into their hands, it will break apart in spectacular ways. But what do i espect from a team that can't even teach its own users proper movement and camera controls even though they have a huge dedicated newbie gateway thing and dedicated helpers for that. Let alone basic inworld content manipulation that isn't a "click this button and everything happens automatically" feature. Everyone needs to find their own way of working with SL development but you have by far found the worst. Just look at Cool VL Viewer, on point regular updates with fixes and new features and no one complains there because it actually *****ing works and it doesn't halt SL as a whole. You'd do yourself a big favor by shrinking your updates this reduces the amount of time you need to test stuff and would allow your "betatesters" to focus their testing more and you would stop the rest of SL from waiting on you for so long every goddang time.

At least i'm not telling myself that dedicated beta testing is in any way replaceable with "live" releases to the masses - unlike a certain other viewer that constantly releases broken stuff that's supposedly tested. And round two: At least i accepted the fact that users will always break your stuff shortly after release no matter how much care you put into it - unlike a certain other viewer, i can push a fix for it shortly after. The "need" for betatesters, the constant nagging of your users, the long release cycles. All problems of your own making. Just saying.

Poor beta testers... have to test untested stuff. Why the hell do you let beta testers test untested stuff that's what early access is for... and then there's also alphas, where are those alpha testers?

Since the switch to HTTP there is no more direct way to control the bandwidth usage. The old bandwidth setting does nothing now and the only way i could think of "limiting" the bandwidth would be playing with fetching options and lowering concurrent fetches (for meshes, not sure if there are settings for other things)... that is if that setting even works.