My Optix porting of SmallVCM (only PathTracer & BDPT)

[AGPX]

Ah, ok, so probably it use both (pressing 'p' (lowecase) the number of devices should decrease)...

[ultimatemau]

You should look at the Streaming Bidirectional path tracing (Chapter 8) from Dietger van Antwerpen: http://repository.tudelft.nl/view/ir/uu ... fdaff8be6/
Actually it's better read the whole thesis .

[ingenious]

This paper is also quite relevant to this discussion:

http://cgg.mff.cuni.cz/~jaroslav/papers ... /index.htm

It's first-authored by the main author of SmallVCM.

[AGPX]

You should look at the Streaming Bidirectional path tracing (Chapter 8) from Dietger van Antwerpen: http://repository.tudelft.nl/view/ir/uu ... fdaff8be6/
Actually it's better read the whole thesis .

Hi, thanks for this link, it's hard to find a publication with so many details. This publication worth a read for sure.

[toshiya]

This paper is also quite relevant to this discussion:

http://cgg.mff.cuni.cz/~jaroslav/papers ... /index.htm

It's first-authored by the main author of SmallVCM.

This paper is great, but I have to rebut a few points regarding SPPM and stochastic hashing since they are misleading in my opinion (I already notified them to Tomas):

* The paper claims that stochastic hashing is wrong for longer paths. This claim is true only if each trace() generates multiple photons and add them immediately as soon as it's generated, because the longer the path the more likely that photons are written later which breaks the assumption of the algorithm. For the results I presented in my sketch, I used a variation of photon tracing algorithm which traces one bounce ray and generates one photon per pass (similar to path tracing with persistent threads). The hash table is created after each trace call, so lengths of paths are irrelevant. In this case, given any location in the scene, the probability that one thread being the last one to write is the same. I admit that it's not clear from the sketch, but stochastic hashing can be made correct for longer paths.

* For SPPM, we don't need to "always" trace at glossy surfaces (nor we need to always stop at diffuse surfaces). For slightly glossy surfaces, we can just stop there and produce better results. Figure 7 is a bit misleading since I can easily get (b) and (d) at the same time with SPPM. I think the same misleading results are repeated for SmallVCM results. It's like the fact that you can make original photon mapping completely screwed if you don't trace additional bounce rays for specular surfaces, so it's not very fair comparison. Once we have such a heuristic in place with SPPM, it is actually rather hard to break except maybe for direct illumination. The SPPM results I compare in the UPS paper do use this heuristic.

One little note about additional noise in stochastic hashing: I think people are missing the fact that it can be greatly reduced if we use a larger hash table with a well designed hash function (shown in my dissertation). Additional noise is certainly adjustable with little overhead.

[ingenious]

For the results I presented in my sketch, I used a variation of photon tracing algorithm which traces one bounce ray and generates one photon per pass (similar to path tracing with persistent threads). The hash table is created after each trace call, so lengths of paths are irrelevant. In this case, given any location in the scene, the probability that one thread being the last one to write is the same.

How does this avoid the issue that one grid cell can be overwritten by subsequent passes (i.e. longer paths)? Or do you build a separate hashed grid for every bounce? If not, then it seems to me that with this approach length-1 photons are less likely to survive than longer-length photons which land in the grid at a later time. Maybe if each path is traced in one thread and generates only one photon (upon termination), then you can assume that due to scheduling paths terminate at random times. Am I missing something?

For SPPM, we don't need to "always" trace at glossy surfaces (nor we need to always stop at diffuse surfaces). For slightly glossy surfaces, we can just stop there and produce better results. Figure 7 is a bit misleading since I can easily get (b) and (d) at the same time with SPPM. I think the same misleading results are repeated for SmallVCM results.

It's still not clear how to handle glossy inter-reflections with SPPM though, e.g. LGGE paths, where G stands for moderately glossy scattering. I think it's better to just trace a full eye sub-path and MIS between the different PPM estimators, as done in bidirectional photon mapping. It's only a little more involved than SPPM (and much easier than a full-blown UPS/VCM implementation), and should give better results on most scenes. Efficient recursive computation of the MIS weights is also available (and implemented in SmallVCM). Unless there's some technical consideration that favors a "pure" SPPM implementation.

[toshiya]

Or do you build a separate hashed grid for every bounce?

Yes, that's what I am doing for the results in the sketch. The number of bounces for each thread is not synchronized (i.e., as soon as it's killed by Russian roulette or missed the scene, it's regenerated from a light source in the next step). GPUSPPM on my webpage uses a simpler approach of storing one photon per path (which, of course, is a bit wasteful).

#EDIT: Actually, the better answer is that I don't write into the hashed grid as soon as photons are generated. I trace all the rays, generate all the photons, and then write them into hashed grid at once.

It's still not clear how to handle glossy inter-reflections with SPPM though, e.g. LGGE paths, where G stands for moderately glossy scattering. I think it's better to just trace a full eye sub-path and MIS between the different PPM estimators, as done in bidirectional photon mapping. It's only a little more involved than SPPM (and much easier than a full-blown UPS/VCM implementation), and should give better results on most scenes. Efficient recursive computation of the MIS weights is also available (and implemented in SmallVCM). Unless there's some technical consideration that favors a "pure" SPPM implementation.

I do agree that what I mentioned is voodoo :-> My point is that you shouldn't always trace additional bounce rays just because it's glossy regardless of glossiness (which of course is suboptimal). In practice, it should be adjusted according to the glossiness. I am saying that we have already employed such a strategy in traditional photon mapping and in many other "practical" rendering systems. One can decide to trace additional bounce rays when the glossiness of an analytical BRDF is above a constant threshold, which is exactly what I did for my papers.

I am not saying that it's better than MIS, but this approach is simpler, often works fine, and computationally efficient. MIS approaches are usually more costly per sample and can be outperformed by simpler heuristics in some scenes (you know what I am talking about, beam-point 2d...).

[tomasdavid]

#EDIT: Actually, the better answer is that I don't write into the hashed grid as soon as photons are generated. I trace all the rays, generate all the photons, and then write them into hashed grid at once.

Unfortunately, the original approach to stochastic hash grid, as it is implemented,
loses the one feature I found really useful, that is, not having to preallocate for all possibly generated photons.
Of course, it still keeps the load balancing advantage when you actually trace against it.

PS: I finally moved my lazy ass and put author's version (with Toshiya's comments incorporated) on my webside (after seeing the result of TOG editing I do not feel bad about 1 citation on 19th page anymore), but Toshiya's comments here are more useful then the rather cryptic explanations I could fit in.

[toshiya]

... loses the one feature I found really useful, that is, not having to preallocate for all possibly generated photons.

I am not sure how it can be done, either I don't claim that such a thing is possible with stochastic hashing, though I admit that it might be misleading in the sketch. My dissertation contains a bit more details than the sketch on stochastic hashing, if someone else also wonders.

Thank you very much for incorporating my comments! I apologize if I sounded bitchy, but I believe this kind of post-publication discussion is sometimes useful.

[friedlinguini]

I apologize if I sounded bitchy, but I believe this kind of post-publication discussion is sometimes useful.

If this is bitchiness, please bring on a drunken flamewar. Those of us outside the ivory towers don't usually get to see the critiques, crosstalk, and clarifications; we only get to see what authors have thought to include at the time of publication.