Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

Point Lights Issue ( reconstructing position from logarithmic depth )

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 riuthamus   Moderators   -  Reputation: 5606


Posted 30 August 2012 - 11:12 PM

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.


#2 Steve_Segreto   Crossbones+   -  Reputation: 1539


Posted 30 August 2012 - 11:42 PM

The point light in Catalin Zima's blog worked for me. http://www.catalinzima.com/tutorials/deferred-rendering-in-xna/

#3 riuthamus   Moderators   -  Reputation: 5606


Posted 30 August 2012 - 11:49 PM

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! Posted Image

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

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, 30 August 2012 - 11:52 PM.

#4 Hodgman   Moderators   -  Reputation: 30938


Posted 31 August 2012 - 12:28 AM

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 Posted Image

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

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

Edited by Hodgman, 31 August 2012 - 12:29 AM.

#5 riuthamus   Moderators   -  Reputation: 5606


Posted 31 August 2012 - 02:31 AM

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!

#6 Telanor   Members   -  Reputation: 1346


Posted 31 August 2012 - 03:51 PM

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:
RuinValor 2012-08-31 17-49-01-90.png

#7 riuthamus   Moderators   -  Reputation: 5606


Posted 22 December 2012 - 12:10 AM

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.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.