Another soft shadows demo

[Humus]

I got another soft shadows demo up. It's fully dynamic this time. I also combine the dynamic lighting with lightmapping for static lights.

http://www.humus.ca/

 

[pat777]

I got another soft shadows demo up. It's fully dynamic this time. I also combine the dynamic lighting with lightmapping for static lights.

http://www.humus.ca/

That looks great. This is anotehr great demo from you. I wish it would be possible to create dynamic indirect lighting in real-time with area light sources.

 

[wireframe]

I will assume that it is nice as always. I say "assume" because once again it does not work correctly on Nvidia hardware (6800) out-of-the-box. This is getting me worried as I was hoping standards would be standards and I am working on the assumption that your demos, although lovely, are not tweaked to the core for performance where issues may arise due to tricks and hacks.

With dynamic lights enabled I see the light source and what looks to be light maps. These are essentially squares/boxes showing the light gradients. Disabling dynamic lighting brings back the actual stone and wood textures, but things become very uninteresting.

I will, of course, congratulate you again and thank you for yet another great demo once it has been fixed to work on 6800 series hardware

 

[Scali]

Could you tell a bit more about how it works exactly?
After browsing through the shaders a bit, it looks like you are storing extra info in the shadowmap, and during the lighting pass, you take 10 extra samples from the shadowmap, with slight displacements, which are weighted on the difference in distance to the first sample.
But I am not sure if I get the whole idea behind this.

 

[Humus]

Ok, first I render the depth map normally. Then I render the shadow as they would appear normally on the screen to a screen sized texture. Along with the shadow info stored in .x I also set .y to 1 to cut down the instruction count in the inner loop in the main lighting shader, and the depth in the .w component. In the main lighting shader I first grab the center sample. Then I take 10 other samples and for each sample I check the depth against the center sample. If the depth difference is too large it won't contribute to the final color. This to avoid shadows or light leaking over from the background or foreground close to edges in the scene.

 

[Humus]

I will assume that it is nice as always. I say "assume" because once again it does not work correctly on Nvidia hardware (6800) out-of-the-box. This is getting me worried as I was hoping standards would be standards and I am working on the assumption that your demos, although lovely, are not tweaked to the core for performance where issues may arise due to tricks and hacks.

With dynamic lights enabled I see the light source and what looks to be light maps. These are essentially squares/boxes showing the light gradients. Disabling dynamic lighting brings back the actual stone and wood textures, but things become very uninteresting.

I will, of course, congratulate you again and thank you for yet another great demo once it has been fixed to work on 6800 series hardware

Do the static lights work properly? Just the dynamic light that's broken?

 

[Scali]

Ah right, so the 'shadowmap' used in the lighting shader is actually in screenspace, that part escaped me at first. I didn't know why there was a cubemap used in the shadowshader, but that makes sense aswell now, that IS the actual shadowmap I suppose. And the shadowshader creates the screenspace shadowmap with a boolean value for each pixel whether it is in shadow or not, and the distance to the lightsource.
So if I understand correctly, it is a screenspace blur of 10 neighbours that are near in light-distance enough to be considered shadows on the same surface.
The x-coordinate will contain the sum of weights, the y-coordinate the nr of samples included in the sum.
Makes sense now.

Oh, one more question... The pixelshaders are 2.0, but I see you use the centroid suffix. Is this because the Radeon cards actually support it, even though according to the SDK docs, it is a ps_3_0 feature?

(and this is probably no surprise, but everything seemed to work fine on my Radeon 9600Pro).

 

[Mendel]

Do the static lights work properly? Just the dynamic light that's broken?

On my 6800 GT, yes. static lights work once the dynamic lights have been disabled. If the dynamic lights are enabled, the screen is an awful mess with moving gray boxes

 

[Humus]

Ah right, so the 'shadowmap' used in the lighting shader is actually in screenspace, that part escaped me at first. I didn't know why there was a cubemap used in the shadowshader, but that makes sense aswell now, that IS the actual shadowmap I suppose. And the shadowshader creates the screenspace shadowmap with a boolean value for each pixel whether it is in shadow or not, and the distance to the lightsource.
So if I understand correctly, it is a screenspace blur of 10 neighbours that are near in light-distance enough to be considered shadows on the same surface.
The x-coordinate will contain the sum of weights, the y-coordinate the nr of samples included in the sum.

Correct.

Oh, one more question... The pixelshaders are 2.0, but I see you use the centroid suffix. Is this because the Radeon cards actually support it, even though according to the SDK docs, it is a ps_3_0 feature?

(and this is probably no surprise, but everything seemed to work fine on my Radeon 9600Pro).

Hmm, good question. Didn't even think of that, but you're right. The docs put it under ps3.0. But then again, it has been supported on the whole R300 range hardware, and it apparently makes a difference in this demo, so it works fine under ps2.0. And checking with fxc it seems to be in order too:

ps_2_0
def c11, 0.000500000024, 1, 2, -1
dcl_centroid t0.xy
...
...

I guess MS allows it but doesn't require it on ps2.0 hardware.

 

[Humus]

On my 6800 GT, yes. static lights work once the dynamic lights have been disabled. If the dynamic lights are enabled, the screen is an awful mess with moving gray boxes

Hmm, I'll take a look at that tomorrow and see if I figure something out. Bedtime now ...

 

[DeanoC]

centroid was promoted(demoted?) to ps 2.0 with Dx9.0c. Technically it wasn't valid before that but the instruction stream had a space for the bit, so its been effectively there since Dx9.0.

 

[Scali]

centroid was promoted(demoted?) to ps 2.0 with Dx9.0c. Technically it wasn't valid before that but the instruction stream had a space for the bit, so its been effectively there since Dx9.0.

Ah right. But I checked the DX9.0c docs, and it doesn't actually mention this, so I wasn't aware that it would work.

Complete text from DX9.0c SDK docs:

Centroid
Centroid is an optional instruction modifier (ps_3_0 and above) that modifies the way that sampling locations are altered when multisampling. Centroid clamps the attribute interpolation to the range of the attribute across the primitive, when the multisample pixel center is not covered by the primitive. Gradients computed from such data are not guaranteed to be accurate. Take care when an attribute marked with _centroid is used for texture sampling. Normally the evaluation is performed at the pixel center. Any Input Color Register (v#) declared with a _color* usage will automatically have _centroid applied implicitly.

 

[Richard]

Humus, I see a reasonable amount of banding at the edge of the dynamic shadows, otherwise it's a cool demo.

Any news on that HumusMark?

 

[Ostsol]

8)

Any news on that HumusMark?

Eh. . . Unless Humus gets a NVidia card, I wouldn't bother asking. . . Until that happens, the amount of bitching and accusations of bias from the NVidia fanboys would render any such benchmark quite useless. A benchmark can only be as useful as it is accepted.

 

[loekf2]

Do the static lights work properly? Just the dynamic light that's broken?

On my 6800 GT, yes. static lights work once the dynamic lights have been disabled. If the dynamic lights are enabled, the screen is an awful mess with moving gray boxes

In fact I have a similar issue on my 5900XT. Just a blur of grey
boxes. Didn't try any setting, just ran the executable.

(I'm running XP SP2, so DX 9.0c on my machine)

 

[Bludd]

Nice demo, Humus.

Works flawlessly on my R9800 with 4.9 Cats

 

[sonix666]

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.

 

[Humus]

Humus, I see a reasonable amount of banding at the edge of the dynamic shadows, otherwise it's a cool demo.

Well, to get it smoother you'd need more samples, or another pass to blur the blur. It would be a good deal slower in both cases.

Any news on that HumusMark?

Well, I did finally add benchmark mode into the framework recently. I essentially just ripped the old code from the old framework and put it into the new framework. Didn't recompile any old demo with this though, but it should work in this demo at least.
http://www.humus.ca/3D/benchmark.html

 

[Humus]

In fact I have a similar issue on my 5900XT. Just a blur of grey
boxes. Didn't try any setting, just ran the executable.

(I'm running XP SP2, so DX 9.0c on my machine)

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.

 

[AlNom]

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.

So, coding for (apparently) a more general user base, you'd have to go with R16F? (assuming this works)

How much different is it on Radeon cards, then, if at all