[SOLVED] Extracting pixel's worldspace position

[devsh]

BlindSide something must be wrong both with my method and yours, when I ran checks today to check where the worldspace Y coord plane was... it was somehow curved using both methods. My camera position is absolute and so should be my frustum corners

I think to be spot on accurate i will have to go back to the matrix inverse idea... but I have no clue whether to inverse after View and Proj have been multiplied or each one before. I have no clue how to do the whole process backwards. Could someone give me an example or a step by step... please this is an exceptional situation and I hope you will understand me asking people to do something "for me"

[Nadro]

In my Deferred Shading I use method frustum corners, BlindSide tell You how it work. This is very good solution and easy to implementation. But this is other solution:

Code: Select all

GBuffer.x = length(PositionInViewSpace);

and in lighting stage:

Code: Select all

float3 EyeVec = float3(Position.x * AspectRation,Position.y, InvertedTanHalfFov);
float3 NewPosition = normalize(EyeVec) * GBuffer.x;

So You can also try with this method

[devsh]

I have tried the frustum corner method and it doesn't work as accurately as I would like. So I need to use matrix (inverted)

[devsh]

are frustrum far plane coords that you get from camera->getFrustum()->getFarLeftUp() etc. ABSOLUTE POSITION or RELATIVE TO SOMETHING like camera position or camera parent position???

cause that might cause a problem (the camera has a parent).

[devsh]

ok I am back to matrixes... how do I recontstruct screenspace coords without having the .w value handy?

[devsh]

on the camera Rays method... could a bizzare near value gently caress everything up?

EDIT:

Well basically I know why the matrix method does not work and why the camera ray does not work. This is kind of thanks to BLindSide's depth map algortihm

lets say I have 40000 far value and the pixel.z is at 19743

float depth pos.z/MaxD
;
float mulDepth = depth * 256.0 + 2.0;

float flooredDepth = floor(mulDepth);

gl_FragColor = vec4(flooredDepth / 256.0, mulDepth - flooredDepth, 0.0, 0.0);

turns into

depth= 0.493575;
mulDepth = 0.493575 * 256.0 + 2.0;
flooredDepth = 128; // 128.3552 rounded down by floor()

gl_FragColor = vec4(0.5, 0.3552, 0.0, 0.0);



And here is where the problem occurs... blindSide and so did I used the method he made up for unpacking this thing. Fortunately it gave values above 1.0 and that was when I realized



float getDepthAt(vec2 coords)

{

vec4 texDepth = texture2D(DepthMapSampler, coords);

float extractedDepth = (texDepth.r + texDepth.g / 256.0);

return extractedDepth;

}

ok then lets go through it

texDepth = vec4(0.5, 0.3552, 0.0, 0.0);
extractedDepth = 0.5 + 0.3552/256 = 0.5013875;

So the thing simply does not work and we get bugs

0.493575 != 0.5013875

Just to show you the significance, after multiplying by the farValue.. you get

19743 (the correct one) --->>comes out as->> 20055.5

WITH AN ACCURACY of ~312.5

I think the moral is, just because someone is the king of effects... You shouldn't use their formulas like bible.

[devsh]

BitPlane: This is significant and I think It needs a post... not an edit. If you think otherwise, please do not delete. I will merge with previous post, just let me know.

Well I have reworked the equation.

First of all, I need to say that this is no personal attack on blindside.

What BlindSide had seemed to get wrong as well is that in a shader when colors are clamped 0 to 1, there are 254 values in between. when you want to go from 8 bit integer to a float you divide by 255 and not 256. This is because 1*256 equals 256 which is outside of the range of unsigned 8bit.

well as it goes for unpacking the equation is almost the same

loat getDepthAt(vec2 coords)

{

vec4 texDepth = texture2D(DepthMapSampler, coords);

float extractedDepth = (texDepth.r + texDepth.g / 255.0); // changed from 256 to 255

return extractedDepth;

}

But the packing is slightly different

float depth = pos.z/MaxD;
float mulDepth = floor(depth*255.0)/255.0;

gl_FragColor = vec4( mulDepth, (depth-mulDepth)*255.0, 0.0, 0.0);



Ok then so lets go through the previous example

lets say I have 40000 far value and the pixel.z is at 19743

float depth = 0.493575;
float mulDepth = 0.490196078;

gl_FragColor = vec4( 0.490196078, 0.86162511, 0.0, 0.0);

Unpacking



float getDepthAt(vec2 coords)

{

vec4 texDepth = texture2D(DepthMapSampler, coords);

float extractedDepth = (0.493575); // changed from 256 to 255

return extractedDepth;

}


So as you see 0.493575*40000=19743

the blindside mistake is gone.. although my algorithm will not be as perfect because the floats get rounded to the nearest 0.003922

but I am expecting an accuracy of ~0.61

I have already tested the algorithm with my water and a certain bug related to depth comparison is gone

[hybrid]

BitPlane: This is significant and I think It needs a post... not an edit. If you think otherwise, please do not delete. I will merge with previous post, just let me know.

(Just in case you wonder why his goes public: Please reply to a PM if you want to keep things private)
Don't know why you assume it was from bitplane, but the PM was from me (a least one in case you got more then one on ths issue )
Feel free to post huge things, which have significant information, in a new thread. When being unsure if your new post has not enough significance (or in case you don't know what significance is), just edit your last post, you'll be on the safe side then. But don't abuse our forum as your private blog. This will lead to immediate deletion.

[BlindSide]

Thanks devsh, duly noted. The thread title is bit harsh though don't you think?

Btw you can use 32-bit depth packing if you want, theres code for it here: http://www.gamedev.net/community/forums ... ID=3054958

I still find there are artifacts with it though. Now that Irrlicht has FP rendertargets why not just use those?