Variance Shadow Maps Demo (D3D10)

[gjaegy]

Hey, thanks for your answer Andy, very useful as usual.

I have it working now, and even understand it

Now, it costs me 2 additional G-Buffer components, but I guess I can live with that. Actually I don't see any other option...

[EDIT] And yes, I did ensure the 2x2 quads were using the same slice. I have now commented the code out, in the deferred pipeline. It makes sense

 

[Andrew Lauritzen]

Now, it costs me 2 additional G-Buffer components, but I guess I can live with that. Actually I don't see any other option...

Indeed, there are other ways to hack it if you want, but those two values are useful for other stuff too. Like when you go to add deferred MSAA they're incredibly useful for determining surface connectivity

 

[gjaegy]

do you mean FXAA or MLAA or SRAA algorithm ?

those are the next ones on my task list with SSAO and transparent objects management.

I have started to read the long 30+ pages topic, but i think i will simply choose FXAA and see how it performs.

 

[Andrew Lauritzen]

do you mean FXAA or MLAA or SRAA algorithm ?

No I mean real deferred MSAA with all it's multifrequency shading glory. A la Battlefield 3 or http://visual-computing.intel-research.net/art/publications/deferred_rendering/. One step in the algorithm is identifying pixels that form continuous surfaces and thus can be shaded at lower frequencies, a task for which the depth derivatives are very useful.

Obviously for screen-space reconstruction techniques (FXAA,MLAA,etc) it doesn't matter.

 

[Humus]

However, the viewspace position is reconstructed using the linear view space depth, which is read from the G-Buffer in the PS.

Hence, the texture coordinates derivatives are not correct.

I am pretty sure I have to manually compute them, however I have no idea how to proceed.

Could anybody help me ?

Thanks,
Greg

[EDIT]:
I found some interesting method here http://visual-computing.intel-research.net/art/publications/sdsm/ (Andy is everywhere )

I implemented a screen-space derivative reconstruction thingy in my Volume Roads demo. It might be useful for you too.

http://www.humus.name/index.php?page=3D&ID=84

 

[gjaegy]

Hi Humus,

sorry to re-activate such an old post. I had to go back to this for some reason.

I am now reconstructing the depth derivates in the pixel shader, and had a look at your volume roads demo.

However, there is something I don't (fully) understand. In your shader, you have the following code:

// Find suitable neighbor screen positions in x and y so we can compute proper gradients
// Select based on the smallest different in depth
float4 screen_pos_x, screen_pos_y;
if (abs(dx0 - d) < abs(dx1 - d))
	screen_pos_x = float4(In.position.xy + float2(-1.0f, 0.0f), dx0, 1.0f);
else
	screen_pos_x = float4(In.position.xy + float2( 1.0f, 0.0f), dx1, 1.0f);

if (abs(dy0 - d) < abs(dy1 - d))
	screen_pos_y = float4(In.position.xy + float2(0.0f, -1.0f), dy0, 1.0f);
else
	screen_pos_y = float4(In.position.xy + float2(0.0f,  1.0f), dy1, 1.0f);

I understand you are doing this to ensure derivates get computed on a continuous surface (as long as this is possible though your comparaison algorithm).

However, I thought the derivatives, when handled automatically, were computed on a 2x2 block. Which would mean that they would always be computed using the second part of the code above ("else" branch).

Is that right ? Does that mean that your code actually gives better results than the standard hardware gradients computations ?

Cheers,
Greg

 

[homerdog]

Humus is a rare sight these days you might want to send him a PM.