Sign in to follow this  
xycsoscyx

Deferred Shading and Depth Reconstruction

Recommended Posts

Sadly, it seems like a lot of the threads on this are old, so I opted to open a new topic about it. I'm working on deferred rendering currently, and I wanted to be able to use the trick to get position from the depth value. I had this working using this method:
// Calculate Depth
Project = mul(Position, Transform);
Depth = Project.z / Project.w;
// Calculate Position
Project.xy = mathamagical;
Project.z = Depth;
Position = mul(Project, InvTransform);
The problem is that this creates the extra matrix multiplication each time I want to reconstruct the position (and the mathamgical part for calculating the XY based on the overlay texture coordinates is annoying as well and adds extra code). Instead of this, I opted to use the linear depth method:
// Calculate Depth
ViewSpace = mul(Position, View);
Depth = ViewSpace.z / FarClip
// Calculate Position
Position = ((ViewDir * Depth) + CameraPosition);
This works fine if my camera is not tilted (the rotation is the identity matrix), but if I try to turn, my lighting turns with it. Here's some screenshots: Correct, Wonky. I'm using code that MJP posted in another thread to calculate the corners of my far frustum plane, then passing those in as texture coordinates for my ViewDir value. Anyone have any idea why it's off like this? EDIT: Here's two screens showing the positions from the above images: Correct, Wonky. You can see that the values are literally turning with the camera, but I don't understand why (I assume I have to adjust my frustum corners perhaps?). [Edited by - xycsoscyx on December 31, 2007 3:46:29 PM]

Share this post


Link to post
Share on other sites
It would appear that ViewDir is in view-space (which means it doesn't change when you rotate the camera), when it should be in world-space (so that it does change when you rotate the camera). Try multiplying it by the inverse view matrix and see if that helps.

Share this post


Link to post
Share on other sites
Indeed, any code I posted would have had the corners of the view frustum (ViewDir) in view space with the goal of calculating the pixel's view-space position rather than world-space. Making sure those frustum coordinates are in world-space should do the trick.

Share this post


Link to post
Share on other sites
I had actually assumed that already, since all of your examples on threads worked in view space. I tried multiplying the frustum corners by my inverse view matrix (which is just the camera objects rotation/translation matrix), but things are still off (things seem to still tilt a bit when I rotate the camera, which means something is still off a bit).

EDIT: By off, I mean that things are coming together a bit, but it's still not right. The final X coordinate is close, but it moves a bit when I rotate my camera (turning 45 degrees turns the X position just a little, but it always stays mostly right). The Y coordinate still seems to remain view dependant (if I tilt up, all the positions tilt up too). The Z coordinate seems to be fine, it looks correct and stays in place.

[Edited by - xycsoscyx on January 2, 2008 2:06:47 PM]

Share this post


Link to post
Share on other sites
I have the exact same problem. I also tried multiplying with inverse view matrix and a bunch of other stuff, without luck. I guess I can't understand whats really wrong :(

I calculate the frustum coords the same way you are. From this thread:

http://www.lighthouse3d.com/opengl/viewfrustum/index.php?defvf

But this code does calculate the frustum coords in world coordinates since it offsets the camera position to it. Since the light doesn't follow the camera translation, but only the rotation, the translation ought to be in world space, correct? I tried to multiply with only the inverse rotation of camera but that didn't work either...

Did you solve this problem? I'll look at my frustum coords some day later, when I'm not so busy at work.

Cheers

Share this post


Link to post
Share on other sites
Had a little time to spare and I solved it now. It was a very embarrising error - my vertex buffer was not set as D3DUSAGE_DYNAMIC and D3DPOOL_DEFAULT, so it was only the first 4 frustum far plane coords that made it to the shader. No wonder it looked like it did...

Well it works now and it's like MJP and Zipster said - make sure your frustum coords are in the correct space - AND make sure you update your frustum coords :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this