Lightmap Creation With Photon Mapping Issue
Author
I am coding a lightmap generator which uses photonmapping to get the lighting samples. The problem I am having is that all the photon mapping implementations return arbitrary floating point numbers that only give me an idea of how light or dark the the sample is relative to the total lightness or darkness of the map/geometry. Why is that a problem? Some maps are outside, meaning that they should be generally brighter, and some maps are just generally dark, meaning that there should really be no places where things are "bright."
What I have done is linearly interpolated the values so I get a value between 0 and 255, but the lightmaps that I am receiving as output are highly detailed-- I can definitely see the areas where the most light rays are striking the geometry. The problem is that this map is outside, and therefore I shouldn't be able to see the fine details because of the brightness of the sun.
I have one method that gave me satisfactory results. I scan the lightmap's lighting data (the floating point numbers calculated with the photon map) for the maximum value. Then I scale it by 0.85, and make any number greater than it equal to it, thus capping the lighting values. This gives me a much better (brighter) approximation. But I can't help but think that I have done or understood something wrong to find myself in this position.
So my question is this: is there a better, or 'right', way to do it?
hey
I don't have much to offer, but I thought this article about Exposure (The Exposure Function) may help.
cya
I don't have much to offer, but I thought this article about Exposure (The Exposure Function) may help.
cya
Author
Wow... that function actually does a surprising job of approximating the values, along with giving me one single variable to tune brightness. Pretty cool :) A note, though, is that his pseudo-code is wrong... should be:
This will probably work for me, but if there are any others with ideas or knowledge, please share. I would like to allow users many different methods for this.
~zf
return (1 - Exp(-(light*exposure))) * 255;This will probably work for me, but if there are any others with ideas or knowledge, please share. I would like to allow users many different methods for this.
~zf
I'm not sure I understand your problem exactly. Yes the data may have a high dynamic range, so 8-bits per component may not be enough to store them. You're probably better of using a 16 bit float per component, or something like that, and then you have to do tone mapping to dynamically adjust exposure depending on if the camera is indoors or outdoors.
Anyway, as for the "details" (I assume you mean that it looks "noisy"?) I can recommend doing a final gathering pass. I.e. store all the photons for the whole scene first like you're doing now, but then for each texel in the lightmap you shoot out N rays in a hemisphere (in a cosine distribution) and for each ray you look find all the photons within a certain distance of the intersection with the geometry, add all these up (and divide by N) to get an approximation of the total incoming light at each point which is proportional to the diffuse emission at that point (which is what you want to store in the lightmap). Not that these FG rays don't bounce. They just look to find a single light bounce, the light of which is produced by the preceeding photon mapping phase (and, any incandescent surfaces the ray may hit).
This smooths things out a bit. You look at it as doing the "final bounce" of the photon tracing "in reverse". So each point on the surface "looks up" and tries to find what other photons would shine light on it.
Anyway, as for the "details" (I assume you mean that it looks "noisy"?) I can recommend doing a final gathering pass. I.e. store all the photons for the whole scene first like you're doing now, but then for each texel in the lightmap you shoot out N rays in a hemisphere (in a cosine distribution) and for each ray you look find all the photons within a certain distance of the intersection with the geometry, add all these up (and divide by N) to get an approximation of the total incoming light at each point which is proportional to the diffuse emission at that point (which is what you want to store in the lightmap). Not that these FG rays don't bounce. They just look to find a single light bounce, the light of which is produced by the preceeding photon mapping phase (and, any incandescent surfaces the ray may hit).
This smooths things out a bit. You look at it as doing the "final bounce" of the photon tracing "in reverse". So each point on the surface "looks up" and tries to find what other photons would shine light on it.
Author
Actually sebastiansylvan, minus the final gathering, that's exactly how I do it, what with the float, and the tone mapping. Basically everytime a photon ray collided with the geometry, it would use the UV coordinates of the face to get the texel, and then add the power of the photon to a floating-point "map." I tried to use Reinhard tonemapping but it kept giving me values out of the bounds (0-255) and other general errors... So in the meantime I used a linear mapping which was awful.
Since that wasn't working, I moved to true photon mapping (with a KD-tree) hoping that it would make things easier... but it was no different from the previous approach, it still gave me floating point numbers to deal with.
To state the problem clearly: I need to be able to see two things; one, the sheer "brightness" of direct lighting of the sun. But also, in the dark areas I need to see how the color has bled onto surfaces instead of pure black or grayscale lighting. The problem is that the final images end up in grayscale because indirect lighting accounts for such a small amount of the data it's invisible.
I think I'll try using two photon maps... one for direct lighting (i.e. the first photon collision) and the second for every bounce after the first. Then I can use both in the final result and weight the indirect lighting as needed...
Overall, I have alot of questions that aren't addressed in any of the info I've read... for instance, what are appropriate values for the "power" components of a light? I've tried using RGB, and also RGB converted to floating point (255 = 1.0, 0 = 0.0)... I'm kind of just figuring it out as I go.
Since that wasn't working, I moved to true photon mapping (with a KD-tree) hoping that it would make things easier... but it was no different from the previous approach, it still gave me floating point numbers to deal with.
To state the problem clearly: I need to be able to see two things; one, the sheer "brightness" of direct lighting of the sun. But also, in the dark areas I need to see how the color has bled onto surfaces instead of pure black or grayscale lighting. The problem is that the final images end up in grayscale because indirect lighting accounts for such a small amount of the data it's invisible.
I think I'll try using two photon maps... one for direct lighting (i.e. the first photon collision) and the second for every bounce after the first. Then I can use both in the final result and weight the indirect lighting as needed...
Overall, I have alot of questions that aren't addressed in any of the info I've read... for instance, what are appropriate values for the "power" components of a light? I've tried using RGB, and also RGB converted to floating point (255 = 1.0, 0 = 0.0)... I'm kind of just figuring it out as I go.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
