XEffects - Reloaded - New Release (V 1.4)

[BlindSide]

btw i have done some research and found some really nice article about deffered lightning. but none about shadowing which is kinda making me believe that its not something u should do or maybe no one has simply done...or i'm to stupid to find it. anyway keep up the good work.

Yes I was almost about to say what you suggested was impossible, because you would need to see the scene from the cameras point of view with the shadow map projected from the light source's point of view for each light, because the whole point of shadowmapping is to shadow those points that have the wrong depth from your point of view based on the light source's projection.

But then I got to thinking, and I realized there definitely is a way. If you render the scene depth from the camera's point of view, you can interpolate between the 4 normals of the screenquad (That are pointing out into the scene) based on the screen's coordinates and shoot a ray into the scene, if you multiply the normalized direction of the ray by the screen space depth, tada!, you get the world position. This little trick was used by the crysis guys for things like SSAO etc (Don't think they used it for the shadows however.).

Anyway, we now have the world space pos, but how do we sample the projected shadow map texture at that position? Simple, just multiply that world space pos by the respective view and projections matrices (In the right order!), divide by W and scale, and hopefully, you will get the correct screen coordinates for the projected shadow map for that particular screen pixel!

This would be quite useful if you had alot of lights with highly tessalated geometry, it would avoid having to render them again and again. I think it would also avoid a few state changes like render target switches, etc, if you do it right.

One problem might be the matrix multiply per pixel, not sure how expensive this is but it might raise the instruction count a bit. I think for most practical situations however with multiple lights this technique will outperform the standard direct rendering.

Cheers

[FuzzYspo0N]

i love how the complex stuff seems easy when blindside explains lol,
blindside, did you get my other mail? you should reply slacker.

This is looking cool, i like the frames and responses im getting on :

iMac (running winXP) so its like :

Intel Core2 Duo @ 2.40 Ghz
2gb ram and a 24 inch running on a Mobility Radeon HD 2400 XT,
so its running nice and smooth for the most part.
DirectX :
Lowest settings : 100 fps
Highest settings : 20 fps

OpenGL :
Lowest settings ; is like 70 - 90 fps
Highest settings is about 5 - 15 fps

[BlindSide]

blindside, did you get my other mail? you should reply slacker.

Sorry Fuzzy Yeah I'm a slacker But I had my reasons this time, I'll reply in a exactly 3 days.

Intel Core2 Duo @ 2.40 Ghz
2gb ram and a 24 inch running on a Mobility Radeon HD 2400 XT,

Wow, we have this exact setup at uni, is it the one with the big screen and everything integrated into the flat panel casing with the dvd slot on the side?

My uni got like 2 rooms full of them (Like 50 pc's each) at the beginning of this year I think. When I first walked in I was like They are sweet machines.

[sudi]

One problem might be the matrix multiply per pixel, not sure how expensive this is but it might raise the instruction count a bit. I think for most practical situations however with multiple lights this technique will outperform the standard direct rendering.

I don't think this is neceesary. What if u render the 3d position of a pixel into the buffer and not only the depth. But thats just my idea....still experimenting with it.

[BlindSide]

I'm not sure if you read my post correctly Sudi. We can already decode the position from the depth using the intuitive screen quad ray technique. So if you render the positions you are kinda taking a step backwards in terms of performance, and not gaining anything else. The problem comes from using different viewProj matrices for each light source. You either render the entire scene each time with different viewProj matrices applied to the projective texturing or you do what I said.

Ok it can be a difficult concept to get your head around so I'll say it clearly:
The scene is RENDERED from the camera's point of view, but the shadow map is PROJECTED from the light source's point of view.

The problem comes with the second part.

[frostysnowman]

You are full of win Blindside. This will be of much help to me!

EDIT: I have a few problems with XEffects. Here is the code:

Code: Select all

	effectHandler* shaderHandler = new effectHandler(device, dimension2d<s32>(128,128), "DATA/SHADERS", 
		driver->getScreenSize());
	shaderHandler->setAmbientColor(SColor(255, 25, 25, 25));
	core::stringc shaderExt = (driver->getDriverType() == EDT_DIRECT3D9) ? ".hlsl" : ".glsl";
	//shaderHandler->addPostProcessingEffectFromFile(core::stringc("shaders/BlurHP") + shaderExt);
	//shaderHandler->addPostProcessingEffectFromFile(core::stringc("shaders/BlurVP") + shaderExt);
	shaderHandler->addPostProcessingEffectFromFile(core::stringc("DATA/SHADERS/BloomP") + shaderExt);
	shaderHandler->setClearColour(SColor(255,100,101,140));

In the irrlicht loop, I remember to call shaderHandler->update() instead of smgr->drawAll(); But- initially I had a problem where XEffects did not detect my GPU was not able to use PS_3_0 and VS_3_0, so I went into XEffects and find-replace-All to PS_2_a and VS_2_a. That compiled, but I think you should fix that bug where it doesn't seem to realize that I can't compile to 3_0. After that- I have a bug where I get the error message:

Error: Tried to set a render target texture which is bigger than the screen.

This error message only occurs when using the D3D9 driver. It doesn't make sense because I choose a render target from driver->getScreenSize(). My GPU is a NVIDIA GeForce Go 6400 however (I'm on a laptop), and you said that you had some problems with NVidia Cards. I set the dimensions to 512,512 like in the first example- but then everything looks sort of blurred because it's smaller than the actual screen size : /. I really hope that can get fixed because it seems D3D is faster for me than OPENGL.

[BlindSide]

Sorry, I did not take into account 2A or 2B compile targets, I'll add those in as backup to PS 3.0 when I have time.

This error message only occurs when using the D3D9 driver. It doesn't make sense because I choose a render target from driver->getScreenSize(). My GPU is a NVIDIA GeForce Go 6400 however (I'm on a laptop), and you said that you had some problems with NVidia Cards. I set the dimensions to 512,512 like in the first example- but then everything looks sort of blurred because it's smaller than the actual screen size : /. I really hope that can get fixed because it seems D3D is faster for me than OPENGL.

This is an Irrlicht limitation. The error message says "Error: Tried to set a render target texture which is bigger than the screen." but it actually means "Tried to set a rendertarget that is bigger than the screen and not a power of two.".

You should apply the vi-wer's large rtt patch and recompile Irrlicht if you this to work. There is also a simpler way if you can't get the patch to work, you can just disable the check in CD3D9Texture.cpp for a power-of-two size and this will allow you to create non^2 sized render targets (But not larger than the screen like if you applied the patch.).

Btw, I'm pretty damn sure all 6-series Geforce cards support Shader Model 3.0. Look it even says so on the NVidia website for the Geforce Go 6400. And I did NOT say I had problems with NVidia, I said I had problems with ATI cards under OPENGL, and you are using D3D so this issue is even more irrelevant .

Cheers, I hope someone uses this in a project somewhere lol.

[roelor]

@ my comp the best results are 512 x 512 texture and 16 x pbb (or something like that)

Open gl works fine.

[omaremad]

Nice work on the point lights.

One weird thing is your depth packing, are you storing the fractional part and the integer parts in separate components but using only 2 channels.

Code: Select all

return float4(flooredDepth / 256.0, (mulDepth - flooredDepth), 0.0, 0.0);

why not use the the full 32 bits

Code: Select all

// Packing a [0-1] float value into a 4D vector where each component will be a 8-bits integer
vec4 packFloatToVec4i(const float value)
{
   const vec4 bitSh = vec4(256.0 * 256.0 * 256.0, 256.0 * 256.0, 256.0, 1.0);
   const vec4 bitMsk = vec4(0.0, 1.0 / 256.0, 1.0 / 256.0, 1.0 / 256.0);
   vec4 res = fract(value * bitSh);
   res -= res.xxyz * bitMsk;
   return res;
}
 
// Unpacking a [0-1] float value from a 4D vector where each component was a 8-bits integer
float unpackFloatFromVec4i(const vec4 value)
{
   const vec4 bitSh = vec4(1.0 / (256.0 * 256.0 * 256.0), 1.0 / (256.0 * 256.0), 1.0 / 256.0, 1.0);
   return(dot(value, bitSh));
}

Then you get the precision from using two more components.

I know you know this because we discussed it before, i just found it strange you chose the 2 component solution.

[hollow]

Hi BlindSide,

the problem i reported about in the old XEffects thread is not occuring anymore (the ScreenQuad not being initialized properly). So this seems to be a very interesting postprocessing framework, we are currently implementing different effects.

Is there any possibility to read the z-buffer from the DepthSampler that is set in the Callback for post processing? I did not find code that would write z-buffer information to that texture.

Thanks again, awful work.

[BlindSide]

Thanks again, awful work.

Thanks ... no wait :S

Is there any possibility to read the z-buffer from the DepthSampler that is set in the Callback for post processing? I did not find code that would write z-buffer information to that texture.

Did you read the detailed comment in the header file for addPostProcessingEffect? It has detailed instructions on accessing the depthSampler. Don't forget to enable the depth pass using enableDepthPass and add nodes to the depth pass using addNodeToDepthPass (You have to add them here even if you added a shadow to them, the shadow depth pass is unrelated.).

Do you mind being more specific about your requirements? What kind of effect are you trying to achieve?

One weird thing is your depth packing, are you storing the fractional part and the integer parts in separate components but using only 2 channels.

Well I have my reasons. Don't forget my PS 2.0 compile target for 8 sample PCF is struggling to stay under 64 mathematic instructions, I already had to sacrifice a few things e.g Attenuation etc. The other reason is that I find 16-bit depth more than enough, storing 32-bits from a depthbuffer that could be either 16-bits or 24-bits is rather pointless. I could pack it to 24, that might be an idea for later.

The other reason I kept it 16 is because I was experimenting with VSM also, and you need to store the depth and the squared depth and 16-bit was accurate enough and allowed me to store 2 sets of depth in a RGBA8 pixel. Unfortunately it turns out storing it this way is equivalent to RG16 storage, which is not equivalent to RG16F, and using an integer format to the squared depth on NVidias results in horrible artifacts and the whole thing just plain not working (Apparently it works fine on ATIs, theres a discussion on this on the original VSM demo thread.). You can try it, just download the VSM demo and select RGBA16 instead of RGBA16F as the render target.

[omaremad]

The other reason is that I find 16-bit depth more than enough, storing 32-bits from a depthbuffer that could be either 16-bits or 24-bits is rather pointless. I could pack it to 24, that might be an idea for later.

Your GPU vertex unit runs at 32 bit always, you calculate the depth there, that means you have 32bits of real data, you are not really touching the depth buffer.

Since you are using an "integer" intermediate format its best if you linearise your depth data that is used for comparision; integers have a constant percision throughout all their range while a "projected depth" has all the percision at the near plane.

Anyway the VSM guys reccomend 32bit(beacuse of the squaring and the subsequent oprations on those values) and also reccomend the linear z(for consistent quality at diffrent distances)

The other reason I kept it 16 is because I was experimenting with VSM also, and you need to store the depth and the squared depth and 16-bit was accurate enough and allowed me to store 2 sets of depth in a RGBA8 pixel. Unfortunately it turns out storing it this way is equivalent to RG16 storage, which is not equivalent to RG16F, and using an integer format to the squared depth on NVidias results in horrible artifacts and the whole thing just plain not working (Apparently it works fine on ATIs, theres a discussion on this on the original VSM demo thread.).

squaring the depth will make the number smaller so having it in a 0-255 range is worse than having normal depth in this percision range, why not square the depth in the pixel shader after reading the normal depth? I think in their case they stored depth and depth^2 it beacuse they had a spare 2 components.

[BlindSide]

The other reason is that I find 16-bit depth more than enough, storing 32-bits from a depthbuffer that could be either 16-bits or 24-bits is rather pointless. I could pack it to 24, that might be an idea for later.

Your GPU vertex unit runs at 32 bit always, you calculate the depth there, that means you have 32bits of real data, you are not really touching the depth buffer.

Ah ... good point there.

Since you are using an "integer" intermediate format its best if you linearise your depth data that is used for comparision; integers have a constant percision throughout all their range while a "projected depth" has all the percision at the near plane.

By linearise you mean divide by W? I'll give that a try.

Anyway the VSM guys reccomend 32bit(beacuse of the squaring and the subsequent oprations on those values) and also reccomend the linear z(for consistent quality at diffrent distances)

VSM runs just fine on 16-bit floating point surfaces, and if I were to use 32-bits in Irrlicht I would either need to render to 2 textures which means MRT support or use a larger format, both of which may not be that hard to implement but I want to stick to vanilla Irrlicht for the availability of this wrapper.

squaring the depth will make the number smaller so having it in a 0-255 range is worse than having normal depth in this percision range, why not square the depth in the pixel shader after reading the normal depth? I think in their case they stored depth and depth^2 it beacuse they had a spare 2 components.

Yes squaring (<1) makes it smaller I'm sure the VSM guys et al didn't just do things "beacuse they had a spare 2 components.". The reason you need to specifically store the depth and the squared depth (The whole point of VSM!) is so that you can blur the shadow map in a post processing phase and gather the depth distribution (AKA Variance, from Variance Shadow Mapping) from the squared depth info.

Take 2 numbers, 5 and 10 for example, the average of these 2 numbers will be 7.5. Now square them each, we get 25 and 100, average them to get 62.5. The square root of 62.5 is 7.9~!

7.9 != 7.5!!!

If it is not clear by now, the VSM technique more or less relies on the difference between these two values (You square the current depth and compare it to the stored squared depth). I admit I don't fully understand the statistical significance of storing the depth distribution yet, but I know enough to tell you that you need 2 sets of data.

Btw, I'm flattered that you had time to look through my shader files, please save me the embaressment and don't examine the brdf, aniso etc shaders as I just copied and pasted those a few years ago from the nvidia site and haven't really touched them or found a use for them since. On the subject of brdf and aniso, have you looked into stuff like Oren Neyer yet?

[terier]

Here's how my render looks... strange artifacts.

http://img510.imageshack.us/my.php?image=renderad9.png

Any ideas on how to fix this?

[BlindSide]

Wow that is very pretty.

What you are seeing is a garbled version of the 16-bit encoded depth map (Hence the red/green bands). I can not help you without further information. I would like: DirectX/OpenGL, Did you run the demo directly or re-compile?, What settings did you choose at the start? and most importantly, what video card?