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.

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.