Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
1–9 of 9 posts
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#2Nice work.
I'm always a fan of custom raytracers since I feel that they're projects that everyone in CS should do once. It's possible to get a raytracer built in a day [1][2], but you can also endlessly expand the project to create something as photorealistic as your project.
One request: can you add benchmark numbers to each image? I.e, "this image was rendered in X minutes on Y hardware". This is particularly important since your renderer implemented a bunch of performance optimizations so it's helpful to compare it with other physically-based renderers.
[1] https://www.kevinbeason.com/smallpt/
[2] https://raytracing.github.io/books/RayTracingInOneWeekend.ht...
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#3Very nice! I only took a quick gander at the code, and I only dabble in PBR & path tracing as a hobbyist, so forgive me if I'm asking poor questions here --
Have you thought about implementing a bidirectional integrator? (it looks like it's only sampling rays originating at the camera, but I could easily be overlooking something)
How are you handling scenes with many light sources?
What are your thoughts on using cuda versus something cross platform like opencl? I've been tinkering on a gpu enabled path tracer as well (not nearly as far along as this), and I've been restricting myself to C99 so that I can easily run the kernel on cuda/opencl/cpu, which I found can actually make for an easier debugging experience)
How big of a difference does using an SOA representation for vectors? I've understood that to be more of a SIMD type optimization, so I'm curious how it does on the GPU?
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#4Very nice! I only took a quick gander at the code, and I only dabble in PBR & path tracing as a hobbyist, so forgive me if I'm asking poor questions here -- Have you thought about implementing a bidirectional integrator? (it looks like it's only sampling rays originating at the camera, but I could easily be overlooking something) How are you handling scenes with many light sources? What are your thoughts on using cud…
I'm mostly trying to keep the pathtracer simple and performant, so for this reason I would rather not implement bidirectional methods. However, I may end up implementing path guiding instead in order to better sample caustics etc.
I sample the lights proportional to their area times intensity. This is very much less than optimal for scenes with many lights.
As far as opencl goes, I don't have much experience with it so I cant really comment. For my GPU code I do tend to prefer a C-ish coding style, although I still use templates etc here and there.
SOA vs AOS mostly comes down to whatever access pattern you use on the data. On the CPU you mostly have to worry about the cache/prefetcher, on the GPU its more important to get coalesced vector loads in order to make maximum use of bandwidth
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#5Nice work. I'm always a fan of custom raytracers since I feel that they're projects that everyone in CS should do once. It's possible to get a raytracer built in a day [1][2], but you can also endlessly expand the project to create something as photorealistic as your project. One request: can you add benchmark numbers to each image? I.e, "this image was rendered in X minutes on Y hardware". This is particularly impor…
The GPU I currently use is my laptop's 845m, so I don't think my performance numbers are that representative
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#6What are your thoughts on the performance of wavefront tracing as opposed to regular path tracing approach?
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#7Why CUDA?
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#8Why CUDA?
Because there are no real alternatives yet, especially if you need to leverage existing libraries.
Re: Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
#9The staircase in particular looks amazing. I think in your description you should expand/ link some of the jargon, e.g. BVH is Bounding Volume Hierarchy (https://en.wikipedia.org/wiki/Bounding_volume_hierarchy), and SAH is Surface Area Hierarchy (https://medium.com/@bromanz/how-to-create-awesome-accelerato...).