[HN Gopher] Show HN: Physically-Based GPU Pathtracer with Mitsub...
___________________________________________________________________
Show HN: Physically-Based GPU Pathtracer with Mitsuba XML Support
Author : janvanbergen
Score : 58 points
Date : 2021-08-06 13:39 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mkl wrote:
| The 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...).
| unknownOrigin wrote:
| Why CUDA?
| dogma1138 wrote:
| Because there are no real alternatives yet, especially if you
| need to leverage existing libraries.
| sxp wrote:
| Nice 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...
| janvanbergen wrote:
| The GPU I currently use is my laptop's 845m, so I don't think
| my performance numbers are that representative
| chrsig wrote:
| Very 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?
| janvanbergen wrote:
| 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
| pixel_fcker wrote:
| What are your thoughts on the performance of wavefront tracing as
| opposed to regular path tracing approach?
___________________________________________________________________
(page generated 2021-08-06 23:01 UTC)