ompf2.com

... 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 d...

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)...

I had once actually tested similar ideas, but I immediately discarded it since the performance was not really good. It looks like they achieved around 100M rays per second in fully dynamic scenes. Given that we can trace maybe a few times more than that in static scenes, it isn't too bad, but maybe ...

This paper is also quite relevant to this discussion: 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 ...

All architectural designers seriously need to use a rendering algorithm that can properly handle caustics!

# In my office, caustics from a mirror like building on the other side are trying to burn my eyes during sunny days.

I've also found that the Moller-Trumbore test is the fastest on GPUs. The Woop test (or perhaps a slight variation) is the fastest for me on CPUs, but because of the additional storage-related cost, it is slightly slower than the Moller-Trumbore test on GPUs in my experiments. Plucker is definitely ...

Thank you for the replies! I managed to slightly speed up mine (whopping 2%...) by following this code: http://tog.acm.org/resources/RTNews/html/rtnv21n1.html#art9 which uses a fewer branches as I suspected it should be. The article posted by graphicsMan (which links to the above) concluded that one...

Maybe my question is still not clear, but I am not talking about making VPL rendering with clamping consistent, which your progressive VPL is doing. I am just asking if there is an obvious way to achieve the same image with 100 VPLs x 1000 iterations and 100K VPLs x 1 iteration while clamping the im...

In a progressive setup, where at each rendering iteration you sample a fixed number of light paths and accumulate all resulting images, you need to progressively increase the pixel clamping threshold, as discussed in our Siggraph sketch linked above.. My question is, wouldn't it be kind of "subopti...

I am currently using the "optimized version" of this method: http://people.csail.mit.edu/amy/papers/box-jgt.pdf but I started wondering if it sill is an efficient approach today because of the number of conditional branches. For example, I've tried to add some early-outs based on the distance along ...