# Photon mapping

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

## Recommended Posts

##### Share on other sites

How exactly are you doing the visualization of the photon map?

##### Share on other sites
Hm - I though I made sure hotlinking was working. Oh well - quickfixed the problem.

I have been using the following method: since packed photon direction is commonly represented through two 8-bit variables (theta and phi, which is the method I'm using right now), these rather naturally map to a 256x256 grid of intensity values that can be exported as a bitmap (to see relative spherical distribution in all directions).

Also, by looking at the produced images after the render, it's easy to deduce that photons have to be present in the correct pattern to form the quite evidently correct lighting pattern. Knowing these two things, I can know that there's a linear distribution of photons throughout the scene and that the distribution itself is correct.

What is lacking is the finesse (the smooth transitions) that should be produced in the render pass by radiance estimation. I hope you can open the images now (sadly, each in a separate window) to see what I have in mind. By clicking on Original Size on the eSnips page, you can view the images in their native 512x512 size.

As stated above, I can get decent results, but only by using an inexorbitant number of photons for the estimation, which - for lack of a better term - is way too damn slow.

I'm using Jensen's code so there shouldn't hopefully be anything too unexpected. The estimation code looks like this:

for(i = 1; i <= np.found; i++)  {  TPhoton *p = np.index;  //use direct mapping with no culling  irrad[0] += p->power[0];  irrad[1] += p->power[1];  irrad[2] += p->power[2];  }double tmp=(1.0f / PI) / (np.dist2[0]);irrad[0] *= tmp;irrad[1] *= tmp;irrad[2] *= tmp;

##### Share on other sites
Direct visualization of the photon map is extremely inefficient, as Jensen notes repeatedly. The real wins come from combining a direct lighting pass (Whitted style) with partial irradiance data from the photon map. Jensen details several techniques for this in the photon mapping book as well as freely available papers all over his site.

In short, what you're getting is precisely what you should be getting.

Also, note that it is generally advisable to use a stratified stochastic distribution of emitted photons, not a purely uniform one.

##### Share on other sites
I once implemented photon mapping (it's a while back I admit) and what I remember is that I got poor results from the built-in VS2005 random generator. Use the mersenne twister instead, it's faster and much better. That solved similar problems for me.

EDIT: Didn't read the last post above mine; looking at your images it indeed looks like you use an even distribution. Keep it, but add randomness (using the Mersenne Twister).

##### Share on other sites
Quite counter-intuitively, after a little bit of pondering, it seems obvious to use a smaller number of emitted photons, a relatively small number of photons in the estimation and a larger radius to achieve a greater sense of smoothness. This, of course, is only suitable for an ambient diffuse light - directional lights and caustics require just the opposite.

In any case, if the pixellation is normal, then that's that I suppose :). I added the Mersenne twister - I'm not sure of the benefits just yet - the visual quality didn't improve much; however, I haven't done any speed benchmarking with respect to rand() - on large scenes this could make a world of difference.

Thanks for the feedback, guys!

##### Share on other sites
The speed of your PRNG is essentially irrelevant, unless it's stupidly slow. The real costs are in intersection tests and KD-tree traversal for the photon map lookups.

##### Share on other sites
Yeah - I noticed; that's why I was dismayed that 1500+ test samples were needed to be collected to get decent results.

##### Share on other sites
If you plan on using the photon map for indirect or direct lighting, then you should also look into the "final gather" operation, which is computationally expensive (instead of querrying the photon map at that point, it shoots out hundreds of rays over the hemisphere and querries the photon map at those points). This prevents direct visualization of the error associated with the photon map, and generally produces decent results for indirect illumination, though I'm a bit too rusty to remember if it also produces good results for direct illumination.

##### Share on other sites
I don't think direct illumination is a good goal for photon mapping, unless you truly have static scenes. Occlusion problems will become readily apparent in dynamic scenes, but the eye will be more forgiving for indirect lighting. It is my understanding that this is generally the adopted view with radiosity solutions as well.

Along the same lines, real-time raytracing engines are accepting the fact that primary rays are better processed through a rasterizer than through actual path tracing - which should be done for secondary rays (including global illumination algorithms if implemented). The raster engine is just so much faster...

1. 1
2. 2
3. 3
Rutin
19
4. 4
5. 5

• 14
• 30
• 13
• 11
• 11
• ### Forum Statistics

• Total Topics
631780
• Total Posts
3002314
×