Small volumetric path tracer back
Board:
Home
Board index
Raytracing
Visuals, Tools, Demos & Sources
(L) [2013/01/10] [ost
by D-POWER] [Small volumetric path tracer] Wayback!I have been working for the past month or so on a volumetric renderer based on smallpt. I implemented multiple scattering and a couple of phase functions (Isotropic and Henyey-Greenstein), the result so far are good enough to be shared, but the convergence is very slow, even slower than smallpt. That's why I'm planning to port this to the GPU and see what I can get.
The code is hosted on [LINK https://github.com/D-POWER/smallvpt github], feel free to fetch it and tell me what you think.
In the first image, there is a weird triangular pattern that I don't know what's causing it (maybe the rng?)
image.png
[IMG #1 Image]
[IMG #1]:Not scraped:
https://web.archive.org/web/20210305165647im_/http://dpow3r.files.wordpress.com/2012/12/foggy_cornell_box_bs_25000spp.png
(L) [2013/01/10] [tby Ciebiada] [Small volumetric path tracer] Wayback!Nice images but they might have made a better impression if maybe the resolution was smaller so the quality would be better.
Are those white fireflies in the top image a bug? Because it doesn't look like naive-path-tracing caustic noise to me.
Also regarding the rng. I know I've advocated xorshift before but some time ago I found it produced some patterns in my silly path tracing renders. Maybe it was correlation between threads, I'm not really sure, but since then I switched back to a good implementation of simple LCG (like the one in java, the implemtation is publicly available) and had no problems whatsoever. It's fast and for monte carlo simulations its more than enough.
(L) [2013/01/10] [tby D-POWER] [Small volumetric path tracer] Wayback!The fireflies are most likely caused by indirect lighting from the glass sphere, since the light source is small so sampling becomes challenging for a naive path tracer. About the pattern in the first image, I still don't know exactly the problem, but my instincts are telling me it's the random number generator, since I'm using the same seeding parameters for every thread.
(L) [2013/01/11] [tby spectral] [Small volumetric path tracer] Wayback!Great test [SMILEY :-)]
Maybe try this with SmallVCM [SMILEY :-D]
(L) [2013/01/11] [tby D-POWER] [Small volumetric path tracer] Wayback!Thanks spectral. My goal from the start is to provide a minimal code base for people to experiment with volumetric rendering, and show how it is done in practice, that's why I opted for smallpt, to maintain the spirit of a minimalistic unbiased path tracer.
The code will eventually be ported to the CUDA platform, since it offers huge speed improvements, so I might use some gpu tricks from smallptgpu...
By the way, anyone knows how slow OpenCL is compared to CUDA?
(L) [2013/01/12] [tby Dade] [Small volumetric path tracer] Wayback!>> D-POWER wrote:By the way, anyone knows how slow OpenCL is compared to CUDA?
CUDA usually gives access to some of the latest hardware feature not yet available in OpenCL and NVIDIA has introduced some really interesting feature in their latest generations of GPUs. However if a feature is available both in CUDA and in OpenCL, there is not a single technical reason why CUDA should be faster ... if it is faster, you should complain with your CUDA vendor [SMILEY ;)]
Keep also in mind that a GTX 580 is faster than the newer GTX 680 for most single precision floating point applications (and HD7970 is a lot faster of both in the same field). So you have also to careful pick the hardware to use.
(L) [2013/01/14] [tby spectral] [Small volumetric path tracer] Wayback!Sure,
It is nice to demonstrate it on a small renderer, but then... it will be interesting to add some comments, some references about the theory etc [SMILEY ;-)]
BTW, I agree with Dade, about OpenCL vs CUDA .... OpenCL has approximately the same speed than CUDA... sometimes it is even faster (sometimes not) !
The main advantage (today) of using CUDA is that :
1) You have a good debugger even on the GPU
2) You have some existing librarie (thrust etc...)
3) CUDA C is more advanced than OpenCL
The main advantage of OpenCL are :
1) You can run on different kind of devices... CPU/GPU/...
2) You can handle more memory when using the CPU... interesting for big scenes
3) Dynamic code generation... you can use it to have a more dynamic/flexible renderer
(L) [2013/01/15] [tby D-POWER] [Small volumetric path tracer] Wayback!Thanks guys for sharing your thoughts about CUDA and OpenCL...
spectral another advantage of CUDA is that it is more and more supporting OO features of C++ which isn't available in OpenCL yet.
>> spectral wrote:It is nice to demonstrate it on a small renderer, but then... it will be interesting to add some comments, some references about the theory etc
Well I didn't use much references in my implementation except this [LINK http://www.cs.cornell.edu/courses/CS6630/2012sp/notes/09volpath.pdf paper], you can also find every equations that I used in this [LINK https://github.com/D-POWER/smallvpt/tree/master/Docs doc]. If you still have questions, feel free to ask [SMILEY ;)]
(L) [2013/01/17] [tby lion] [Small volumetric path tracer] Wayback!Another advantage of OpenCL is that it can run not only on Nvidia devices.
In some cases OpenGL shader can be used.
This two variants more portable.
(L) [2013/03/11] [ost
by D-POWER] [Small volumetric path tracer] Wayback!I've ported smallvpt to cuda, added support for sub-surface scattering and fixed a lot of bugs in my scattering code
image36263.png
back
