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.
How far did you tested this approach? And what is its benefits beside what you did show?
ReplyDeleteI think you would get the same improvement if you use portals to increase samples in regions visible to the camera.
Is it based off this paper or just a coincidence?
ReplyDeletehttp://cgcad.thss.tsinghua.edu.cn/chenjt/isppm/preprint.pdf
Awesome!! This is great, thank you for sharing.
ReplyDeleteI wonder how your glass monkey head will do with the PPM-MLT.
Hi, thanks for the comments.
ReplyDeleteUm. I've never seen that paper before, Im adding it to my readinglist for sure.
As I've said somewhere around here, right now, I kinda have something with work, college and stuff going on, so I had to put ray tracing on the second plan for now. But I'm glad you guys like it, and still visit this blog :).
Best regards.
Micheal, I see that you your PPM implementation follows the "PPM: A Probabilistic Approach" paper, which means you can build the data structure over photons rather than hit point.
ReplyDeleteHowever, when implementing metropolis visibility sampling, we have to use the "hitpoint map" approach, right (also known as "reverse photon mapping")?
Well,
ReplyDeleteI didn't read papers about this matter and am not familiar with anything other than old Keleman's metropolis paper.
So my implementation is quite the same as path tracing with metropolis sampling, but instead of using pixel brightness I used path length.
But it's up to you how do you evaluate the path quality.
My first tests (images from this post), were using just path length as a quality measure. Paths with more visible hitpoints were not different in quality than same length paths but with hitpoints that are not visible.
Adding "just" visibility checks to quality calculations (go through all the path hitpoints and if it's visible to the viewer then pathQuality++) gave outstanding results compared to just path lenghts.
But then I felt envy to Toshiya's implementation, and wanted to get rid of that visiblity checks. So I left the algorithm the same, all radius calculations and such. But decided to build the hitpoint map instead of the photon map, like Toshiya does in his original paper. This way I could measure the path quality without extra visibility checks, and yet keep that basic implementation from "PPM: A probabilistic Aprroach"
Yes you are right. That's why I thought we have to use the "hitpoint map" approach rather than the "photon map". Otherwise we will need to trace extra rays to do the visibility check. However, I realized that even if you choose do the visibility check, it will only work if all the surfaces directly visible to the camera are diffuse. If there is a, say mirror, directly visible to the camera, then some photons that are not directly visible to the camera can still contribute to the image via the mirror. The "hitpoint map" approach avoids this problem.
ReplyDeleteThat's true. Forgot about that :)
ReplyDelete