56 replies to this topic

[Alienizer]

I get it, and did it, thanks. But, now I get a very dull output, no shade or anything???

Isn't this like path tracing? except we query the photon map instead? So we have to shoot huge amount of secondary rays?

[Reedbeta]

Yeah, it is like path tracing for the first bounce back from the eye. But it should still be faster than path tracing since you use the photon map for all further bounces. BTW, I think the secondary ray samples can be co-stratified with pixel area, lens area etc. to reduce the total number of rays. I don't know why you'd get a "dull" output; if everything's working right, it should look the same as visualizing the photon map directly except for being a lot smoother.

[Alienizer]

Well, isn't suppose to be dull since we average indirect lighting on secondary rays? It's like every eye pixels are averaging say 128 rays from the photon map, so all of them will be about the same right? This is what I do (in somewhat pseudocode)...

for each eye pixel cast ray to scene and get closest hit {
for x = 1 to 128 {
from hit point, cast ray to scene and get photon at hit point
add photon color to total
}
total /= 128
add total to direct illumination ray and set eye pixel to it
}

[Reedbeta]

"Get photon at hit point" sounds suspicious to me. Photons are incoming light, remember, so at the secondary hit points you would need to search for photons and process them through the surface's BRDF to get the reflected light back toward the original hit point. Don't use photons as reflected light, which they aren't.

[Alienizer]

"get photon at hit point" is get all the photons in a radius at the hit point and average them. So I'm doing this wrong. What you are saying is, instead of averaging all the photons in the radius, I should treat each photons as if they were to hit the surface from which the secondary rays are from?

[Alienizer]

Let me correct what I say, you mean that for each secondary rays, I get all the photons in the radius at hit point, but for each photon I do the BRDF to see if it emit some light (mirror etc) or is totally absorbed (rusian roulette)? and then I add all those up and average them?

[Reedbeta]

Yes, treat each photon as if it's hitting that secondary surface and reflecting back toward the primary hit point. Therefore, multiply each photon by the BRDF evaluated using the direction from which the photon is coming and the direction toward the primary hitpoint. Then add those all up and divide by the area used in the photon search (converts the photons' flux to irradiance on the secondary surface, so the units will work out right and the returned value will be a radiance).

[Alienizer]

Works beautifully Reedbeta. Thank you so much, and thanks everyone else as well for helping me out and taking the time to explain. I really appreciate it.

[Alienizer]

Just a tech question. Is it correct to say that using the photon map directly (direct & indirect lighting, caustics and all) with billion and billions of photons would produce the perfect output as in real life?

[Reedbeta]

Yes, in the limit of very many photons it should produce a mathematically correct result. For it to be true to life of course requires also perfectly correct materials and scene modeling, etc.

Plus, real life has other things like dispersion, polarization, phosphorescence, fluorescence, nonlinear optics, and quantum phenomena that we hardly ever bother to model in computer graphics, because (in most conditions) we can't see them.

[Alienizer]

Yes of course, beside, a pixel can only display 256 shades of RGB so that alone is not even close to real life. But I should of ask it another way, can we use this as a reference image, meaning, use it to compare other style of render, like raytrace, path tracing and whatever, so for example, when making a raytracer, use the photon image to know how good the raytracer is?

[}:+()___ (Smile)]

It's not a good idea to use biased algorithm for reference image. And photon mapping even without final gathering is biased algorithm due to 3D blur of photon field. Better to use something like basic ray tracing with insanely large ray count instead.

[Reedbeta]

Smile - if you use so many photons that the blur radius is ~1 pixel, it should be ok for practical purposes.

Alternatively, use this.

[Alienizer]

}:+()___ (Smile), on 16 March 2012 - 09:29 PM, said:

It's not a good idea to use biased algorithm for reference image. And photon mapping even without final gathering is biased algorithm due to 3D blur of photon field. Better to use something like basic ray tracing with insanely large ray count instead.

But raytracing doesn't do caustics and color blending. Path tracing does not work well with very small emitters because the chance to hit one is little, but photon mapping should simulate real life light transport, it should even work for laser lights. And I was technicaly thinking that if I have trillions of photons (of course in a progressive manner) with a radius <1 should be like the real thing. Material has lots to do as well like Reedbeta said, but I would imagine that photon mapping is the way to go to use a reference no? I mean, if you let it run for a week, you should have all the dots blended in by then!

[Alienizer]

Reedbeta, on 16 March 2012 - 09:52 PM, said:

Smile - if you use so many photons that the blur radius is ~1 pixel, it should be ok for practical purposes.

Alternatively, use this.

Yes I've looked at the progressive photon mapping. Works great, but slowwwwww.

But what do you mean Reedbeta by "it should be ok for practical purposes"? It's not that good?

[Reedbeta]

I mean for practical use as a reference image to compare other renderers with. Even though technically any photon mapping technique with a finite number of photons is "biased" - well, real-world path traced images do not have an infinite number of samples either. The error can be made as low as you desire with either photon mapping or path tracing, by running with enough photons or enough samples, so I do not really see the point in calling out photon mapping as being biased, although by some particular technical definition, it is.

[Alienizer]

I see. But what exactly is "biased" and "unbiased" as far as a render goes? Isn't it just a saying or is there actual facts about them?

[Reedbeta]

Unbiased means that as you increase the number of samples taken, it will converge toward the mathematically correct answer. Biased means it converges toward something other than the mathematically correct answer, so some error is unavoidable no matter the number of samples taken. The terms derive from statistics where people speak of biased and unbiased "estimators", i.e. formulas for estimating some quantity based on limited data. Being biased or unbiased is a provable mathematical property of the estimator.

The trouble, IMO, is that when people speak about photon mapping renderers they count only the raytracing phase as being part of the estimator when they talk about bias or lack thereof. Once you create a photon map with a finite number of photons, the error (due to having only finitely many photons) is "baked in", and then raytracing an image using that photon map will converge not to the mathematically correct illumination in the scene, but to the illumination represented by the photon map, which has some error. That's why they say it is biased - even infinitely many samples in the raytracing part will not eliminate the error from the photon mapping part.

It seems silly to me to neglect that you can also turn up the number of photons as well as the number of samples, and make it converge to the correct answer that way. In other words, consider the estimator as including both the photon mapping phase and the raytracing phase. Then it's unbiased.

It's true that in the traditional form of photon mapping you must store the photons all in a data structure, so memory consumption grows with the number of photons, so you will eventually run out of space, but IMO that is not a good reason to leave the photon mapping part out of the estimator. In any case, with the progressive photon mapping technique you do not need to store all the photons so it is really unbiased by any reasonable definition and even some unreasonable ones.

[Alienizer]

oh I see! So then, a pure raytracer (no photons) is biased because of the incorrect result, even if it 'looks' good. A path tracer will most of the time be unbiased if it can reach the lights (if they are not point lights), and a path tracer with direct light sampling is half raytracer and half path tracer so it's also biased, and the method you told me about photon mapping for indirect illumination and raytrace for direct illumination is also biased.

So in other words, only photon mapping with a radius <1 per pixel is truly unbiased, and path tracing also (without point lights) in unbiased, the rest are all biased. So most raytracer's claimes to be unbiased (and real fast, no dots) is not correct because they use approximation.

Am I getting this right?

[Reedbeta]

Just because it has direct light raytracing doesn't mean it's biased. As long as you are careful not to double-count some lighting components or leave some lighting components out, it's perfectly legitimate to use different evaluation methods for different sectors of illumination, e.g. direct light sampling for light sources (even area lights), and path tracing or photon mapping for indirect light. This is just a form of importance sampling - distributing your samples in a way that puts more samples in areas likely to be important. This is compatible with being unbiased as long as you are careful about the math and make sure everything is correctly weighted and each lighting component is included exactly once.

A raytracer with no indirect illumination would be biased because it leaves out a lighting component. Path tracers are typically designed to be unbiased in all cases, whether they use direct light sampling or not (and it's better that they do, because it decreases variance and therefore improves quality for a given amount of render time!). Photon mapping with or without final gathering is unbiased if you increase the number of photons as well as the number of samples. It's biased if you consider only a fixed photon count while increasing the number of samples in the raytracing (& final gathering) part. Most raytracers' claims to be unbiased are probably on the level (excepting bugs or unintentional design flaws, and really extreme issues like floating point precision etc.)

BTW, I guess I should clarify that with regard to the photon search radius, I'm expecting it to get smaller as the number of photons increases, so that it goes to zero in the limit.