Progressive photon mapping with metropolis sampling

Hi again,

To answer my last entry, I've added metropolis sampler to my photon tracing routine.

Well it was a natural thing to do.

I am aware of that paper by Toshiya et al. - Robust Adaptive Photon Tracing using Photon Path Visibility.

But since I am quite familiar with Kelemen's mlt, and I didn't want to switch to that sppm approach (I keep it as a traditional photon mapper with shrinking radius), I implemented it quite differently. Path quality is equal to how many photons do contribute to photon map (and photon map's bouding box is based on the visible hitpoints). So it just favors longer paths. Perhaps I could extend it to how much flux the path carries.

Also like in standard Kelemen's mlt, there are 2 mutation strategies, small and large mutation, which the former needs some further testing like mutation approach and size.

So enough talking, pics:

Path tracing:

Photon mapping - random sampling:

and finally, Photon mapping - metropolis sampling:

All images were computed in 2 minutes, also the metropolis code is still fresh and messy.

photon mapping vs path tracing outdoor test

So yea photon mapping doesn't handle biger scenes very well.

Glass is farily good (good caustics makes up for crap direct ilumination, I trace 5m photons every pass here, perhaps if I lowered that number I would get better direct lighting and antialiasing, but worse indirect lighting).

Photon mapping:

Path tracing:

Lambert material, photon mapping (without direct lighting computed separately):

Photon mapping with direct lighting:

Path tracing:

As expected path tracing performs better, maybe some fine tunning (photons per pass and initial radius) would help, but I don't expect miracles.

Couldn't resist the GPU hype,

so I wrote an open cl path tracer in C. It's very similar to Dade's SmallptGPU but it uses float4 though.
I don't have proper GPU to test it on, but I got tempted by sse operations that vector operations supposedly utilize.

A performance note:

While I get 2 fps on this scene with my core 2 duo (no ht), my friend with his radeon 4870 gets almost 60 fps.
I'm not yet sure if thats good enough.



(I misleadingly called frames samples, while they are samples per pixel, yea)

Water caustics

One of the hardcore scenes to test. Forgive me the noise but my bvh is so slow :(.

Cheers.

A little update

Hi there,

What's new:

• Added Beer's law to the glass material - you can tell how absorption varies with the distance traveled (for ex. monkey's ear is barely colored versus it's middle).
• Pixel filtering - added variety of filters. The black border around the light source is due the negative values of mitchell filter.
• Reimplemented simple bvh and .obj parser.

Btw. could somebody tell me:

when I specify my light intensity with pure rgb triplet as its emittance, for ex. (15, 15, 15) - what units are those? And how could I convert between other, perhaps more physically convenient, units? so I could compare my results with other renderers.

Cheers.

Cornell box

I just like them.

I'm back

Yet again starting from scratch. Playing with metropolis.



Naive path tracing on the left, same thing but with metropolis on the right.

Explicit direct lightning

gives a lot,

unmatched quality:

A fireflies happen to appear from time to time (there is one on the ceiling for example) and, what's funny, it's a random thing while my PRNG has constant seed values.

I'm almost sure its because all threads share one random number generator and what seem to happen they are at times calling random procedure ALMOST in the same time, reassigning the values unpredictably.

Edit:

Blah

Seems my sRGB conversion was causing that fireflies from previous images.

Btw. I was wondering why the farthest I've ever get in ray tracing (excluding fixed path MLT in C++) was when I was using OCaml. Say what You want, but that functional language thing fitted ray tracing very well. Also, but that's maybe caused by my nature - now when I have dozens of ways to implement something I start to wonder what way to choose, what would lead to better design. Too many options confuse me, and slow me down big time.

I've set emitter colour to rgb approximation of 2600K, it makes some nice, realistic atmosphere.

It's still naive path tracing, though.

Multithreading and some GUI

Hi there,

I've added some multithreading and was playing with gui in swing.

As far as everything was a very pleasant experience, I'm concerned that
I got only ~190% load on my two cores, what means that the speedup is not exactly 2x.

So I've tested sunflowand noticed
that it also doesn't get anywhere near 200% - 180%-190% most likely. So I don't know...

Java path tracing

Hello I'm back.

My current weapon of choice is Java though.

The renderer supports:

• median split BVH,
• thin lens and pinhole camera models,
• sphere and Triangle primitives,
• naive path tracing with lambertian surfaces only,
• rendering in a progressive manner.

Performance is not that bad. I designed it to take full advantage of the new feature of java called Escape Analysis, so I'm not reusing objects (what leads to ugly code btw.) but creating them like crazy.

What sucks though is that there is no 1.6.0_14 java for Mac OS X yet, but I've tested in on windows and it works very well.

Some first, naive path tracing, renderings: