Disclaimer

Black Dragon is MY Viewer, i decide which feature i want to add and which to remove, i share this Viewer to show the world that user base size is not important, i do rate quality by effort, thought and love put into the project, not some rough estimated numbers. I consider feature requests only if i you can name proper valid reasons i can agree on. It is my (unpaid) time i'm putting into this project, i'm not here to cater to every Joe's desires.

Wednesday, July 17, 2019

Black Dragon 64x - Update 3.5.2 "Searching Dragon"

A relatively small but action packed update awaits!



I got: fixes, fixes, fixes and MORE FIXES.


First the boring stuff: the Poser has gotten some under the hood changes none of them active at the moment but i'll build upon them in the future, i got some plans to extend the Poser with more fancy stuff.

Flycam has seen a slight change in how the flycam smoothing works and all controls needed some... tweaking to accomodate for that, these tweaks have now been made, the new Xbox360 controller defaults should once again feel decently enough as starting point to be used if you don't feel like sitting there and tweaking them for hours, also the max smoothing value for avatar smoothing has been increased to allow making the avatar rotation sharper and more responsive, zoom and roll should hopefully work properly again.

Now to the more interesting stuff: I experimented a bit with multithreading, multithreading is a big thing, everyone keeps saying "just multithread that shit and it will improve performance". Well yes... and no. Spawning extra threads has a huge impact, spawning an extra thread has to outweight the impact you improve, if you incurr more impact with spawning threads than you are solving you're essentially just slowing down stuff and making it crazily unstable too. How unstable... i got to see live in action and it was a crashfest and all i did was just a simple list fill, it was crashing left and right, at random, seemingly for no reason, all over the place. Multithreading requires careful managment of resources, you cannot read and write onto the same thing at the same time, infact you shouldn't probably be writing to something being read somewhere anyway, best case you should be writing to something entirely different and thats where the problems start. While SL is technically very modular and theoretically it should be easily splittable into parts that run simultaneously, having to make sure that the other threads are not writing into the same memory at the same time its being read or written into somewhere else or making it write into a new thing and merging those later is a huge undertaking, it requires writing lots of extra stuff and rewriting some parts completely to make sure they can work while the other thread is doing its job, rendering especially is very... fragile there. I think the image decoding is probably one of the biggest performance impacts all around and probably the easiest and safest to multithread since the Viewer can already work with all states of a texture, whether it is loaded, still loading, still decoding or missing, it will just require lots of careful shoving textures around, this could drastically improve performance while textures are being worked on and they are worked on most of the time. Back to what i did with multithreading, i multithreaded the Avatar Render Settings, the list will now be collected and created in a seperate thread and then written into the actual list in the main thread when the heavy work is already done, this completely eliminates the huge freeze when opening the tab for the first time or when it updates if your list is decently sized (like mine), i'd throw around a few numbers but going from a few seconds freeze to "what? its over already?" is pretty much an infinite improvement. In any case, this was a very interesting experiment and some valuable experience that i hope to be able to use on other stuff later down the line, we'll see... and if you consider the Viewer not multithreaded (even tho it averages around 20 threads at all times) it now is officially multithreaded, at least as long as your preferences window is open haha.

Single-threaded


Multi-threaded


That's a big improvement as you can see.

Another quite small but interesting change is the falloff for Volumetric Lighting, rather than it being a straight falloff it is now using the distance squared, this should make the falloff gain intensity much faster towards the end, the side effect is that falloff now requires much higher values, the sliders have been increased to accomodate for that. It's overall a very miniscule difference and hardly noticable but i think it looks a bit more like what i initially wanted, i might implement an option to scale this later on.

Onto the most interesting part, the reported issues: About Land should no longer show a scrambled price label, profiles should once again allow creating and deleting picks (tested it and it works), clicking the description field in other people's profiles should no longer kill the formatting, clicking the X is online/offline message in IM should no longer throw a "invalid slurl type" error and finally.... FUCKING (speaking of fucking) FINALLY, the cock-magic bug is fixed. FIXED! I know you all loved being a magician but sadly as South Park has shown cock-magic is illegal and you should stop doing it... but what was the issue... ohboy... here we go...

This issue started surfacing somewhere in the last few releases, i spent a few days trying all versions up and down, trying to find out which version introduced this bug, soon enough i found out it was 3.4.2+, much sooner than expected. I went through all changes i made trying to limit the troublemakers down to just one change, bad for me this change was a masive one, it was a massive bunch of extra stuff for animesh so i had to drop this for a while. The issue started appearing in other Viewers too, reports from Firestorm and Official Viewer (i was able to reproduce it in Official as well) started appearing, all of them past LL code 6.0.2 which was the version this big change was included in. Black Dragon however was able to reproduce this issue 100% of the time, on the same obejct at all times. So on the last meeting i had a small but interesting talk with Beq Janus (from Firestorm) about this issue and what it could be, this lead me to investigate something and soon enough i ended up at the introduction of the new bounding box code that came with 6.0.2. I remembered that i changed something there, luckily i left an option to control the fidelity of said bounding box calculations so it was super easy and fast to see whether this was actually the cause and to my not-surprise it was. My overly aggressive attempt to optimize the bounding box calculations back to pre-6.0.2 performance surfaced this issue in a 100% reproducible manner, reading its code revealed an interesting tidbit which i think might be important on how to fix this issue for all Viewers. The Viewer creates a small box around the center of the object, then extends it with several factors, the base object bounding box, bones etc. In my case the bounding box was reduced to its first stage, the small box at the center of the object and that is exactly why the dick kept vanishing, due to the rigging putting it far off-center, the center (and thus the bounding box) goes out of screen when you zoom closer, the actual bounding box was somewhere above the actual visible dick, which explains why it reappeared when you looked up and why you could zoom closer before it disappeared again and you needed to look further up to make it reappear. This is also the reason why it didn't happen on avatars, they often have a decent center, unlike these genitals. In the code it states that it could possibly happen that the rigged bones are not initialized properly or at all, this could cause exactly what i just described just randomly, it would explain why it happens so rarely on other Viewers and why its fixable with a relog. Needless to say i re-enabled the full calculation for animesh but still left the second and third (the heavy ones) out for avatars, avatars seem to do just fine without these, animesh on the other hand don't, they need all three stages. So this issue should be fixed for now and should only appear randomly, very rarely just like in other Viewers. I explained the case in the Jira and hope that LL will find a fix for this rare case, maybe just revert to the old bounding box calculation (which worked just fine) in such a case, its better than having your dick vanish right?

by Loverdag

by Books
by Kissmebaby Allen
by Spiritus
by Jeremy





Saturday, June 29, 2019

Black Dragon 64x - Update 3.5.1 "Searching Dragon"

Another quickfix update.


Just a few more things reported.

Specifically Depth of Field lock wasn't working anymore and some avatars from KZK had their head in a wrong resting position.

AVX version will follow soon now that it has cooled off a bit.


Tuesday, June 25, 2019

Black Dragon 64x - Update 3.5.0 "Searching Dragon"

Quickfire update time.


Just smacking a few stupid bugs that were reported.

Flycam wasnt starting properly, rolling didnt work at all, the mentioned profile description issue is fixed (for both second and first life) you can now click the description and it will turn into the un-parsed version for you to edit and will turn right back into the final parsed version when you deselect it to preview how it will look for others, your own presets are now loaded again, autopilot should work again and mmo style click-to-walk should be fixed too. Hooraaaay.

Ohyea and i think the AVX version will not come the next few days... its going to be super hot (up to 40°C here and i dont want my PC compiling and turning my place into the inside of a vulcano), unless it gets very cool around night i won't be doing an AVX version, so don't wait for it.





Sunday, June 23, 2019

Black Dragon 64x - Update 3.4.9 "Searching Dragon"

Searching...

Searching for the update...

where is it...

Error 404
Update Not Found
...



So with over half a month delay (i'm so sorry about that), i can finally present something thats worthwhile showing and this update comes with a huge bunch of changes.



Let's start with the cat in the sack. Profiles! LL announced that legacy profiles would come back and their project viewer has been released, i grabbed it immediately and got to working on it... or more like reworking pretty much most of it. It all started with the simple desire to change the layout... because that's what i love doing right? Changing layouts, making everything look fancy... i open the profile file and... its empty... mostly... just file references to other files... at this point it already dawned upon me whats going on here. The bane of my XUI designer existance... file references to other files, panel injectors, everything split everywhere... total chaos.


Here's the original layout... it looks meh, wastes space and looks... "Firestormy"... well its coming from Firestorm, they commited their profiles to LL so we were going to get a 1:1 port of their profiles. If you know me you know that i can't stand this. What started as simply just redoing the layout ended up in taking the ENTIRE profile code apart, reworking large parts of it and re-implementing everything carefully piece by piece, 9 days... wake up, work on profiles, squeeze real life and some games inbetwen, go to bed, every goddamn day. It was a massive mess, bloated with trash, unnecessary code (and it still is, there's still much to optimize) and generally stupid stuff all over the place. Look i may not be a coding professional, i may not be a coder at all but even my baby code is still more organized, simpler, faster and not as much of a headache than this mess. Maybe my code looks like its written by someone whose first day of coding just began and doesn't want to fuck it up so you write everything super simple and straighforward but at least its not a complete dumpster fire, its simple and gets its job done (mostly because i dont know any super professional hacky stuff so i have to resort to stupidly simple things that look noobish)... but damn BURN IN HELL PROFILE... nightmares incoming. Anyway... said and done, its all smashed together, unified and should work without any dirty hacks, most important of all its smaller now, both code and XUI files.


Here's the new layout, it does the ziczacdigiridooimageparsingslurlthingy and everything. Great. If you find any issues please report them, i'll go for a second pass to finetune everything a bit and fix any issues that come up, provided i can reproduce them and find out why they are happening. Technically everything should work tho, i got my profile wiped when i fucked everything up so it was a nice first test to see if stuff is working, it should. Please be aware that currently your image parses get deleted when you click OK, so if you have any icons parsed (like i did previously or like Blizzard has on the picture) make sure you are aware of this issue, it will be fixed along with everything else that comes up.


Next up... Firestorm's preferences/menu search. Same story as above, it's a mess, i reworked it for 3 days straight and fixed a few... ugly things on the way too. Note that the functionality comes from Firestorm (who commited this also to LL, both the profiles and search are now official), i merely made it less stupid and eye-cancer inducing.


Yay... you can now... search things... i guess for all those who need it.

A lot of under the hood work has been done too, cleaning up, more microoptimizations here and there, some experiments amd a few changes here and there, for instance the "Search Bar" is back in the navigation bar... no idea why it vanished in the first place but its back! Hurray!

One other fix worth mentioning.. it was reported that rigged mesh doesn't cast shadows when certain conditions are met, namely when the object had a single face that had a RGBA texture (a texture with alpha channel) flagging the entire object as alpha blending while the rest was actually flagging the object as masking, this caused the object to be falsely flagged as masking and blending at the same time, driving it into an edge case where it would always skip casting shadows. Needless to say no more!

Another experimental feature that im working on is the ability to load presets from other Viewers... it is in for now but cannot be disabled, if you got Firestorm installed in its default directory (C:/Program Files/) you'll now be able to load all its presets from the sky/water/windlight editor... be aware that opening the window now caused the Viewer to freeze for up to a few seconds due to the massive amount of presets being loaded, its only on open tho, i'll add options to toggle it off later and maybe find a better way to organize them, for now you'll just find all of them mixed in with yours, yay, chaos!

Aside from those big changes theres a huge amount of small changes coming from LL, all the latest changes and fixes have been merged, lots of crashfixes, bugfixes, refactors and so on, most importantly for those of you using the latest Windows 10 update however (1903) should now no longer see their colors getting corrupted on exiting the Viewer. Great. TOOK YOU LONG ENOUGH NIRAN I THOUGHT MY GPU WAS DYING.

By Loverdag
By Loverdag

By Spiritus

By Spiritus
By Ella

Here's a little bonus, one of my fruitless attempts at always-on headtracking.

Thursday, May 16, 2019

Black Dragon 64x - Update 3.4.8 "Playing Dragon"

It's too-late-for-update time.


I wanted to have it released last weekend already but you know how it goes, you finish up something small and notice something interesting, then you follow that and BOOM you are in the middle of some huge changes taking much longer than you wanted.

Anyway, this update got some interesting things for you!


Starting with the first thing you'll notice, the loading screen, i've improved its loading process drastically, it will now update the progress a lot more in-between big steps and will also inform you on what it is doing. Rather than starting at 30% and jumping massive 5-15% at a time, it will now start at 5% for the login and add 1% for every small step it has done, you will obviously still see it jump a lot depending on your loading speed but you'll notice that it looks a lot more like it is actually doing something now, you can also see what its doing and where in the loading process it currently is, this not only gives you an idea what might be taking so long but also gives me better insight at which part of the loading process the Viewer crashes (if it does), which makes it extremely easy to find out what code caused the crash in the first place. Here's an example of how it looks now, note that the final version looks a bit different, the text is right next to the loading bar on the right side now and the colors have changed but it's essentially the same otherwise. Note that this was logging in with my alt account, hence why it was so fast, older accounts with more items will obviously take a bit longer and get more time reading the loading info.



Next up, as promised last update the rest of the changes to the about land floater. A few examples:





You might notice that the Audio tab is gone, it is now in the Media tab, this was done to use the tab's space properly, otherwise half the tab would have been empty on both tabs, what a waste of space if you ask me, they should work just as usual, if not report it to me and i'll look into it. Have a look:


Then there's preferences and its million settings, i went through the entire display tab and tried making sure that all settings are enabled and disabled when appropriate, hopefully reducing the confusion a bit when you tick an option and it doesn't do anything because it requires a different option to be ticked first. This means that from now on you'll see a lot of greyed options in display if you keep lot's of things off and because i'm not stupid you can still use the [default] buttons in that very edgy case you've set an option so high that it crashed the viewer and now you can't set it back down because you need to have the option enabled to use the sliders which would immediately crash you again. (you would still be able to do it on login without issues but that's a different thing...). Future plans include actually telling you why said options are disabled, i'm thinking of an overlay that simply tells you "Needs X enabled" in red probably, we'll see.

This update also brings a new handy feature for machinima and photographers like myself. I present you: Raise Water Level. Yes! You heard that right, from now on anyone can change the water level on any region locally (and revert it back to region default if they need to) at any time. Why? Story time: I went through my pictures and noticed a distinct lack of nice pictures so i set out to make a new one and visited Maddy's EchtVirtuell blog to find some SIM tips, didn't take long to find a nice one, Elvenshire. I went there and tried making a picture but was dissatisfied with it and gave up and went to do some other more important things at the time. Some time later Ella posted this impressive picture into my Discord channel of the same place i went to...


When i saw it i wanted to head back and fix all the things that annoy me in this picture, the seemingly distinct lack of SSAO usage, the missing water and reflections, the pixelated shadows in the front (on the alpha surfaces) and the seemingly missing or inappropiate shadows in the background on the second wreckage and beyond. Said and done, i went there and...


i just couldn't finish this picture... the pixelated shadows on the alpha "water" was absolutely killing me (and the picture) so i said "fuck this, i'm doing it now" and added a feature to change the water height so i could raise the water level and derender all the fake water. All said and done and the outcome after some additional playing with sliders was this:


This is definitely a massive improvement over the above image but i still wasn't happy, i wanted it to be closer to Ella's original shot, so i made some drastic color correction and tone mapping changes to get to this:


Color wise its closer to Ella's shot but obviously i didn't want to just copy her (which is also almost impossible, each shot is highly unique and with so many options it would take many hours to get even remotely where you want it to be) but instead improve on the original image and its problems with shadows and SSAO. I'm quite happy with the outcome, it looks really good and makes use of the region water in a decent way... and that's how the Raise Water Level feature came to be. You can find it in the windlight water editor here:


Last major noteworthy change is the improvement of the bone camera i introduced a while ago, it will now rotate with your avatar instead of staying fixed in place, this allowed me to make another little funny thing i wanted to do and was basically another one of those features i made just for something i wanted to show. Tick HD and sound and enjoy.



The rest of the changes are just tiny fixes for reported issues, small QoL changes and cleanup in the Viewer, changes that should hopefully improve the overall quality and feel of the UI and change the Viewer for the best it can be.

By Ella

By Ella

Saturday, April 27, 2019

Black Dragon 64x - Update 3.4.7 "Playing Dragon"

It's too early-update time.

I really wanted to cook this one a bit more but i think the joystick thing would have sidetracked me for far too long and this update comes with 2 important crash fixes that seem much more important than fixing the jerkiness of joystick controls.


So without further ado, here comes 3.4.7, mainly an early release due to the aforementioned two crashes reported one being a week ago and the other one just yesterday. The first one fixed is a crash when you stop all motions completely and manage to hang the recreation of the headtracking animation in such a way that touching the head/eye tracking sliders results in a crash due to the animation not running. The second crash is related to right-clicking animated mesh on yourself or on others (with outline selection updates disabled). Both should be no longer.

Also once again i've gone through some code and micro-optimized calls here and there, nothing you'll notice but it sums up i suppose, this includes main viewer window loops and the joystick/flycam loops, i've also tweaked the flycam a bit to HOPEFULLY be a bit less jerky on massive framedrops, i can't get rid of the different input strengths with different framerates (not without completely rewriting it) but the difference should be smaller and sudden FPS drops shouldn't cause the camera to fly into space anymore.

Global brightness should now also work on lit alpha and material surfaces and whatever it was that caused projectors to not work at all on them seems to be fixed as well... magically.

Besides these changes, the latest LL code has been merged, namely EAM (Estate Access Manager), with it come more controls over bans (that's pretty much all i've seen). I've started overhauling the first tab of the "About Land" window now that EAM is done, the rest will be coming in the next updates.

before
after

About EEP: LL is working on fixes for all the reported issues (there are a lot), sadly it does not seem like they want to change their mind about marketable presets, this will mean that i'll either drop EEP support for now or at least make make some pre-EEP / EEP hybrid abomination that adds the new controls and features of EEP without the regio-share support and keep the old pre-EEP thing intact. Oz will absolutely hate me but its not my fault that they are doing the stoopid with these items.

For those who haven't seemingly seen my actual EEP bug-rant yet (yes Nalates i mean specifically you) you can find it here on the Second Life Forum - EEP Feedback Thread it's a massive scale rant (with pictures too) and it's a two part thing too, the continuation follows a few comments later. I can tell you that i am truly infinitely pissed, no amount of bugfixing is going to change that... but if those rumors of a full inverse kinematic animation system was true that would possibly make me happy.

By Ella
By Spiritus
By Jarrgo
By Beev


Saturday, April 13, 2019

Black Dragon 64x - Update 3.4.6 "Playing Dragon"

Sweet sweet updates, you got more of them sweet updates?


An update dedicated mostly to optimization and bugfixing wheeee.




Overall performance should be better all around, everywhere, when avatars are around and when not, top performance should also be better. I got up to 140 FPS before the meeting on friday and still had ~45 FPS when everyone arrived, that was quite nice to see. Mostly selecting objects, specifically meshes have been further optimized in hopes to reduce any kind of hitching to an absolute minimum.

While we are on the topic of selecting things, selecting meshes should be a bit easier and hopefully more reliable, note that meshes are still a finicky thing and may just decide to randomly not be selectable anymore for no reason, it's a mystery.

The land tools should now send the correct tool to the server, meaning you'll now use the correct tool again.

Headtracking has been... revamped a bit, it does no longer feature two sliders for horizontal and vertical restrictions but rather offers one slider for head in degrees and another one for the eyes, this means you can now turn off eye tracking once and for all (hopefully). This feature is directly applied to the headtracking motion so in theory it should apply for all effects that use this motion. It does not disable random eye jittering though.



Next up a reported crash when pressing Factory Reset while not logged in was fixed (phew, it tried to reset your user settings when it doesn't even know yet who you are!)

Another reported issue was land info / profile reverting any unchanged windlight modifications, this should no longer happen, i took the time to fix a longstanding issue that caused the water changes and/or preset to revert to default when you changed the sky preset as well while working on the previous issue. Begone bugs.

Overall there has been done quite some stuff under the hood, most of which you might not notice but if you do, let me know, worst case the performance should be the same.

With this update the Viewer is also up-to-date with all the latest shenanigans of LL minus the worsened selection performance, this means autoplay in the webbrowser works again, hooray the login screen will once again play the video automatically!


EEP. Enhanced Environment Project is becoming a big topic lately and yes i've looked into it long ago, i wasn't satisfied nor am i now, in fact i'm massively disappointed, i keep hearing a lot of bad things about it and it gets worse. Not only is EEP going to break possibly every single graphical optimization and improvement i have ever done the past 7 years, in its current state it will break rendering as a whole, it's a fucking mess from what i was shown. I'll be testing EEP out myself soon but i can tell you i'm not going to have fun with this. I'm at a point where i'm denouncing support for EEP as a whole. Not only is the rendering part a disaster, its implementation is catastrophic to the point that its akin to spitting in our faces. LL has fucked up many things in the past but this easily takes the cake. With the new system they are going to take away the ability to locally modify any region windlight and give us this re-introduced feature they call "local environment" that is to replace it, not only doesn't it offer all settings it also does not allow us to change our modifications because from EEP onward windlight presets are seen as marketable items which means being able to edit someone elses windlight and save it is seen as copybotting. What a joke. I for my part would be ashamed coming up with such disrespectful nonsense towards photographers and machinimas, the very reason windlight exists and is so popular in the first place, it's windlights very reason to exist, what else does sky and water mean if not for photo and machinima and now we're spit in the face with this marketing bullshit. You can keep your stupid EEP if all it does is limit the very thing you write so big on your goddamn flag. "Your World, Your Imagination", more like "My Ass, Lick It". If i were you i'd go to LL's forums and burn down their forums until they understand.


Some sidenotes about this update: I became fed up with the seemingly decreasing performance so i tried out several other Viewers to get a picture of how well BD performs compared to them and to my surprise BD has been able to keep up with all of them except the very latest Singularity which was a whopping 10 FPS more average.



That isn't all that bad when you take into account that BD employs a few settings more and sets several options a good chunk higher besides drastic visual changes in several shaders such as for shadows, ssao and depth of field. My panicking was for nothing, BD's performance seems fine when compared to other Viewers but it's probably better to panic about performance once in a while and go on performance-improvement sprees to make sure performance stays the way it is than just adding shit on top and watching the viewer crumble to pieces.



By JDB
By Pirschjaeger
By Ella

Tuesday, April 2, 2019

Crawling Shadows: The Quest For Infinity

It's time i make a new informative post, one that i've made in the past already but will try to recycle in a more informative and hopefully better explained way.

This post will address the many issues with shadow rendering that many of you probably have seen already, one we might never ever have fixed.


So what is the issue? Let's start at the beginning, what are shadows, technically speaking. Technically speaking shadows are the lack of light or depending on how you see it a huge overay of darkness. In Second Life shadows are everywhere where there is no direct sunlight, how does this work? Take the sun, imagine your camera at this very moment is the sun and you are shining wherever you look. Now imagine you are shooting a ray from your sun camera into the world wherever you look, when the ray hits a solid object it stops and you count the distance how far this ray went before it stopped, everything past this ray in this direction is assumed to be shrouded in darkness, shadows. The Viewer does this many times every second, as fast as it can for every pixel on screen (with a 1920x1080 resolution this would mean 2073600 times just to finish the screen once). As you can imagine this is extremely slow (this is essentially raytracing) so to make this run decently fast some genius people came up with tricks to make this faster, one of them we use in Second Life. Cascaded Shadow Maps.

Cascaded Shadow Maps is simply put splitting the covered area into several segments (cascades) to make use of different shadow map resolutions for different distances, save resources and overall up the quality and reduce the artifacting we would encounter when rendering one large shadow map over the entire world. What we do is we take our "sun" and calculate a shadow map that is essentially a texture with three-dimensional information on lighting conditions in a covered area, we do this by rendering an image with coverage information with all objects inside this area, basically we are rendering the covered area a second time (although much faster and simpler) to "bake" the objects depth information into the texture which we later use to determine shadowing. We do this with a given resolution for each shadow cascade, 4 here (some games use 6). Since a shadow map can only contain a certain amount of depth information, similar to a depth map can only contain a certain amount of inbetween color steps from black to white, there's only a limited amount of precision, the smaller our area the higher the precision as we have more depth-steps in a smaller area, thus being able to define depth differences more accurately.


Depth map portraying the precision issue: Close to us everything is seemingly black (e.g the same depth) the same goes for flat angles and close to infinite depths, we only have 256 shades from black to white.

As you might guess this already has a massive drawback. If the resolution is too small, the area too big or the camera/sun angle too... special we run into precision issues.



Looking at the above pictures we can see that the shadow precision takes a huge hit on the lower one the further away our shadows are. My body still has highly precise shadows, while 4m into the picture the shadow precision becomes noticeably worse almost making it indistinguishable, another 8m into the picture and shadows become pixel mush. This is because the first 4m of the picture (roughly to the tip of my tail) the shadows use the first shadow map at 2048x2048 resolution, meaning we have roughly 5 pixels for 1cm depth, that is still highly accurate. The second shadow map uses 2048x2048 as well but covers 8m depth, meaning we are now left with roughly 2.5 pixels per cm. We've become half as precise and we can clearly see that 2.5 pixels is... just barely enough to produce something we can identify as our shadow. Beyond that we use 512x512 for the other two shadow maps, the third being 24m and the third being 64m. With 24m we get 1 pixel for roughly every 5cm that is highly inaccurate.


But wait that's not everything! We haven't even talked about the angles. BD has much better shadow accuracy but even BD has issues displaying shadows with low angle sun but why? Remember the depth map? Imagine you are looking at a plane from above, you can see every centimeter of it clearly, now as you approach a lower angle it becomes harder for you to see every centimeter of the entire plane, you start having issues telling apart how far something is away, if you were to lie down on the plane and look over the plane what would you see? Almost nothing, an almost straight plane, basically 0 depth perception, if anything or anyone were standing on it you could only guess how far it is away from you based on your previous experiences and its size. Similarly the rendering has issues defining depth on a plane that is pointing its ends towards you rather than the huge flat area, if you were to look perfectly along the plane on the same height as it you would see only the start of the plane and then the infinite nothingness behind it, 0 depth. Similarly here, if you were to shoot a ray or render an object in front of you while the camera is lying down flat on the ground you would only see the object, possibly a bit depth on the object itself if it does have some (like an arm in front of a body) and that's it, if you use this as shadow map you'd be casting a shadow from this object across the entire plane into infinity and the one pixel touching the ground would be used to determine whether the plane is shadowed or not for as long as this plane goes (obviously a super cataclysmic example), if we imagine the same situation with a slight angle we would still be using a single pixel for many centimeters (if not meters) of the plane causing extreme inaccuracies and artifacting... crawling, pixelation, flickering to name a few, the crawling here coming from the rendering applying this shadow pixel (square) to a changing camera view angle and guess what happens if you rotate a huge square shadow pixels to "face" your camera... right you see this pixels seemingly "crawling".

Example: How far do you think my avatar is?

Solution: You thought it was very close... no you thought it can't be because i wouldn't be asking this question otherwise right? You're right, my avatar is roughly at 1/3 of the plane's total depth. We can see this with the depth map, my avatar is clearly much brighter than the platform. This perfectly illustrates the issue with depth at certain angles, we simply can't tell depth here this creates mistakes.



How can we combat this? Raise the shadow resolution! Reduce the shadow distance! I hear you shouting... well yea... no. You see... this issue is just the drawback of how we render shadows, we cannot truly fix this, not without sacrificing more resources, whether it is adding more shadow cascades (6+) using extra techniques such as screen space precision shadows for small scale objects, raising the resolution or lowering the distance shadows cover, they all have their pros and cons, most noticeably cons, the performance. Raising the resolution does improve the accuracy but also massively impacts the shadow rendering performance, even more so with high complexity objects. Lowering the shadow distance does make the shadows more accurate but in a smaller area and can negatively impact performance as well in certain situations. Having a huge area covered is less straining than a smaller part of the same area that shows the most complexity since this complexity is now rendered with much higher precision (you could say resolution, but the resolution is the same its just more accurate). Adding extra shadow cascades uses more memory and adds 2 more shadow map rendering iterations to the mix and so on. All we can do is adjust the settings to match the scene as best as possible, this is why i added the shadow distance and shadow resolution sliders large non-detailed areas can be grouped into one shadow area with lower resolution than lets say an area with complex items such as grass/leaves or avatars which require a lot more accuracy to be distinguishable. A tip from me, lowering the first shadow map to 2 or 1 doubles/quadruples the accuracy of shadows extremely close to your camera while a 64-128m shadow map with 1024 to 2048 can be sufficient for a huge area, remember you can adjust all shadow maps separately to suit your current needs, make use of them.

The differences can be between this:


And this. I turned the shadow resolution close to me down and the distant ones way up, while the distant ones look decent now, the close ones have become a garbled mess.

Another example:


This is the transition from the second to the third shadow map, i could easily fix this by reducing the first two shadow maps (since they are not visible anyway) to 512x512 and the third (most of it here is covered by it) to 2048x2048 or higher.