Re: My Optix porting of SmallVCM (only PathTracer & BDPT)

(L) [2014/05/08] [ost by AGPX] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> ultimatemau wrote:You should look at the Streaming Bidirectional path tracing (Chapter 8) from Dietger van Antwerpen: [LINK http://repository.tudelft.nl/view/ir/uuid:4a5be464-dc52-4bd0-9ede-faefdaff8be6/]
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.

(L) [2014/05/09] [ost by toshiya] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> ingenious wrote:This paper is also quite relevant to this discussion:

[LINK http://cgg.mff.cuni.cz/~jaroslav/papers/2014-gpult/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.

(L) [2014/05/09] [ost by ingenious] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> toshiya wrote: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?
>> toshiya wrote: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.

(L) [2014/05/09] [ost by toshiya] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> ingenious wrote: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.
>> ingenious wrote: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...).

(L) [2014/05/10] [ost by tomasdavid] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> toshiya wrote:#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. [SMILEY :-(]
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.

(L) [2014/05/10] [ost by toshiya] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> tomasdavid wrote:... 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 [SMILEY :?] 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.

(L) [2014/05/10] [ost by friedlinguini] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> toshiya wrote: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.

(L) [2014/05/12] [tby tomasdavid] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

>> toshiya wrote: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.
No worries [SMILEY :-)]
I would suggest you put a note to the sketch that people really should read your thesis rather than the sketch.
My approach (where the probability of replacement depends on the value of the counter) is can do the trick of fixed size.. in theory.
In practice, you'd have to have the operation as atomic, which it ain't, so it can happen that photon A decides it will be replacing, photon B *also* decides it will be replacing (using correct probability after photon A has been written), photon B is written and only *then* photon A gets written.
But in practical practice, this happens so rarely that it shouldn't matter. But it is not 100% unbiased decision either. [SMILEY :-(]

(L) [2014/05/12] [tby ingenious] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

So how about the following. Each light path is traced in one thread, storing the generated photons in a thread-local array. Upon path termination, the photons to the grid in a random order, without any global synchronization. (A fast on-the-fly permutation function is given in Listing 3 in the [LINK http://graphics.pixar.com/library/MultiJitteredSampling/paper.pdf Correlated Multi-Jittered Sampling paper].) When using persistent threads, the total memory footprint of the temporary storage is num_hardware_threads * max_path_length, which is presumably much smaller than num_light_paths * max_path_length (required by the approach that Toshiya outlined above).
But I actually wonder where the big savings with this approach are: at construction time or in during the final rendering? Because if it's the second, then it may be worth spending a little extra effort in the construction stage and be a bit smarter. For example, variance could be reduced by making the probability of a photon being stored in a cell proportional to its power (rather than assigning a uniform survival probability to all photons in the cell).

(L) [2014/09/02] [tby Emphy] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

Dear AGPX (for lack of your real name),
Is there any chance you are willing to (privately) share your OptiX sourcecode for this project? I'm implementing a BDPT for my master thesis, but it's going less smooth than one would hope. I think I could learn a lot about the OptIX implementation from what I've seen are your results (well done by the way). I understand it if you want to keep the sourcecode to yourself though but I had tio ask.
Thanks for reading!
Regards,
Emphy

(L) [2014/09/20] [tby AGPX] [Re: My Optix porting of SmallVCM (only PathTracer & BDPT)] Wayback!

Hi Emphy,
you can download the full sources from here, but I have no much time to give you details about the implementation (that however is a straightforward porting of the SmallVCM's bidirectional path-tracer):
[LINK https://docs.google.com/file/d/0B5XiKsI39CvcWkZ1alNncTIxM1E/]
Environment used:
- Windows 7;
- Visual Studio 2010;
- Cuda 5.5;
- Optix 3.5.1;
I have coded it for fun and you'll find some experiments that you can (in)exclude via macros (like a "FAST_CONNECTION").
Good luck,
- AGPX

Re: My Optix porting of SmallVCM (only PathTracer & BDPT) back

Board: Home Board index Raytracing General Development