Soft Shadows (w/o EA) Demo (99% done, released)

[nullsquared]

@ CABAListic: You can get away in simple scenes with no self shadowing by blurring a white/black texture (white is viewport background, black is any objects), and projecting that onto receiving geometry...

That's right (in fact that's part of the technique I'm refering to), but you're losing the depth information and may therefore have backprojection of shadows and such things. This only works if your shadow receiver is always behind (seen from the light) any potential shadow caster.

Anyway, I didn't succeed to find the paper I got it from, if I remember correctly, its title was "Simple soft shadows", but that didn't show up on Google. I'll keep looking and post the link, but in the meantime, the technique works like this:

You need a 2-channel shadow texture. In the first channel you store the depth from the light like with occasional shadow mapping, and in the second channel you store exactly that white/black image, except in the paper they do it reverse (i. e. they assume that the shadow texture defaults to black and store a 1 in the second channel for every caster. Naturally you can do it the other way, just need to remember to adjust the formula later). Then you blur both channels of the texture (might want to use a box filter instead of gaussian, since this is supposed to be a fallback for not-so-good hardware), and in your receiver shader, you extract the actual depth from the shadow map via this code:

Code: Select all

float4 shadow = tex2D(shadowTex, shadowUV);
float depth = (shadow.x-1) / shadow.y + 1;

If the depth check says the area is shadowed, then you use the second channel to determine the amount of shadowing.

Though, if you ask me, actually you could just NOT blur the first channel (only the second one) and save the calculation above, that should work equally well, I think.

Interesting. So it's basically what I mentioned, except with an added standard depth check.

[dEspadas]

Great work!

Just to let you know, it runs on my FX5200, but I should spare us both from the FPS.
Anyway, I succeed in adding 3 lights before it was just to hard for my poor GPU to move the camera at all. I need an upgrade urgently.

The only thing was that I got some artifacts on the shadows, just don't know if it's something expected due to the oldness of my GPU.

[nullsquared]

Great work!

Just to let you know, it runs on my FX5200, but I should spare us both from the FPS.
Anyway, I succeed in adding 3 lights before it was just to hard for my poor GPU to move the camera at all. I need an upgrade urgently.

The only thing was that I got some artifacts on the shadows, just don't know if it's something expected due to the oldness of my GPU.

Artifacts such as:
- pixelized shadows, not "smooth" but more like "rough PCF"? I know about this - I still need to add manual bilinear filtering. The idea is that you need a bilinear filter on the floating point textures, and only recent (GF6000+, HD2000+) cards can do that.
- "wrong" shadows? That's probably your card falling back to byte-based textures if it can't support floating point textures. You can't really store both depth and depth² correctly in a byte texture.

[dEspadas]

Artifacts such as:
- pixelized shadows, not "smooth" but more like "rough PCF"? I know about this - I still need to add manual bilinear filtering. The idea is that you need a bilinear filter on the floating point textures, and only recent (GF6000+, HD2000+) cards can do that.
- "wrong" shadows? That's probably your card falling back to byte-based textures if it can't support floating point textures. You can't really store both depth and depth² correctly in a byte texture.

Hmmm, I would say "Yep" to both. If you like i can post a screenshot, but I think you already know the issues.

Next week I will test it on a 7600GS also, I want to see it runs a little more smoothly.

[pjcast]

Heh, I got it to compile & run on a MacBook Pro (Radeon X1600), and while it runs fast, there are no shadows and rendering looks a little distorted. Unfortunately, I'm not up to speed on shaders, so not sure where to look

(Only required some minor changes to read media path out of application bundle instead of relative path as before). As well as setting project settings.

[pjcast]

And, to show some of the rendering issues:


This is with pressing space a few times to light up the level, and turning off flash light. With the flash light lamp thingy on, there was a slighty different artifiact like some green freckles. I had captured a video, but was 80MB and I didn't want to upload or grab tools to reencode on the Mac.

[nullsquared]

And, to show some of the rendering issues:


This is with pressing space a few times to light up the level, and turning off flash light. With the flash light lamp thingy on, there was a slighty different artifiact like some green freckles. I had captured a video, but was 80MB and I didn't want to upload or grab tools to reencode on the Mac.

Woah! Hm. Looks like the shadow texture is incorrectly sampled/rendered. Can you show me a screen shot of what it looks like with 1 shadowing light?

[pjcast]

This is the demo just starting off (with just flash light):


This is after adding one light:


This is after backing up a little bit:

[nullsquared]

This is the demo just starting off (with just flash light):


This is after adding one light:


This is after backing up a little bit:

Yup, looks like some kind of shadow map problem. Can you check the format of the shadow textures Ogre makes? It almost looks like you're not getting the type of texture you're asking for.

Something to try: what happens if you comment "btex2D_rg" and uncomment "tex2D" in the shadow() function, where it says "float2 moments =" (in diffuse.cg)? This'll stop the 3x3 blur of the shadow map, which might be causing some type of problem. Also, try switching 00diffuse.material from bilinear filtering to none filtering for the shadow map texture unit. X1600s don't support bilinear floating point filtering either way.

[Vectrex]

runs great on my 8800GT (about 70 fps with all lights on and 2048 sm), but when anti-aliasing is on (8x) it goes down to 20-30. In fact it doesn't matter what the shadowmap res is, it's still 30, even at 64x64. Whereas a low shadowmap res speeds things up without AA.
I assume something to do with fill-rate?

[nullsquared]

runs great on my 8800GT (about 70 fps with all lights on and 2048 sm), but when anti-aliasing is on (8x) it goes down to 20-30. In fact it doesn't matter what the shadowmap res is, it's still 30, even at 64x64. Whereas a low shadowmap res speeds things up without AA.
I assume something to do with fill-rate?

With more FSAA you're basically rendering to a framebuffer that's N times bigger than your screen resolution - meaning, you have to process N times more pixels for the lighting shader (done completely per-pixel if you look in diffuse.cg). Since the shadow map stays a fixed resolution, it doesn't really have much to do with the AA.

[Angus5]

This should be one of the shadow techniques like "setShadowTechnique(SHADOWTYPE_TEXTURE_SOFT);" or something.

[nullsquared]

This should be one of the shadow techniques like "setShadowTechnique(SHADOWTYPE_TEXTURE_SOFT);" or something.

I was actually thinking of that myself, but more like a plugin rather than integrated. Why? Because it's not that simple. The usual Ogre texture shadows are projected, and easily mixed into the fixed function pipeline. However, with these, you need shaders. And your lighting shaders need to manually accept the shadow map and do the shadow themselves. Of course, this is relatively simple since I put all of the shadowing code in a simple "shadow()" function. However, there are still things you need to take into consideration, such as passing in texture_viewproj_matrix, inverse_texture_size, and so on.

[Angus5]

When I thought of making soft shadows (just a theory), I thought a way to do it was to cast the shadow and then cast another, lighter shadow that's a tiny bit bigger. Does that make sense?

[jjp]

What you could do is to vary the position of each light source a few times and render a shadow map for every variation. But that means the shadow for each light will cost a lot more for a reasonable penumbra effect. And it leads to banding artifacts.

[nullsquared]

What you could do is to vary the position of each light source a few times and render a shadow map for every variation. But that means the shadow for each light will cost a lot more for a reasonable penumbra effect. And it leads to banding artifacts.

That's what F.E.A.R. did with it's stencil based "soft" shadows.
- extremely slow, at least on my machine
- extremely ugly at the same time
With shadow mapping there are so many efficient ways to make soft shadows (VSM, implemented in this demo, being one of the fastest), there's no point in "wiggled" shadows.

[sinbad]

This should be one of the shadow techniques like "setShadowTechnique(SHADOWTYPE_TEXTURE_SOFT);" or something.

No - this technique is just a use of existing features in Ogre, with some shaders. It's not a separate technique.

[quantum]

It even run on my fx5500 without artifacts(it crashed before i updated the drivers) at about 5-6 fps but once I start to add lights the fps goes trough the floor.

[twilight17]

Hey Nullsquared.. are you Agi_Shi from Irrlicht Forums?
and also
Agi_Shi from Newton forums?

[nullsquared]

Hey Nullsquared.. are you Agi_Shi from Irrlicht Forums?
and also
Agi_Shi from Newton forums?

That'd be me. I know, I sometimes behave like an a55 on the Irrlicht forums

[twilight17]

Hey Nullsquared.. are you Agi_Shi from Irrlicht Forums?
and also
Agi_Shi from Newton forums?

That'd be me. I know, I sometimes behave like an a55 on the Irrlicht forums

Ahh lol, I see. xD

[eugen]

is this technique supporting alpha based transparency shdows for casters?

[nullsquared]

is this technique supporting alpha based transparency shdows for casters?

Not out of the box.
- alpha rejection would be relatively simple
- alpha blending would be relatively the opposite of the simple. The thing with this, is that one object might modulate the colour of the shadow, but another occlude it. So we'd need 2 layers of shadow maps. But what if we had 2 transparent objects and 1 complete occluder? That's 3 layers. Not to mention that we'd need some heavy-a55 compression of the right colours into the floating point textures, unless we make them from RGB to RGBA.

[mklann]

Hi all,

thanks for this very interesting contribution! I tried the demo and got 70+ fps for a scene with about 200k polygons on my notebook with Quadro FX 570M.

I have three questions though, maybe because I know very little about shaders.

1) When I tried the scene with my own mesh, self-shadowing worked for the flash-light. But when I hit space to create a light at some location, self-shadowing did not work for this light. I also noticed that some surfaces of the mesh received light although they should be shadowed.

I am wondering whether the mesh has to have certain properties to work with this shader?

2) I noticed that when you get very close to a wall, the spot does not stay in the centre (that is where the flash light is pointed at) but wanders off to a corner of the screen. Is that supposed to be like that?

3) We are already using shaders for our models that work with normal and specular maps. What's the best way to combine existing shaders with this one? As I said, I know little about shaders. Is there a way to chain them? Or would we have to extend every shader we might use with the code from this one?

Thanks a lot!

[nullsquared]

Hi all,

thanks for this very interesting contribution! I tried the demo and got 70+ fps for a scene with about 200k polygons on my notebook with Quadro FX 570M.

I have three questions though, maybe because I know very little about shaders.

1) When I tried the scene with my own mesh, self-shadowing worked for the flash-light. But when I hit space to create a light at some location, self-shadowing did not work for this light. I also noticed that some surfaces of the mesh received light although they should be shadowed.

I am wondering whether the mesh has to have certain properties to work with this shader?

Many factors can result in this... What unit scale is your model? (centimeters/meters/feet/etc.?) It shouldn't really matter, but I've always gotten the best results with models in meters. How complex was it? What was your shadow map resolution? This is really the most basic of basic variance shadow mapping - while it looks really neat and is quite scalable, it doesn't work everywhere . There's lots of extensions these days, layered variance shadow maps, for example.

2) I noticed that when you get very close to a wall, the spot does not stay in the centre (that is where the flash light is pointed at) but wanders off to a corner of the screen. Is that supposed to be like that?

If you look at the main.cpp file and handleScene(), you'll notice I always offset the flash light a bit to the lower right of the camera. Otherwise, the shadows wouldn't be visible if the light was 100% matched up with the camera - notice how the shadows of the flash light are always to the left, since it's offset to the right. And this results in the light going off into the corner when up close.

3) We are already using shaders for our models that work with normal and specular maps. What's the best way to combine existing shaders with this one? As I said, I know little about shaders. Is there a way to chain them? Or would we have to extend every shader we might use with the code from this one?

It shouldn't be too hard. You need to modify your material files to pull in a shadow texture (content_type shadow), just as the demo shows. Then you need to make sure each shader gets the right parameters for the shadowing... after that, it's just a simple matter of copying shadow(...) (and btex2D_rg(...), if used) and modulating your final light be whatever shadow(...) returns.