Black Dragon viewer serious performance issues

[Jackson Redstar]

FS and BD side by side  be like them running a marathon - only BD is the one that smokes 3 packs a day! Seriously though, I am wondering if there is an issue with BD or something maybe in Win 11 chocking the life out of it, I am in a sim about 50 people, of first of all have to set the avatar render options in BD to unlimited or nearly everyone is a grey blob, but besides that, with the other settings roughly equal, FS loads the scene running a good 25-28fps in under a minute, BD, 10 minutes later is still huffing along at 3-10fps and even 20 minutes later some things (objects and avatars) as still not out of their grey state. I notice this even in empty sims but complex - lots of objects, transperencies in trees and bushes etc.... so I am wondering, is it just me or have other BD users noticed this as well? wouldn't surpise me at all if something in Win 11 is playing choke the chicken. My system is core i7, Nvidia 3070, 32 gig RAM, drives all SSD. BTW I use the studio driver on the 3070 - my video editor seems to like that better. Win is 11 pro, version 22H2, build 22621.1992

[Chic Aeon]

Best to post screenshots of your settings for both viewers so the folks that would know can answer.  I have had a fair amount of issues with Win11 on my new laptop but running a utilities program has fixed most. But some programs don't work well in Win11.   It simply COULD be a difference in some setting but it will be difficult to say if folks don't know what yours are :D.

 

Good luck.  

[belindacarson]

@NiranV Dean

[NiranV Dean]

Oof. It's this topic again.

You won't like my answer but: No one knows.

Debugging what exactly is happening here and why the Viewer is choking for one person and not another is... impossible. You can't even establish a reliable baseline when you take into account that both SL and the Viewer may or may not refuse to work properly at any given point in time for seemingly no reason.

It could be a setting, it could be the server, it could be your connection, it could be your OS, some software or the Viewer. It could be a random bug that leads down a rabbit hole and causes a chain reaction to go off, locking the Viewer perpetually in a loading state because a single texture is iffy. This type of report comes up frequently, frequently enough to be annoying and a serious issue but not frequent enough to say that it is an issue with the Viewer itself since a lot of people have a completely different experience, myself included. And all of these reports so far have only ever ended in no fix or in the very very rare occasion that it was fixed it was never found out what fixed it, it just suddenly stopped.

All i can say is that 10 minute loading time is certainly not normal. A full scene with 50 people should be loaded in 2-3 minutes (depending on the scene, the avatars, their textures and meshes and how many of them you have visible). Increasing the amount of avatars being fully rendered will increase time it takes to load by a good chunk... but i've also seen the opposite where keeping them jellydolled keeps them perpetually in a half-loaded state and thus the Viewer in loading for much longer. Generally speaking i'd highly recommend using "Max Avatars" over "Max Complexity" anyway, jellydolls are incredibly slow, tax your framerate a lot and cause stuttering, they also look ugly af. Max Avatars is much more consistent and causes a lot less frametime spent on them (sadly). It's also normal that you have to turn up Max Complexity first, the Viewer is set to allow a reasonable amount of complexity by default and since practically next to no one has a reasonable complexity, they all get immediately jellydolled a sight that should come to no surprise to you knowing that SL is user-created and virtually nothing here is optimized.

[JeromFranzic]

I don't think it's BD that has issues with rendering. I've seen it with all viewers regardless of OS used... for me, it's more of an issue with the LL viewer as that one clamps its texture memory to 512 MB. Some areas are slower than others to fully rez, but I've noticed that as an issue with connection quality.

Sometimes BD does have issues rendering, but the easiest fix for that is to TP away from a chosen location, wait a few seconds, then TP back to it. If needed, I'll clear cache, log out and then log back in.

[Jaylinbridges]

19 hours ago, JeromFranzic said:

Sometimes BD does have issues rendering, but the easiest fix for that is to TP away from a chosen location, wait a few seconds, then TP back to it. If needed, I'll clear cache, log out and then log back in.

The new improved SL...  The CDR rezzing algorithm and cache management has never been worse.  I must zoom out to infinity and back to close up to cause my own low lag sky platform objects to rez multiple times/day.  Same anywhere residents have had the nerve to actually place objects on their land.  The lighting contrast problem and color over saturation with PBR is just another stake in the zombie.  SL coders need to observe the real world, where colors are not artificially boosted to cartoon levels, and white objects during daylight are not like staring at a noon day sun.

 

Edited July 27, 2023 by Jaylinbridges

[NiranV Dean]

14 hours ago, Jaylinbridges said:

The new improved SL...  The CDR rezzing algorithm and cache management has never been worse.  I must zoom out to infinity and back to close up to cause my own low lag sky platform objects to rez multiple times/day.  Same anywhere residents have had the nerve to actually place objects on their land.  The lighting contrast problem and color over saturation with PBR is just another stake in the zombie.  SL coders need to observe the real world, where colors are not artificially boosted to cartoon levels, and white objects during daylight are not like staring at a noon day sun.

 

Welcome to why i hate most Linear and Linear-like tone mapping styles, they take the artificial colors and boost them, i hate it, real life isn't colorful, its desaturated, thats why i prefer Rheinhard or similar styles.

[Henri Beauchamp]

8 hours ago, NiranV Dean said:

real life isn't colorful, its desaturated

You are totally right.

However, we must do with what monitors can display, and unless you are rich enough to pay for a high DPI monitor (with the graphics card to match the resolution at high enough FPS rates) and a full HDR color space and super-high contrast dynamic (i.e. with a QLED or OLED screen) , you do need some kind of dynamic range compression, or you will have to push the luminosity to levels that will make black spots look grey (and make your eyes bleed), so to see all the color details.

This is why, with my monitor (which is an excellent one, but definitely not an HDR one) I prefer (and pretty much need) linear color space...

In fact, on non-HDR monitors, an HDR rendered scene will look way more artificial and even ”toonish”, with way too saturated dark colors.

[Jackson Redstar]

1 hour ago, Henri Beauchamp said:

You are totally right.

However, we must do with what monitors can display, and unless you are rich enough to pay for a high DPI monitor (with the graphics card to match the resolution at high enough FPS rates) and a full HDR color space and super-high contrast dynamic (i.e. with a QLED or OLED screen) , you do need some kind of dynamic range compression, or you will have to push the luminosity to levels that will make black spots look grey (and make your eyes bleed), so to see all the color details.

This is why, with my monitor (which is an excellent one, but definitely not an HDR one) I prefer (and pretty much need) linear color space...

In fact, on non-HDR monitors, an HDR rendered scene will look way more artificial and even ”toonish”, with way too saturated dark colors.

When i do video of sl, i am constantly trying in post  color grade to make it look a little more like rl film, and try to control the saturation and contrast. I recently bought a BenQ monitor, 10 bit, but of course 10 bit would never be used for SL, but it does produce 100% srgb coverage. not sure what this all has to do with the thread, but trying to reproduce a film look from a SL screen recording has been an obsession of mine for a while LOL

[NiranV Dean]

3 hours ago, Henri Beauchamp said:

You are totally right.

However, we must do with what monitors can display, and unless you are rich enough to pay for a high DPI monitor (with the graphics card to match the resolution at high enough FPS rates) and a full HDR color space and super-high contrast dynamic (i.e. with a QLED or OLED screen) , you do need some kind of dynamic range compression, or you will have to push the luminosity to levels that will make black spots look grey (and make your eyes bleed), so to see all the color details.

This is why, with my monitor (which is an excellent one, but definitely not an HDR one) I prefer (and pretty much need) linear color space...

In fact, on non-HDR monitors, an HDR rendered scene will look way more artificial and even ”toonish”, with way too saturated dark colors.

Yea linear color space is fine but what i mean is using linear Tone Mapping post process to artificially "boost" the colors even more to make them "pop". Tone Mapping is originally supposed to be used for HDR to compress the color range back into something non HDR monitors can display properly, something like Rheinhard Tone Mapping does this, it also naturally desaturates colors a bit (turning white a little less blinding and pitch black brighter, tho these two can be fixed or worked around with, at least pitch black can be kept, pure white isn't as important as rarely anything in real life is truely blinding white). I don't understand why they haven't given us options, now that they made Tone Mapping an official thing, they could have given us a bunch of Tone Mappers to choose from (certainly something i'll try to implement). Pretty much every game i've ever played that has the option to enable Tone Mapping also comes with an option to switch Tone Mapping styles. Warthunder and Escape from Tarkov are two examples of such games.

[Henri Beauchamp]

4 hours ago, NiranV Dean said:

I don't understand why they haven't given us options, now that they made Tone Mapping an official thing, they could have given us a bunch of Tone Mappers to choose from (certainly something i'll try to implement).

I totally agree. It is important that the user can get SL to display beautifully on their monitor and following their tastes.

I personally do not care the least how things are supposed to look (they will never look as they are supposed to anyway, because monitors are imperfect, even HDR ones, and their adjustments by the final user is even ”more imperfect”). I just want SL to look good for me, on my monitor. The rest is pedantic purism.

Beside, SL is not RL. I do not need (and even less want) SL to look exactly like RL !... I personally use SL to roleplay, and enjoy having a virtual world that is not like RL, in which I can live and share my fantasies, while having things left to my imagination.

[Beq Janus]

@Jackson Redstar, back on the original subject a little. I'm sure that you'll have probably looked at this already but do double-check that you have all the correct AV whitelisting in place for BD as well as FS. Assuming that BD is using a separate cache, that would be a good reason why sucking down a scene might take a lot longer. Temporarily disabling any AV might be a quick way to test that theory.

Also, keep in mind that if you are running "side-by-side" comparisons, viewers will (by default) back off and go into low-usage background mode when not the active window. For many viewers (Cool VL Viewer is the exception here, I think - because I haven't yet borrowed Henri's idle/background code, and BD may be the same), the rendering frame rate and the rate at which background stuff is serviced are somewhat correlated. If your viewer is inactive (i.e., you are tabbed out), some aspects of the background workload will run at a lower framerate. Many more things run in separate threads these days than they did in the past, but several aspects of viewer operation are still coordinated from the main thread; when you tab out, and the viewer yields the CPU for other processes, this coordination happens less often, and if you are tabbing out of one viewer and into another then the active viewer will naturally appear to be a lot more snappy and faster. 

Edited July 30, 2023 by Beq Janus
clean up punctuation and grammar a bit

[Henri Beauchamp]

3 hours ago, Beq Janus said:

Also, keep in mind that if you are running ”side-by-side” comparisons, viewers will (by default) back off and go into low-usage background mode when not the active window.

+1

Not to mention viewers are configured differently, e.g. on the number of threads they use. And with modern CPUs such as Intel's with their ”performance” and ”economy” cores, you cannot really control which are the cores affected to two simultaneously running viewers. They will also fight for VRAM and GPU resources, meaning you can draw strictly no conclusion on which one of the two running viewers is getting the most resources from your computer hardware (but it will never be a 50/50 split, you can bet on it).

To compare viewers speed, you must run them one after the other, have them render the exact same scene (*), with the exact same FOV, and with the exact same settings (this might be a challenge, since each TPV got its own peculiarities, with its own ”boosting” features, own sliders scale (e.g. for the LOD factors in graphics settings), etc).

Benchmarking properly requires a very strict protocol...

---------

(*) This sadly means it is close to impossible to compare them in a scene with non-bot avatars around, since avatars come and go, with vastly different render cost. I wish LL would provide a testing ground sim on Aditi, with a rich (heavy), varied environment for objects, and a dozen bot avatars (with equally varied and render-heavy outfits).

Edited July 30, 2023 by Henri Beauchamp

[NiranV Dean]

Well i can see that BD is objectively slower than say the Official Viewer or FS, that shouldn't come as a surprise considering that BD has 0 optimization in regards to loading/caching/decoding and neither does BD have KDU, OpenJpeg (1.5 which i'm currently using) is a good bit slower and probably always will. So in bare theory you should never ever see BD outperform any other Viewer unless they are having a bad day for some reason. But from my experience the past 10 years using my Viewer the difference between Official and BD have been barely noticeable at best, i don't sit there and time loading times exactly but i've never found them to take too long, a minute at most. Unless i do some whacky shenanigans like rapid-fire relogs (which will break your outfit, get you stuck, make you unable to move, stops stuff from loading all the way up to breaking the entire Viewer to the point you can only relog) which as far as i can tell is due to the shutdown and start routine being so insanely fast that the cache isn't properly "done" writing causing you to potentially corrupt it with a too fast restart. It might also be server related, generally speaking even with slower relog if i relog before the server has actually disconnected me properly (you are still online and will now be disconnected error) it will break a lot of things.

[Henri Beauchamp]

1 hour ago, NiranV Dean said:

OpenJpeg (1.5 which i'm currently using) is a good bit slower and probably always will

Try and borrow the Cool VL Viewer's v1.4.0.635f version (”f” is representative of how many modifications sessions I performed over the original 1.4.0.635 code, with all known security holes fixed, personal optimizations added, v2 optimizations backported, Kathrine Jansma's AVX2 optimizations added, ARM 64 bits support added), which is part of the viewer source tree (linden/indra/libopenjpeg/ subdirectory).: it decodes just as fast as OpenJPEG v2 (and, should you implement GL textures decode multi-threading in BD, like I did for my viewer, just as fast as KDU on modern CPUs), and does not have the bugs that plague the latter in SL with partial decodes (lower texture LoDs), or the silly way  even the ”fixed” v2 decodes textures (making them appear as quite ugly while rezzing).

[Jackson Redstar]

10 hours ago, Beq Janus said:

@Jackson Redstar, back on the original subject a little. I'm sure that you'll have probably looked at this already but do double-check that you have all the correct AV whitelisting in place for BD as well as FS.

In a nutshell, why getting new users to stay is so hard...unless one has a PhD in Technology.. yeah yeah I know it's a "game" and gamers know all this stuff already - but my guess would be that 10% of the user base is a "gamer" with an in depth knowledge of all the inner working of their OS. 

But thank you - I'll recheck everything is white listed and as a side note I always set the background idle to 0 in debug settings so it never "sleeps"

UPDATE -  i USED to always have everything white listed. I forgot Win 11 got rid of Defender and there is no longer any options to allow for exclusions. I dont use any other AV either

Edited July 30, 2023 by Jackson Redstar

[NiranV Dean]

2 hours ago, Henri Beauchamp said:

Try and borrow the Cool VL Viewer's v1.4.0.635f version (”f” is representative of how many modifications sessions I performed over the original 1.4.0.635 code, with all known security holes fixed, personal optimizations added, v2 optimizations backported, Kathrine Jansma's AVX2 optimizations added, ARM 64 bits support added), which is part of the viewer source tree (linden/indra/libopenjpeg/ subdirectory).: it decodes just as fast as OpenJPEG v2 (and, should you implement GL textures decode multi-threading in BD, like I did for my viewer, just as fast as KDU on modern CPUs), and does not have the bugs that plague the latter in SL with partial decodes (lower texture LoDs), or the silly way  even the ”fixed” v2 decodes textures (making them appear as quite ugly while rezzing).

Interesting. C-can i even borrow that? Isn't there like different licensing shenanigans going on? No? Or is openJPEG just using whatever their licensing was and it wasn't changed?

1 hour ago, Jackson Redstar said:

In a nutshell, why getting new users to stay is so hard...unless one has a PhD in Technology.. yeah yeah I know it's a "game" and gamers know all this stuff already - but my guess would be that 10% of the user base is a "gamer" with an in depth knowledge of all the inner working of their OS. 

But thank you - I'll recheck everything is white listed and as a side note I always set the background idle to 0 in debug settings so it never "sleeps"

UPDATE -  i USED to always have everything white listed. I forgot Win 11 got rid of Defender and there is no longer any options to allow for exclusions. I dont use any other AV either

Windows 11 got rid of Defender. That is probably the only good thing so far i've heard about Win11. The others are problems. A lot of problems, similar to yours. A picture slowly starts painting. I'm beginning to feel like the Viewer isn't exactly running well on Win11.

[Ardy Lay]

3 hours ago, NiranV Dean said:

I'm beginning to feel like the Viewer isn't exactly running well on Win11.

Runs fine on my computer with Windows 11.  When I am having issues, I look at the forum and so are other people, so I just chill for a while as the world burns or whatever then try again later.  Now, "runs fine" doesn't mean I am perfectly happy with what I consider "bugs", but, I tend to write bug reports then forget them.

[Ardy Lay]

Hmm, there's Windows Defender Firewall, which is not what was mentioned, and there is Windows Security, which does allow exclusions:

I do not have any exclusions defined and I do not have any of the symptoms people keep saying are caused by not having exclusions defined.  I suspect those symptoms appear if the hardware takes longer to do things than mine does.  By many people's standards, I spend an insane amount of money on hardware.

[Henri Beauchamp]

3 hours ago, NiranV Dean said:

Interesting. C-can i even borrow that? Isn't there like different licensing shenanigans going on? No? Or is openJPEG just using whatever their licensing was and it wasn't changed?

The license is fully respected (see linden/indra/libopenjpeg/readme.txt and linden/doc/licenses-linux.txt).

I see no reason why you won't be able to use it in your viewer (and my own work can be reused under either of GPL or LGPL licenses, at your convenience).

Edited July 30, 2023 by Henri Beauchamp

[NiranV Dean]

On 7/30/2023 at 9:50 PM, Henri Beauchamp said:

The license is fully respected (see linden/indra/libopenjpeg/readme.txt and linden/doc/licenses-linux.txt).

I see no reason why you won't be able to use it in your viewer (and my own work can be reused under either of GPL or LGPL licenses, at your convenience).

Mh. Interesting. I'll see how it goes, currently in the process of getting a usable GLTF Release done, it looks like this will need some major refactoring all over the place. OpenJpeg2.5 seems to work fine tho, if i'm all done with this i might take a look into your openjpeg.

[Henri Beauchamp]

14 hours ago, NiranV Dean said:

OpenJpeg2.5 seems to work fine tho

I don't like the way it rezzes textures with transparency: they look ugly while half-decoded. This is especially obvious on trees foliage.

It also sometimes fails to decode textures that OpenJPEG v1.4 deals with without trouble.

Edited August 2, 2023 by Henri Beauchamp

[NiranV Dean]

6 hours ago, Henri Beauchamp said:

I don't like the way it rezzes textures with transparency: they look ugly while half-decoded. This is especially obvious on trees foliage.

It also sometimes fails to decode textures that OpenJPEG v1.4 deals with without trouble.

Haven't yet looked at the rezzing specifically, especially not transparent, they didn't seem noticably different? But then again i'm currently much more focused on getting the Viewer back in working shape, as of right now everything is broken.

[AmeliaJ08]

On 7/27/2023 at 10:02 AM, Jaylinbridges said:

The new improved SL...  The CDR rezzing algorithm and cache management has never been worse.  I must zoom out to infinity and back to close up to cause my own low lag sky platform objects to rez multiple times/day.  Same anywhere residents have had the nerve to actually place objects on their land.  The lighting contrast problem and color over saturation with PBR is just another stake in the zombie.  SL coders need to observe the real world, where colors are not artificially boosted to cartoon levels, and white objects during daylight are not like staring at a noon day sun.

 

Is this maybe some sort of bug that has been introduced to the current rendering code a lot of viewers are using?

I've noticed this in Firestorm 6.6.8.68380 occasionally as well, I seem to remember people discussing it when this version launched too but can't find anything about that now... random mesh objects just not appearing or glitching in and out of visiblity. I find 6.6.3.67470 does not do it.