Path Tracing vs. Ray Tracing (2016)(dusterwald.com)
dusterwald.com
Path Tracing vs. Ray Tracing (2016)
https://www.dusterwald.com/2016/07/path-tracing-vs-ray-tracing/
33 comments
I liked this siggraph presentation about how some people at NVidia see the games industry adopting a more VFX-like pipeline, for a lot of the same benefits you talk about:
http://on-demand.gputechconf.com/siggraph/2018/video/sig1813...
http://on-demand.gputechconf.com/siggraph/2018/video/sig1813...
The biggest benefit of the RTX cards isn't that they'll make existing video games faster or that the new effects are strikingly more beautiful than current technology. The biggest benefit is how easy it is to add these new effects, achieving a look as beautiful as the previous state-of-the-art trickery with a simple toggle.
Noticed a lot of inaccuracies in the article.
> It also requires light sources to have actual sizes, a bit of a departure from traditional point light sources that have a position but are treated like an infinitely small point in space
You don't wait for the ray to bounce into a light. Lights are typically sampled directly at each bounce point in a path tracer. If you waited for the beam to hit a light it would take a crazy amount of time (100k+ samples for complex scenes) to converge.
> how far you can trace them before giving up
You can use Russian roulette techniques to get unbiased sampling of arbitrary length paths.
> The crux of the problem is that with a path tracer you are locked into an all or nothing approach...
There's many more subtleties into getting convergence than simply 'tweaking quality settings', eg. volumetrics, types of lighting, types of material, denoising etc. Also it's MUCH more difficult to get a realistic result with simple raytracing than the author says.
> is it the future of high quality offline rendering?
Pathtracing has been used for almost all offline VFX rendering for a very long time now (although there's some new interesting developments in using rasterization for production now)
> It also requires light sources to have actual sizes, a bit of a departure from traditional point light sources that have a position but are treated like an infinitely small point in space
You don't wait for the ray to bounce into a light. Lights are typically sampled directly at each bounce point in a path tracer. If you waited for the beam to hit a light it would take a crazy amount of time (100k+ samples for complex scenes) to converge.
> how far you can trace them before giving up
You can use Russian roulette techniques to get unbiased sampling of arbitrary length paths.
> The crux of the problem is that with a path tracer you are locked into an all or nothing approach...
There's many more subtleties into getting convergence than simply 'tweaking quality settings', eg. volumetrics, types of lighting, types of material, denoising etc. Also it's MUCH more difficult to get a realistic result with simple raytracing than the author says.
> is it the future of high quality offline rendering?
Pathtracing has been used for almost all offline VFX rendering for a very long time now (although there's some new interesting developments in using rasterization for production now)
> You can use Russian roulette techniques
Did you mean Monte Carlo?
Did you mean Monte Carlo?
They meant Russian Roulette:
https://docs.redshift3d.com/display/RSDOCS/Optimizations?pro...
https://docs.redshift3d.com/display/RSDOCS/Optimizations?pro...
Russian roulette often refers to when a Ray has a random chance of terminating (being absorbed)
> although there's some new interesting developments in using rasterization for production now
Interesting, do you have any links for further reading?
I'm biased, of course, being in the real-time space, but as time has passed I've really come to appreciate the simplicity and practicality of rasterization…
Interesting, do you have any links for further reading?
I'm biased, of course, being in the real-time space, but as time has passed I've really come to appreciate the simplicity and practicality of rasterization…
Maybe I'm wrong, but the terminology isnt that clear. Path tracing is a sub field of Ray tracing - Ray tracing refers to the camera into scene Ray generation. What he describes as raytracing sounds like the whitted recursive algorithm.
The terminology's always been a bit vague: technically "Ray casting" is a more accurate way to describe one ray being sent out and intersected with something (i.e. from camera/eye into the scene). The "tracing" part used to imply Whitted, but then things like PRMan introduced "raytraced shadows" as an alternative to shadow maps, and it took on a dual-use meaning...
You do sometimes see people using the term narrowly, but often the entire category of renderers is referred to as ray tracers. (Which I think makes sense, because they're all based on tracing the paths of rays.)
A notable example of that usage:
> When somebody says "ray tracing" it could mean many things. What I am going to describe is technically a path tracer ~ "Ray Tracing in a Weekend" by Peter Shirley
A notable example of that usage:
> When somebody says "ray tracing" it could mean many things. What I am going to describe is technically a path tracer ~ "Ray Tracing in a Weekend" by Peter Shirley
Ray casting = where does a ray intersect an object
Ray tracing = ray casting from the camera and where an object intersects trace rays (with ray casting) to light sources and reflective materials (Turner Whitted).
Path tracing = ray tracing but when you hit an object start ray casting from that point as bounce and gather all energy so you can send it back to the camera (James Kajiya ?).
So to me path tracing is just a method (extension) of ray tracing.
Ray tracing = ray casting from the camera and where an object intersects trace rays (with ray casting) to light sources and reflective materials (Turner Whitted).
Path tracing = ray tracing but when you hit an object start ray casting from that point as bounce and gather all energy so you can send it back to the camera (James Kajiya ?).
So to me path tracing is just a method (extension) of ray tracing.
... and yet, in the DXR API, the TraceRay function does what you're calling ray casting here, i.e. it figures out the intersection of a single ray with the scene (and calls a shader associated to the hit material, to somewhat simplify it; in any case, TraceRay doesn't trace multiple rays).
The terminology just isn't 100% consistent.
The terminology just isn't 100% consistent.
AFAIK current state-of-the-art in pathtracing are still metropolis light transport methods. Seems like current research is mostly focussed on denoising - which makes sense, since a good denoising provides a valuable shortcut for quicker results.
While I only occasionally glance at new results in this area it seems that CNN-based denoising techniques look quite promising, possibly getting us close to viable real-time pathtracing at least for "suitable" scenes. I am more confident than ever that a shift to traced renderers could be next - this has nothing to do with RTX and the buzz around it though...
While I only occasionally glance at new results in this area it seems that CNN-based denoising techniques look quite promising, possibly getting us close to viable real-time pathtracing at least for "suitable" scenes. I am more confident than ever that a shift to traced renderers could be next - this has nothing to do with RTX and the buzz around it though...
Metropolis has lots of advantages, but it has serious problems for realtime or animated applications, in that it tends to flicker or have noticeable low-frequency noise. This is less of a problem for stills.
RTX can absolutely accelerate path tracers, even for non-realtime applications. The underlying framework is definitely flexible enough to support a variety of rendering algorithms, it's basically accelerated BVH and intersection, with shaders to control behavior.
The biggest advancement I've seen lately is advances in denoising - the ML-based denoisers are incredible, but others are also impressive.
RTX can absolutely accelerate path tracers, even for non-realtime applications. The underlying framework is definitely flexible enough to support a variety of rendering algorithms, it's basically accelerated BVH and intersection, with shaders to control behavior.
The biggest advancement I've seen lately is advances in denoising - the ML-based denoisers are incredible, but others are also impressive.
This is slightly irrelevant but presumably someone could invent a version of Metropolis that also distributed its rays across time as well as space, thereby ensuring that any bright/flickery pixels would remain coherent across frames; i.e. once that path was discovered on one frame, it could propagate that path information out to previous/succeeding frames.
> I am more confident than ever that a shift to traced renderers could be next - this has nothing to do with RTX and the buzz around it though
You mean you being confident or the shift has nothing to do with RTX?
The purpose of RTX is to solve the chicken-and-egg problem of hardware first or software first. It's much less likely for a company to invest the effort into developing a path traced renderer without hardware support, but without software support there's no demand for the hardware. RTX is supposed to kickstart real time path/ray traced graphics.
You mean you being confident or the shift has nothing to do with RTX?
The purpose of RTX is to solve the chicken-and-egg problem of hardware first or software first. It's much less likely for a company to invest the effort into developing a path traced renderer without hardware support, but without software support there's no demand for the hardware. RTX is supposed to kickstart real time path/ray traced graphics.
I use path tracing for scientific/engineering studies of light propagation; in particular, I attempt to simulate monochromatic light sources and reflective/transmissive/absorptive material configurations (ranging from specular to diffusive, and everything in between) to determine the irradiance delivered to specific geometries. In the past I have used commercial packages like ASAP (APEX Solidworks add-in), Zemax, and FRED (in order of preference).
> but until path tracing times are measured in minutes per frame, as opposed to the hours or days they are now
How about realtime on a consumer PC ;)
http://www.pouet.net/prod.php?which=69642
http://www.pouet.net/prod.php?which=75720
To make things clear, these 4k intros are not at all representative of what is done in the film industry. It is made possible by using very simple mathematical shapes (a sphere or 8 cubes). But that's still bonafide pathtracing.
How about realtime on a consumer PC ;)
http://www.pouet.net/prod.php?which=69642
http://www.pouet.net/prod.php?which=75720
To make things clear, these 4k intros are not at all representative of what is done in the film industry. It is made possible by using very simple mathematical shapes (a sphere or 8 cubes). But that's still bonafide pathtracing.
Wish there were illustrations
Disney's Practical Guide to Path Tracing is a good resource for explaining path tracing: https://youtu.be/frLwRLS_ZR0
I wonder what convolutional neural networks bring to the table. Maybe you could use them to get rid of the noise, or then you could use ray tracing for the base image and train a CNN to "recolour" that image based on a noisy path traced one of the same scene.
This demo is 4 years old, but the noise still seems to be a problem: https://youtu.be/BpT6MkCeP7Y
If anybody's got more recent impressive demos to link, I'd like to see how things have been developing.
This demo is 4 years old, but the noise still seems to be a problem: https://youtu.be/BpT6MkCeP7Y
If anybody's got more recent impressive demos to link, I'd like to see how things have been developing.
This one is 3 years old, showcasing Brigade https://vimeo.com/124065358.
It looks like this is part of Octane Render.
It looks like this is part of Octane Render.
This uses a neural network
https://www.youtube.com/watch?v=YjjTPV2pXY0
video results start around 1:15
This one does not use a neural network:
https://www.youtube.com/watch?v=HSmm_vEVs10
https://www.youtube.com/watch?v=YjjTPV2pXY0
video results start around 1:15
This one does not use a neural network:
https://www.youtube.com/watch?v=HSmm_vEVs10
Those both only use global motion, which is the simplest case for temporal filtering; it would be interesting to see the effects with local motion (e.g. a blinking light).
> Maybe you could use them to get rid of the noise
That's what they do. See: http://drz.disneyresearch.com/~jnovak/publications/KPCN/inde...
That's what they do. See: http://drz.disneyresearch.com/~jnovak/publications/KPCN/inde...
Is there a reason that a Path Tracer doesn't just start with a quick Ray Trace and then layer the extra paths on top of it? I've seen the effects mentioned where you limit bounces of a Path Tracer and the resulting image looks grainy. Why not start with a Ray Trace and blend a limited Path Trace on top? I would guess that even a full resolution
Ray Trace blended against a quarter resolution Path Tracer with a high bounce limit would give a pretty good image right?
That's pretty much how commercial ray tracers work. Path tracing for scattered rays and GI, with ray tracing for evaluating direct light. Look at Cycles's code.
I wonder, will we ever see (or is there already) the equivalent of a game engine on a chip? Like a ray-tracing rendering pipeline, where the polygons of a scene (and the position of the observer) are directly sent via a low-level API to the GPU and then it returns an image.
ray-tracing / path-tracing as a category tends to be very branch-heavy with non-local data. GPUs are able to be so insanely parallel because their workloads don't branch much (or rather, every "thread" takes the same branch) and their data is tightly packed.
Think of a GPU like a dozen really, really basic in-order, non-speculating CPUs, each one with a stupid huge wide SIMD unit. As long as the data is nicely packed, doing the same operations on each unit of data, boom - turbo mega ultra fast. That's rasterization. That's pixel shaders. That's modern GPU workloads.
ray-tracing, though? Rays bounce around. They branch. They don't all do the same thing on nicely packed data.
This would be where something like the Xeon Phi coprocessor would fit the bill in theory. Although it looks like maybe it didn't pan out all that well as Intel seems to have killed that product line?
Think of a GPU like a dozen really, really basic in-order, non-speculating CPUs, each one with a stupid huge wide SIMD unit. As long as the data is nicely packed, doing the same operations on each unit of data, boom - turbo mega ultra fast. That's rasterization. That's pixel shaders. That's modern GPU workloads.
ray-tracing, though? Rays bounce around. They branch. They don't all do the same thing on nicely packed data.
This would be where something like the Xeon Phi coprocessor would fit the bill in theory. Although it looks like maybe it didn't pan out all that well as Intel seems to have killed that product line?
There are a lot of moving parts involved in making a full-featured path tracer, and they can have wildly varying performance characteristics. Some parts such as finding ray intersections in parallel and integrating them map extremely well to a GPU-like architecture, while others such as building and traversing a bounding-volume hierarchy are better suited for a traditional CPU (even though within certain constraints you can also do it on a GPU).
The full rendering pipeline is much more than just finding ray-triangle intersections. It also involves material BRDFs/BSDFS (reflection/scatter properties), volumetric effects (fog, liquids, etc), motion-effects such as blurring, etc. Depending on what you are rendering, the render pipeline be vastly different from application to application.
I think most production path-tracers are still primarily CPU-based, which would be because of the required flexibility.
The full rendering pipeline is much more than just finding ray-triangle intersections. It also involves material BRDFs/BSDFS (reflection/scatter properties), volumetric effects (fog, liquids, etc), motion-effects such as blurring, etc. Depending on what you are rendering, the render pipeline be vastly different from application to application.
I think most production path-tracers are still primarily CPU-based, which would be because of the required flexibility.
Sounds a lot like DXR (DirectX RayTracing) though that's high level it offloads the "go raytrace it" part to the Nvidia RTX API.
These, and any solution that generates an image, need a shit ton more information to generate an image than polygons and where the camera is.
These, and any solution that generates an image, need a shit ton more information to generate an image than polygons and where the camera is.
There is much more to a game engine than rendering graphics. Networking, input handling, ai, collision, all kinds of stuff.
This bit:
> but until path tracing times are measured in minutes per frame, as opposed to the hours or days they are now, ray tracing (or rasterization, especially micropolygon rasterizers like the one powering RenderMan) remains the better option for many classes of rendering tasks.
wasn't even true in 2016 - RenderMan (PRMan) 19 added a pathtracer and eventually in 21 removed entirely its REYES rasteriser, and pretty much the entire VFX film/animation industry is using pathtracing now.
Artist time is much more expensive than machine time, and not having to tweak things like materials / lights in the PBR realm that path tracing lives in per shot / sequence to fake things like GI (like the article mentions is a good alternative - it's not) is where a lot of the speedup has come from with iteration times.
If anyone's interested in state-of-the-art for film VFX, five papers on the five most used pathtracing renderers used in VFX were recently released:
https://jo.dreggn.org/home/2018_manuka.pdf
https://www.yiningkarlli.com/projects/hyperiondesign.html
https://www.arnoldrenderer.com/research/Arnold_TOG2018.pdf
https://graphics.pixar.com/library/RendermanTog2018/paper.pd...
https://fpsunflower.github.io/ckulla/data/2018_tog_spi_arnol...