• Advertisement
Sign in to follow this  

Point Lights Issue ( reconstructing position from logarithmic depth )

This topic is 1858 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

We are having a problem with our point lights not working. Our current setup is a deferred rendering for lighting. Now somebody can correct me if I am wrong but this is how we are doing it:

  • We render stuff and our colors are recorded on a color RT
  • Normals on another RT
  • Depth on another RT ( our depth is logarithmic )

    When we render the point lights they need to read the depth RT so they can use the depth to calculate the world position of the pixel and then we can do the lighting calculations.

    Our problem is we have no way of reversing that logarithmic depth at this point... any clues on how we could go about doing this? Or maybe there is a better way to handle the scenario all together. Thanks for your help in advance.

Share this post

Link to post
Share on other sites
hm... interesting okay ill give that a go. Thank you! any other advice people have is welcomed. We have a very nice fireball effect and I would like to add a point light to the process, that and we want lanterns! tongue.png

showed this to the coders and this was the response i got:

yea yea
that's what we used to set it up in the first place
its literally the only xna deferred tutorial[/quote]

Also note we are not using XNA, we are using SlimDX, not sure if that matters at this point. I guess the big issue is that we are using Log depth, and this tutorial and others are not. We are attempting to use log depth to create better precision... but not sure if that is the main reason as to why ours does not work when others have no issues. Edited by riuthamus

Share this post

Link to post
Share on other sites

Our problem is we have no way of reversing that logarithmic depth at this point..
You probably should have named your thread "reconstructing position from logarithmic depth" then wink.png

WolframAlpha can be useful for tasks like this.
e.g. assuming you're using the formula: [font=courier new,courier,monospace]depth = [/font][font=courier new,courier,monospace]log(c*originalZ + 1) / log(c*far + 1)[/font]
You can copy that into wolfram, and ask it to solve for z: http://www.wolframal...) ; solve for z
And it spits out [font=courier new,courier,monospace]originalZ = [/font][font=courier new,courier,monospace](pow(c*far+1,depth)-1)/c[/font]

I make no guarantees about the validity of this formula -- just giving you another tool to try ;) Edited by Hodgman

Share this post

Link to post
Share on other sites
If I use the formula that wolframalpha gives, it gives us a closer result then we were getting before but the position is still off by a bit. I debugged a pixel in PIX and the position came out to (101.089287, 618.003845, -55.915211, -105.442390). Our blocks are 10 units big. The pixel I was debugging should have had a value close to (0, 600, 0). The Y axis (our up axis) is pretty close, but the other 2 are off by a bit.

This is how the log depth is encoded in the gbuffer:

output.Position.z = log(0.001 * output.Position.z + 1) / log(0.001 * FarPlane + 1) * output.Position.w;

The vertex shader of the point light also adjusts the light's z position in the same way. And this is how the position is reconstructed in the light:

input.ScreenPosition.xy /= input.ScreenPosition.w;
float2 texCoord = 0.5f * (float2(input.ScreenPosition.x, -input.ScreenPosition.y) + 1);

//read depth
float depthVal = DepthMap.Sample(depthSampler, texCoord).r;
depthVal = (pow(0.001 * FarPlane + 1, depthVal) - 1) / 0.001;

//Compute screen-space position
float4 position = float4(input.ScreenPosition.xy, depthVal, 1.0f);

// transform to world space
position = mul(position, InvertViewProjection);
position /= position.w;

Every time I debug a pixel, the attenuation always equals 0 since the position it calculates is out of the lights range. This is what it ends up looking like:
[attachment=11022:RuinValor 2012-08-31 17-49-01-90.png]

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement