Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Shadow mapping resolution

Author
Message
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 23rd Apr 2012 11:30 Edited at: 23rd Apr 2012 11:30
I finally got a shadow mapping shader working, using Evolved's example as a base. However, I get quite poor quality shadows with the viewpoint and size of the area I'm rendering.



I think the issue is simply that my light source is above and spans quite a large area. There are probably only 2 or 3 pixels in the depth map that map to the vertical walls on this ramp model. So I think basically when the projection look ups happen, there just isn't enough data to get an accurate render.

At the moment I'm thinking about sticking with static light maps, and just using shadow mapping for the actual characters. I'd simply just render the players and the arena flat base in the depth check, then render then the geometry wouldn't be factored into the depth and would not cast shadows; it'd only receive shadows from the character.

Before I throw away the idea of realtime level lighting, does anyone have and suggestions for fixing this type of problem?

Andrew_Neale
16
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 23rd Apr 2012 12:26
If you're using the example from Evolved that I'm thinking of then the problem is that, as it is cube map based, it is great great for a small fully indoor environment (e.g. a light per room) but for outdoor or top down environments a lot of shadow resolution is wasted upwards. It also means that the further an object is from the light source the more stretched (lower resolution) its shadow will be. For these reasons I've been using Evolved's soft shadow mapping example instead which works using DBP's built in shadows but renders them to a intermediary target which the shader then blurs and combines with the scene. Whilst the dynamic shadow can look a little out of place when mixed with a lightmap, from what I've been working on recently as long as you get the shadow level right it can still look pretty good.


Previously TEH_CODERER.
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 23rd Apr 2012 15:45 Edited at: 23rd Apr 2012 15:46
I was trying the standard shadow map shader which renders one static camera and a spot light style image. The lighting will always be from above and lighting a surface below, so the cube map system would be wasteful, as you alluded to. I think the static light maps are the way to go for what I'm doing, with dynamic character shadow maps. I'm quickly realising there is no one perfect technique, and really you have to find the best solution for what you're trying to achieve. Thanks for your input and good luck with your game though!

Andrew_Neale
16
Years of Service
User Offline
Joined: 3rd Nov 2009
Location: The Normandy SR-2
Posted: 23rd Apr 2012 16:14
No worries, and thanks. I'd wish the same back but having seen how awesome 'Carnage' is looking it doesn't seem like much luck is required.


Previously TEH_CODERER.
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 23rd Apr 2012 21:30 Edited at: 23rd Apr 2012 21:32
If the camera and the light source are both pointing down from above, then it seems unlikely that there would be such a big difference in quality, unless the light source was covering a much larger area than it needs to. The depth camera should only render just enough to cover what the camera can see. Try debugging the area that the light source covers for a particular camera position and make sure it's not wasting space in the depth texture. Also make sure the near/far distances on the depth camera are sensible values.

[b]
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 23rd Apr 2012 22:49
Done all that Diggsey. I view a 50x50 area of the map and the depth camera captures precisely that area. Where it looks down on those models in the example picture, it has very few pixels available to capture depth data for the vertical surfaces because it simply can't see them.

In the most extreme example, the depth camera captures the top sloping ridge and then the floor, with nothing in between. So when the look-up occurs from the perspective camera, due to floating point precision etc. it appear its samples from the top edge (in light) and then the floor (in shadow) intermittently as it figures out what colour the wall should be. At least, that's my assumption.

There's a limitation with using the DB camera to capture the depth data, because afaik, they can only be set to the resolution of the whole game. If I could set the depth camera to say 2048x2048 and render all that, maybe I could get some precision for all the intricate bits of the level, but then there would be a performance hit obviously. I just have a feeling this method isn't really suited for lots of complex little bits of geometry.

MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 24th Apr 2012 05:04 Edited at: 30th Apr 2012 14:55
Are you using the "Shadow Mapping" example or the Advanced Lighting "Spot Light" example? I'm going to assume Shadow Mapping for now, because that's what I would have used in your situation.

You can increase the resolution of the output image from the depth cam to anything you like. This will have a performance hit. I have found that "increasing" the resolution doesn't really have that good an impact on quality - but decreasing is a bad idea. Stick to the default 512x512 or above.


[edited for easy searching]


EDIT: Also, make sure your depth-camera aspect matches the aspect of your output image. It's not usually a big deal - but depending on you "spotlight" image, it can have undesirable results. If these ideas don't fix your problem, maybe post your depth map here?
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 24th Apr 2012 07:22
Quote: "Also, make sure your depth-camera aspect matches the aspect of your output image."


Yep that drove me nuts till I figured it out. Nothing like having shadows and reflections that won't position correctly.

Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 24th Apr 2012 14:57
Can you post the image produced by the depth camera (preferably both a depth image and a colour image)? The biggest problem seems not to be the resolution but the way the depth data is encoded into the texture, and this should be easy to adjust. A normal ARGB texture can easily be accurate enough if the depth is encoded correctly, since you have 32 bits per pixel available and the standard depth buffer is only 16 bits per pixel.

[b]
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Apr 2012 15:15
Quote: "A normal ARGB texture can easily be accurate enough if the depth is encoded correctly, since you have 32 bits per pixel available and the standard depth buffer is only 16 bits per pixel."


That's not usually the problem. The problem is as Fallout has described. The relevant part of the shadow map consists of just a few pixels and it doesn't matter how accurate those few pixels are you will get sharp zig-zap boundaries when those few pixels are stretched over a large area as in the near vertical surfaces in the original screenshot.

What's happening is that a large part of your model can be given a single depth map value when in fact the depth can vary noticeably across the region of interest - so any one value, no matter how "accurate" it is, will only be a crude estimate for a significant part of the surface. Increasing the shadow map resolution is a crude and expensive way to solve that problem. Another expensive solution is to filter or jitter the shadows.

There may be a more sophisticated way of filtering the edges but it escapes me at the moment.
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 24th Apr 2012 15:51 Edited at: 24th Apr 2012 15:53
@GG
That's part of the problem but the shadows are also appearing in the wrong place. The whole face of the first wall on the second ramp should be in shadow but it's not because the wall is too thin to be accurately reprented in the depth map, so the only part that is shadowed is the part behind the ramp which is easily wide enough. The same is true for the second wall, and if you look you'll see that those are the only two places with jagged edges.

[b]
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Apr 2012 16:30 Edited at: 24th Apr 2012 16:35
Quote: "That's part of the problem but the shadows are also appearing in the wrong place."


Actually I'm now confused by that first screenshot - the light seems to be coming from two quite different directions.

But, yes, I see what you mean - the zig zags on the ramp itself are a larger scale than the zig-zags on the ground. It should be simple enough to change the shader so it outputs 16 bits for depth rather than just 8 (if we're talking about the same shader). That should be enough to make the problem far less noticeable. If it has no effect then something else is the cause. If it isn't enough then try 24. (Not sure off-hand whether 32 bits would cause problems if you want semi-transparent objects. I'll have to remind myself how I did it in one of my demos. )

Edit That right hand ramp looks completely wrong - why hasn't the diffuse lighting put that surface in shadow anyway? There's something else wrong here besides the shadow map issues.
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 24th Apr 2012 18:02 Edited at: 24th Apr 2012 18:05
Sorry chaps, you're right. The light is coming from two different directions because those are two different images. Even though I crudely spliced two screenshots together with reckless abandon, the resulting image was actually a perfectly seamless screenshot.

Here's the modified shader I was using. I stripped out all normal mapping and light projection and kept it simple with just a depth map and base texture.


Unfortunately I made my decision to stick with lightmapping and stripped out all my test code and have returned it to it's previous state, so I can't provide a depth map or anything else. If it helps though, I reset the camera to the exact location the shadow map camera was at and repositioned the same ramp prefabs as they would've appeared in the depth map. I can also confirm the depth map has a decent blend from light to dark grey, with reasonable good contrast (i.e. I could make out the shapes clearly).



I measure the top of the ramp walls as 8 pixels wide in this image. Also the image is thinner than you'd expect because I've stripped out the GUI that was present in this render. There was no GUI in the actual shadow map.

This was as close as I could possibly get. This cuts out quite a lot of the scenery in the game, so really I'd need to pull the cam back even further to make practical use of the shadow mapping.

Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 24th Apr 2012 18:23 Edited at: 24th Apr 2012 18:27
That image is easily a high enough resolution to be used for shadow mapping. The problem is definitely caused by the fact that the shader only outputs a greyscale image giving only 8-bit depth.

Sadly DBPro (AFAIK) doesn't support rendering to floating point textures which would make this very easy. Instead you have to do something like this to encode the depth in RGB:


Btw GG, it would be very difficult to use semi-transparent objects with shadow mapping, but it's an interesting challenge. Perhaps you could render the depths of transparent objects into the AR channels and the depths of opaque objects into the GB channels. That would let you have one layer of semitransparent shadows of a single colour over the normal shadows without needing an additional render target. You would need to use additive blending to be able to render AR and GB components independently.

[b]
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 24th Apr 2012 18:32 Edited at: 24th Apr 2012 18:33
Quote: "The problem is definitely caused by the fact"


Ok, I'm taking that as gospel! I will try again and up the depth resolution later on when I return to shaders and report back. If it's wrong, I'm coming to get you!

The thing is though, when I look at that screenshot, look at the rightmost ramp. If you look at it's left wall, you can clearly see the steps in pixels, as you can with anything really. The whole of that left wall should be in shadow. It seems possible to me that, if a camera was looking at the side of that wall, during the look up process in the shader, when a pixel for the side of that wall is mapped to it's corresponding pixel in this depth image, it could occasionally map to the top of the wall and then the floor base, due to floating point imprecision.

To me that'd explain the jagged line effect I was seeing on the wall. As it samples along the one or two pixels that represent the wall area that is in shadow, it could map to the depth value for the floor, then the top of the wall, then the floor again, during the maths conversions. That was my assumption at least, to explain the pattern. It seems unlikely that it would perfectly map to the depth pixels running along the top of the wall every time. That's not my experience of floating point maths.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 24th Apr 2012 18:55
Quote: "Btw GG, it would be very difficult to use semi-transparent objects with shadow mapping"


My statement was semi-precise.

I was referring to surfaces which were partly fully opaque and partly fully transparent such as leaves on simple low poly trees (as in Tree Magik). Both I and Evolved have provided shaders for that situation. Mine is buried somewhere on the Learning to Write Shaders thread .
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 24th Apr 2012 19:43 Edited at: 24th Apr 2012 19:47
Quote: "it could occasionally map to the top of the wall and then the floor base, due to floating point imprecision."


I don't think floating point precision is an issue here, 32-bit floats are easily accurate enough to distinguish in these cases. The problem is when you then store that 32-bit float in an 8-bit channel in a texture.

Also, have you though of using an orthographic projection for the depth camera? That way the light will come at a fixed angle to the world, and so you'll rarely get things that point directly into the light.

[b]
revenant chaos
DBPro Master
19
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 25th Apr 2012 02:17
I think D3D format 116 may do the trick, the help files describe that image format as: D3DFMT_A32B32G32R32F.
I admit I merely skimmed this thread, but it looks to me like you are using the real-time cubemap commands from darkshader. If you are, you need to setup a special camera to render the cubemap, and pass that camera's id to the "Render Dynamic Cube Map cubemapID, camID, posX#, posY#, posZ#" command.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Apr 2012 02:36
I don't think the Dark Shader commands allow you to specify the image format - the standard DBPro set camera to image command does though.
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 25th Apr 2012 03:13
In that case you will want to use "D3DFMT_R16F" (111) or "D3DFMT_R32F" (114) whichever is supported.

[b]
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Apr 2012 13:22
Quote: "whichever is supported"


Neither unless you're able to use set camera to image.
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 25th Apr 2012 15:07
Oh right, I assumed it was already using that. Is it for some reason incompatible with "set camera to image"?

[b]
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Apr 2012 15:13
Quote: "Is it for some reason incompatible with "set camera to image"?"


If it's using the cube map idea then the answer seems to be "yes" due to a DBPro bug/limitation (or at least I can't get a dynamic version of DBPro cube mapping to work with shadow mapping ). I've had to resort to the Dark Shader cube mapping commands which don't give you control over the image format. A right pain.

I was going by revenant chaos's comment. But if the demo is using a single camera view with set camera to image then there should be no problem as you say.
revenant chaos
DBPro Master
19
Years of Service
User Offline
Joined: 21st Mar 2007
Location: Robbinsdale, MN
Posted: 25th Apr 2012 17:41
Ah yes, I remember now.. but now I dont remember what I was thinking when I posted
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 25th Apr 2012 18:55
You are not alone.
MMM
17
Years of Service
User Offline
Joined: 21st Jan 2009
Location: NSW, Australia
Posted: 30th Apr 2012 14:47 Edited at: 30th Apr 2012 14:48
Took this pic for something else entirely; just now realised it also demonstrated the above-stated fix. Thought I'd post here to make searching easier later.

This is setting the depth camera's image with format 114 (D3DFMT_R32F). I also set the float values in the depthmap code to 0.2 instead of 0.8 to reduce scattering.

Pretty neat!


Login to post a reply

Server time is: 2026-07-08 05:37:13
Your offset time is: 2026-07-08 05:37:13