Another soft shadows demo

[Humus]

Nice demo, but my feeling is that it softens the shadows too much at the start of a shadow. There it should be sharp and becomes more soft the further it gets away from the start.

True. I'm cheating a little. I only blur with regards to distance from light. It works fairly well, but I should really blur according to distance(fragment, occluder) / dist(occluder, light), but that would require another pass to apply a dilate filter on the depth values alternatively additional geometry in another pass.

 

[wireframe]

I've uploaded a new version. I recall the 5x00 series cards had trouble with the R16F format as render target, so I changed that to RG16. See if it works better now.

Still a no-go on GeForce 6800. Same result as previous version.

Forceware 61.77 & DirectX 9.0c (Win XP SP2).

 

[Humus]

Can you post a screenshot so I get can a hint?

 

[wireframe]

Can you post a screenshot so I get can a hint?

Thumbnail. Click for a 1024x768 resolution version.

 

[Humus]

Hmm, that looks like geometry corruption. Perhaps it's the clipping planes that screw things up? I added an option to disable clipping. Try and see if it makes any difference.

 

[Mendel]

nope its not the clipping, I noticed I get textures back if I edit the return statement of lightning.shd to not have "shadows" also changing the value of "shadows" in the code seems to have this effect.

edit: its not a fix though... shadows are then obviously not there and I still see those gray boxes, but they're transparent

 

[Mendel]

another hint, those gray boxes keep the same distance and position in relation to camera even if I move. With the modified shader I can see I'm moving in the room, but the gray boxes move their own route on the screen, I can't move in relation to them. edit: they seem to move same speed and circulate in kind of the same way as the light...

 

[Mendel]

the bug is in distance.shd I think...

edit: I put distance.shd to return 0 and remove shadow * from the return statement of lightning.shd to get rid of the boxes completely and to see everything but the shadows. Nice bumpmaps tho

(sorry for this insanity, I'm not a coder, I have no idea what's happening in the code and I'm just almost randomly trying stuff... Hope it helps, though )

 

[Humus]

another hint, those gray boxes keep the same distance and position in relation to camera even if I move.

This is expected. I use clipping planes to cut out a box around the light. Anything outside that box won't be drawn. It lets me save fillrate for the parts that are beyond the light radius. So if the shader for the dynamic light is broken to be grey, it will be a gray box moving around with the light. Now why it's broken ...

 

[KimB]

Edit: Nevermind. I didn't realize that it was the light moving that caused the boxes to appear to move...they don't, so it's got to be something wonky with the clip planes.

And, btw, I get the same result with the 66.31 drivers.

 

[KimB]

Odd, even after commenting out all the clip planes code, I still got the exact same issue. What else could it be besides clip planes that moves when the light moves, but not when the camera moves?

Oh, you know what? I bet it's not changing the rendertarget properly. I bet what I'm seeing on an nVidia card is the last face of the shadow cubemap to be rendered.

 

[KimB]

Yup, got it. Change the rendertarget to I32F. Works like a charm. Slow, but it works (I'm getting about 16 fps). Currently testing other rendertargets to see if they work....

Edit: Yup. RG16F works great, too. No visible difference in performance.

 

[pocketmoon66]

Nice demo, but my feeling is that it softens the shadows too much at the start of a shadow. There it should be sharp and becomes more soft the further it gets away from the start.

True. I'm cheating a little. I only blur with regards to distance from light. It works fairly well, but I should really blur according to distance(fragment, occluder) / dist(occluder, light), but that would require another pass to apply a dilate filter on the depth values alternatively additional geometry in another pass.

Like this

http://www.shadertech.com/cgi-bin/shaders.cgi?filter=1&page=3

The code is a bit off-base to say the least. I wish I had time to revisit it and do a proper implementation.

Basically I did multiple depth map samples, as has become so popular recently , but I expand the sample area based on the distance to the nearest occluder. A shadow map usually stores the depths of the occluders closest to the light source but what do you do with overlapping occluders ? Answer - deep shadow maps! IIRC I depth peeled 4 depth values into the shadow map, which was enough for simple scenes.

I'd like to see PCF implemented by ATI in hardware but also I'd like to see Nvidia PCF samples return a floating point value rather than just 0 or 1, that could help speed things up using SM3.

Rob J

 

[KimB]

IIRC I depth peeled 4 depth values into the shadow map, which was enough for simple scenes.

Did you somehow order them so that the depth values were depth sorted and only the four smallest depth values remained? That seems like the obvious way to do it...but it would require reading the shadowmap texture into the shadowmap rendering shader, wouldn't it?

 

[pocketmoon66]

IIRC I depth peeled 4 depth values into the shadow map, which was enough for simple scenes.

Did you somehow order them so that the depth values were depth sorted and only the four smallest depth values remained? That seems like the obvious way to do it...but it would require reading the shadowmap texture into the shadowmap rendering shader, wouldn't it?

Yep

I did a depth peel, back to front (occlusion query can tell you when to stop) and on each pass I ping-ponged between two shadowmaps, shuffling the depth values along my render target.

On initial pass all depth values are zero'ed and then :

Source : Last shadow map [d1][d2][d3][d4]

Target : next shadow map [=d2][=d3][=d4][=curr fragment depth]

and rebind the updated target as source on each pass.

At the end you have the 4 shadow depths closest to the light source.

Deep shadow maps are cool, notice how the shadow on the floor under the sphere is darker than the shadow cast from the bridge

Rob

 

[KimB]

Yeah, that looks really sweet, but it'll be a while before that sort of thing can be used in games. That said, it seems you might be able to use the 6x00's FP blending support to optimize that algorithm significantly.

And I would really like to see a good implementation of screenspace shadowmaps...

 

[Para]

Yeah, that looks really sweet, but it'll be a while before that sort of thing can be used in games.

Haven't played Max Payne 2 lately?

Remember, everything doesn't have to be 100% accurate code-wise, the most important thing is that the developers get the effect they want.

 

[Mendel]

Yup, got it. Change the rendertarget to I32F. Works like a charm. Slow, but it works (I'm getting about 16 fps). Currently testing other rendertargets to see if they work....

Edit: Yup. RG16F works great, too. No visible difference in performance.

which file, which line? Give original and modified line for us that don't understand shit but can replace a given line in a given file in a given place, please

(if its in the main.cpp I'm out of luck until humus updates the download since compiling the thing is a step too far for me )

edit: it seems Humus already updated it, it works now.

 

[Mendel]

now its only that the light/shadows being fully dynamic isn't used to anything as the light just follows the same path... how about making the light follow camera or something like that?

 

[Humus]

edit: it seems Humus already updated it, it works now.

Yes, I fixed it this morning after reading Chalnoth's post. Didn't have time to mention it here though.