Point Lights Issue ( reconstructing position from logarithmic depth )

Started by
5 comments, last by riuthamus 11 years, 3 months ago
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.
Advertisement
The point light in Catalin Zima's blog worked for me. http://www.catalinzima.com/tutorials/deferred-rendering-in-xna/
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

EDIT:
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.

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 ;)
Hm... thank you very much and if i can rename it, i will. I know on my ipforums you can if you are a thread owner.. but not sure how this one works. I will give it a good ol' college try!
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]

Hm... not sure if this is reviving a dead topic... but we never got an answer and have started development on this. If this is a dead topic please close it mod. I will make another.

This topic is closed to new replies.

Advertisement