Page 3 of 3

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

Posted: Sat May 10, 2014 8:45 pm
by ingenious

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

Posted: Mon May 12, 2014 9:47 am
by tomasdavid
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 :-)
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. :-(

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

Posted: Mon May 12, 2014 12:16 pm
by ingenious
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 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).

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

Posted: Tue Sep 02, 2014 7:45 am
by Emphy
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!


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

Posted: Sat Sep 20, 2014 10:37 am
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): ... NncTIxM1E/

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,