7 ms·

Path Tracing vs. Ray Tracing

75 points by alok-g 4y ago

darkteflon 4y ago
Fascinating, and timely. Can anyone recommend a good write-up of UE’s Lumen specifically, preferably written for the interested layman?
- dagmx 4y ago
  https://advances.realtimerendering.com/s2022/index.html https://advances.realtimerendering.com/s2022/index.html This session has one of the best overviews of Lumen. The previous year has a really good overview of Nanite.
  - darkteflon 4y ago
    Thanks for this. I read about a hundred pages of the (excellent) lecture on RTGI last night. SIGGRAPH stuff is a bit aspirational for me - feels just beyond what I’m able to follow. Appreciate if you or any other poster has something aimed a bit lower - ideally as simple as possible, but no simpler!
    - dagmx 4y ago
      Unfortunately, due to how new they are, there’s not much between these presentations and what the unreal docs present. The unreal docs are probably a little easier to grok https://docs.unrealengine.com/5.0/en-US/lumen-technical-details-in-unreal-engine/ https://docs.unrealengine.com/5.0/en-US/lumen-technical-deta... but they do leave a lot out. At their core, they’re also not that different than how REYES used to work with its micropolygon architecture and the way GI was bolted on. Given how old REYES is, you might find more reading material there.
zamadatix 4y ago
I recently watched https://youtu.be/gsZiJeaMO48 https://youtu.be/gsZiJeaMO48 which was a good visual+math resource into a more detailed gamut of path based rendering.
- 4RealFreedom 4y ago
  That was really good. Thanks for posting it.
signaru 4y ago
besides tracing fewer rays, path tracing appears to have a "chiaroscuro" aesthetic to it. in moderation, absence of light can also be a good thing.
- crote 4y ago
  That is primarily a result of game designers not used to lighting for path tracing. In traditional rasterized games, the only thing that matters is whether the end result looks good. This means adding things like global illumination (a magical diffuse light source which lights up stuff regardless of position), or simply making some parts of a texture brighter to make it look as if a light source is shining on it. Things like shadows are mostly pre-baked into the textures, and primitive reflections can be faked by just mirroring whatever is already on the screen. Basically, fake it until you make it. With path tracing, the renderer follows the laws of physics. If something is lit up, the light actually has to come from somewhere. And as it turns out, most light will have hit multiple objects before finally ending up at the viewer. The artist now has to make a reasonably physics model for every single object in the game - even those the player might not directly look at. It's a completely different approach - made even worse because we aren't yet at a point where every gamer has a computer which can do 100% path tracing, so you still need to support traditional rasterization for people without bleeding-edge GPUs. To get an example of the visuals possible, look at modern cinema. Disney and Pixar movies are path traced, as is probably all CGI these days. I expect games to get a more diverse look over time, as artists get more experience with it.
  - kroltan 4y ago
    I am assuming you are both talking about the comparisons in the article? They are mostly terrible examples of path tracing, as they just took the original map files with the lights authored for the original renderer, erased the baked lighting, and run the new renderer with those lights. So it's not that game designers are not used to lighting for path tracing, it's just that nobody designed it. Heck, even porting maps between two versions of the same lineage of offline raytracer can result in ridiculously different outputs: https://www.youtube.com/watch?v=2JkRwPWnL_c https://www.youtube.com/watch?v=2JkRwPWnL_c Among other things, these games did not have high dynamic range lighting at all, so light data can only ever make the picture darker than the base textures. (Think of it as a layer set to "multiply" blend mode in a photo editor) So making a light brighter at some point wouldn't make things look any closer to white, just making the falloff sharper. So most lights were authored to look good in the renderer, not make any actual physical sense, as you said. That said, this approach of "just swap out the renderer" could work much better for games that work on a physically-based rasteriser workflow (mostly newer stuff, like from around 2015 and onward), because they mostly already use compliant and realistic light sources, and the baked lights and rasterisation are "merely" for performance. (a.k.a. being a game and not a 2-day-per-frame art installation) If you want to see a ray-tracing-native game, take a look at Teardown (https://www.teardowngame.com/ https://www.teardowngame.com/), it does not exhibit any of the "chiaroscuro" described, and has perfectly cromulent lighting.
elihu 4y ago
> "So there you have -- path tracing, the fast cousin of ray tracing. Looks almost as good, works a heck of a lot quicker. " Yeah, that's pretty much exactly wrong. Path tracing exists not because it's faster (it isn't, except perhaps in some pathological conditions), it exists because there are certain lighting effects that standard recursive ray tracing doesn't handle at all, but path tracing does. Caustics, global illumination, subsurface scattering, etc... We could be using ray tracing for just about everything now, but we don't because it doesn't look very realistic. (Photon mapping can be used to create those lighting effects as well, but path tracing seems to have won out, being a bit less fiddly. With photon mapping you have to know sort of what you're going to be looking at in advance, whereas with path tracing you don't.) Path tracing can be very slow, but improvements in computation speed plus algorithmic tweaks to prune unnecessary work mean it can be sort of done in real time these days. One of the big differences between ray tracing and path tracing is that the former is deterministic, whereas the latter is probabilistic. Ray tracing just does a bunch of math until it arrives at the answer, but in path tracing the image quality depends on how much effort you put into it. If you use a few rays per pixel, you get a grainy image. If you use a lot of rays per pixel, you get something that's a lot smoother and clearer, but takes a long time to render. One of the big semi-recent advances is to use denoising algorithms. Instead of throwing a lot of compute cycles at the problem to trace lots of rays, you just render a noisy image and use some algorithm (perhaps based on machine learning, perhaps not) to smooth it out. So now instead of tracing 100 or 1000 rays per pixel to get something that looks good, you might only trace 10, or 2, or 1.
- slavik81 4y ago
  This article is also basically equivalent to "the median vs. the average." Just as the mean is not the only average, Whitted's algorithm is not the only ray tracing algorithm. Path tracing is itself a ray tracing algorithm.
  - elihu 4y ago
    I think it's become kind of an ambiguous term that depends on context. If you're talking about algorithms, "ray tracing" usually means Whitted ray tracing, but it could also mean the whole family of algorithms that are based fundamentally on tracing rays, whether that's Whitted ray tracing, path tracing, photon mapping, metropolis light transport, etc... If you're talking about movies, ray tracing usually means path tracing these days. If you're talking about games, it probably means either path tracing or taking a conventional rasterization engine and bolting Whitted ray tracing on the side because they want realistic reflection and/or shadows. Companies that make GPUs advertise "ray tracing" as a hardware feature, because that's what the hardware does: it tests rays for intersection against some kind of bounding volume hierarchy. Whether software uses that for Whitted ray tracing or path tracing or something else is up to the application.
sorenjan 4y ago
> Traditional ray tracing involves calculating the exact path of reflection or refraction of each ray, and tracing them all the way back to one or more light sources. With path tracing, multiple rays are generated for each pixel but they're bounced off in a random direction. This gets repeated when a ray hits an object, and keeps on occurring until a light source is reached or a preset bounce limit is reached. I'm not following completely. Are they saying that raytracing only generates new rays in the reflection or refraction direction? The diagram seems to contradict that, there's three new rays generated at each surface for raytracing on that. Does pathtracing not take reflection and refraction into account at all? Does it only generate new rays in random directions to sample the incoming light? The diagram shows two new rays being generated at each surface, and one of them fins a light each time. > But here's the really clever part: ordinarily fewer rays would result in a less realistic lighting, but since the bulk of the color of the frame's pixels are only affected by the primary rays, dumping most or all of the secondary ones doesn't affect things as much as one might think. I don't understand this either. This just sounds like raytracing without reflections. Can someone walk me through how the rendering of one pixel works in each case? I think the difference is how the secondary rays are generated, right?
- 0-_-0 4y ago
  A simplified definition could be: It's ray tracing if the ray direction is never chosen randomly, randomness (Monte Carlo integration) makes it path tracing.
- jasonwatkinspdx 4y ago
  This article is straight up bad. So, basic Whitted style ray tracer is, for each pixel, project a ray into the scene and see what the closest intersection is. Now shoot secondary rays at each light source to see if the intersection is in shadow for that light, sum the lighting accordingly. Also if the material hit is shiny, shoot a ray out using snells law and recurse to see what it sees. Now, with path tracing instead we approach the rendering problem more generally, and think of it as a 6D integral that describes all possible ways light can bounce in the scene. Then we sample this integral using monte carlo techniques. The most naive version of this would be to emit virtual photons from lights, trace where they go probabilistically using scattering equations at each surface interaction (so not just snells law) and then seeing if it ever blunders into the virtual camera. Obviously that's very inefficient, so practical path tracers work backwards tracing paths from the camera, or bidirectionally doing both and seeing if they can connect. Then there's a huge pile of techniques like importance sampling that help make all this more efficient. That said, at the end of the day, path tracing is much more computationally intensive than the classic ray tracer. However it's worth this because it can truly render all lighting in a physically correct way. Classic ray tracing bakes in assumptions about shadow rays and simple reflections, which is why images made with it have a very stark unrealistic appearance (think sphere and pyramid floating over a checkerboard style images).
ksec 4y ago
There is a reason why Techspot.com is not on my list of RSS feeds to read. It is also unfortunate most decent tech journalism is completely gone. I am not entirely sure if I should flag it, but at least the comments on HN are 100x better than the article. I would also not be surprised, if this isn't being dealt with early on, the word "Path Tracing" will become another marketing hype and being over used in every single internet comment, just like Apple's "* unified memory* " was some special memory built into the chip or worst SRAM cache inside the chip etc....
supernes 4y ago
Another somewhat recent technique for getting better results quicker is path guiding, as seen in e.g. Intel's OpenPGL: https://github.com/OpenPathGuidingLibrary/openpgl https://github.com/OpenPathGuidingLibrary/openpgl
JoeyBananas 4y ago
Path tracing is really just a different implementation of the same algorithm that uses more sophisticated numerical methods. Path tracing tends to be better because it is only the simple implementations that do not have to resort to path tracing techniques.
darkteflon 4y ago
As far as I understand it, the recent Portal with RTX is the first fully path-trace rendered game to market, (re)built with Nvidia’s RTX Remix. Is that correct? Does anyone know of any other examples?

75 points by alok-g 4y ago

Fascinating, and timely. Can anyone recommend a good write-up of UE’s Lumen specifically, preferably written for the interested layman?

dagmx 4y ago
https://advances.realtimerendering.com/s2022/index.html https://advances.realtimerendering.com/s2022/index.html This session has one of the best overviews of Lumen. The previous year has a really good overview of Nanite.
- darkteflon 4y ago
  Thanks for this. I read about a hundred pages of the (excellent) lecture on RTGI last night. SIGGRAPH stuff is a bit aspirational for me - feels just beyond what I’m able to follow. Appreciate if you or any other poster has something aimed a bit lower - ideally as simple as possible, but no simpler!
  - dagmx 4y ago
    Unfortunately, due to how new they are, there’s not much between these presentations and what the unreal docs present. The unreal docs are probably a little easier to grok https://docs.unrealengine.com/5.0/en-US/lumen-technical-details-in-unreal-engine/ https://docs.unrealengine.com/5.0/en-US/lumen-technical-deta... but they do leave a lot out. At their core, they’re also not that different than how REYES used to work with its micropolygon architecture and the way GI was bolted on. Given how old REYES is, you might find more reading material there.

zamadatix 4y ago

I recently watched https://youtu.be/gsZiJeaMO48 https://youtu.be/gsZiJeaMO48 which was a good visual+math resource into a more detailed gamut of path based rendering.

4RealFreedom 4y ago
That was really good. Thanks for posting it.

signaru 4y ago

besides tracing fewer rays, path tracing appears to have a "chiaroscuro" aesthetic to it. in moderation, absence of light can also be a good thing.

crote 4y ago
That is primarily a result of game designers not used to lighting for path tracing. In traditional rasterized games, the only thing that matters is whether the end result looks good. This means adding things like global illumination (a magical diffuse light source which lights up stuff regardless of position), or simply making some parts of a texture brighter to make it look as if a light source is shining on it. Things like shadows are mostly pre-baked into the textures, and primitive reflections can be faked by just mirroring whatever is already on the screen. Basically, fake it until you make it. With path tracing, the renderer follows the laws of physics. If something is lit up, the light actually has to come from somewhere. And as it turns out, most light will have hit multiple objects before finally ending up at the viewer. The artist now has to make a reasonably physics model for every single object in the game - even those the player might not directly look at. It's a completely different approach - made even worse because we aren't yet at a point where every gamer has a computer which can do 100% path tracing, so you still need to support traditional rasterization for people without bleeding-edge GPUs. To get an example of the visuals possible, look at modern cinema. Disney and Pixar movies are path traced, as is probably all CGI these days. I expect games to get a more diverse look over time, as artists get more experience with it.
- kroltan 4y ago
  I am assuming you are both talking about the comparisons in the article? They are mostly terrible examples of path tracing, as they just took the original map files with the lights authored for the original renderer, erased the baked lighting, and run the new renderer with those lights. So it's not that game designers are not used to lighting for path tracing, it's just that nobody designed it. Heck, even porting maps between two versions of the same lineage of offline raytracer can result in ridiculously different outputs: https://www.youtube.com/watch?v=2JkRwPWnL_c https://www.youtube.com/watch?v=2JkRwPWnL_c Among other things, these games did not have high dynamic range lighting at all, so light data can only ever make the picture darker than the base textures. (Think of it as a layer set to "multiply" blend mode in a photo editor) So making a light brighter at some point wouldn't make things look any closer to white, just making the falloff sharper. So most lights were authored to look good in the renderer, not make any actual physical sense, as you said. That said, this approach of "just swap out the renderer" could work much better for games that work on a physically-based rasteriser workflow (mostly newer stuff, like from around 2015 and onward), because they mostly already use compliant and realistic light sources, and the baked lights and rasterisation are "merely" for performance. (a.k.a. being a game and not a 2-day-per-frame art installation) If you want to see a ray-tracing-native game, take a look at Teardown (https://www.teardowngame.com/ https://www.teardowngame.com/), it does not exhibit any of the "chiaroscuro" described, and has perfectly cromulent lighting.

elihu 4y ago

> "So there you have -- path tracing, the fast cousin of ray tracing. Looks almost as good, works a heck of a lot quicker. " Yeah, that's pretty much exactly wrong. Path tracing exists not because it's faster (it isn't, except perhaps in some pathological conditions), it exists because there are certain lighting effects that standard recursive ray tracing doesn't handle at all, but path tracing does. Caustics, global illumination, subsurface scattering, etc... We could be using ray tracing for just about everything now, but we don't because it doesn't look very realistic. (Photon mapping can be used to create those lighting effects as well, but path tracing seems to have won out, being a bit less fiddly. With photon mapping you have to know sort of what you're going to be looking at in advance, whereas with path tracing you don't.) Path tracing can be very slow, but improvements in computation speed plus algorithmic tweaks to prune unnecessary work mean it can be sort of done in real time these days. One of the big differences between ray tracing and path tracing is that the former is deterministic, whereas the latter is probabilistic. Ray tracing just does a bunch of math until it arrives at the answer, but in path tracing the image quality depends on how much effort you put into it. If you use a few rays per pixel, you get a grainy image. If you use a lot of rays per pixel, you get something that's a lot smoother and clearer, but takes a long time to render. One of the big semi-recent advances is to use denoising algorithms. Instead of throwing a lot of compute cycles at the problem to trace lots of rays, you just render a noisy image and use some algorithm (perhaps based on machine learning, perhaps not) to smooth it out. So now instead of tracing 100 or 1000 rays per pixel to get something that looks good, you might only trace 10, or 2, or 1.

slavik81 4y ago
This article is also basically equivalent to "the median vs. the average." Just as the mean is not the only average, Whitted's algorithm is not the only ray tracing algorithm. Path tracing is itself a ray tracing algorithm.
- elihu 4y ago
  I think it's become kind of an ambiguous term that depends on context. If you're talking about algorithms, "ray tracing" usually means Whitted ray tracing, but it could also mean the whole family of algorithms that are based fundamentally on tracing rays, whether that's Whitted ray tracing, path tracing, photon mapping, metropolis light transport, etc... If you're talking about movies, ray tracing usually means path tracing these days. If you're talking about games, it probably means either path tracing or taking a conventional rasterization engine and bolting Whitted ray tracing on the side because they want realistic reflection and/or shadows. Companies that make GPUs advertise "ray tracing" as a hardware feature, because that's what the hardware does: it tests rays for intersection against some kind of bounding volume hierarchy. Whether software uses that for Whitted ray tracing or path tracing or something else is up to the application.

sorenjan 4y ago

> Traditional ray tracing involves calculating the exact path of reflection or refraction of each ray, and tracing them all the way back to one or more light sources. With path tracing, multiple rays are generated for each pixel but they're bounced off in a random direction. This gets repeated when a ray hits an object, and keeps on occurring until a light source is reached or a preset bounce limit is reached. I'm not following completely. Are they saying that raytracing only generates new rays in the reflection or refraction direction? The diagram seems to contradict that, there's three new rays generated at each surface for raytracing on that. Does pathtracing not take reflection and refraction into account at all? Does it only generate new rays in random directions to sample the incoming light? The diagram shows two new rays being generated at each surface, and one of them fins a light each time. > But here's the really clever part: ordinarily fewer rays would result in a less realistic lighting, but since the bulk of the color of the frame's pixels are only affected by the primary rays, dumping most or all of the secondary ones doesn't affect things as much as one might think. I don't understand this either. This just sounds like raytracing without reflections. Can someone walk me through how the rendering of one pixel works in each case? I think the difference is how the secondary rays are generated, right?

0-_-0 4y ago
A simplified definition could be: It's ray tracing if the ray direction is never chosen randomly, randomness (Monte Carlo integration) makes it path tracing.
jasonwatkinspdx 4y ago
This article is straight up bad. So, basic Whitted style ray tracer is, for each pixel, project a ray into the scene and see what the closest intersection is. Now shoot secondary rays at each light source to see if the intersection is in shadow for that light, sum the lighting accordingly. Also if the material hit is shiny, shoot a ray out using snells law and recurse to see what it sees. Now, with path tracing instead we approach the rendering problem more generally, and think of it as a 6D integral that describes all possible ways light can bounce in the scene. Then we sample this integral using monte carlo techniques. The most naive version of this would be to emit virtual photons from lights, trace where they go probabilistically using scattering equations at each surface interaction (so not just snells law) and then seeing if it ever blunders into the virtual camera. Obviously that's very inefficient, so practical path tracers work backwards tracing paths from the camera, or bidirectionally doing both and seeing if they can connect. Then there's a huge pile of techniques like importance sampling that help make all this more efficient. That said, at the end of the day, path tracing is much more computationally intensive than the classic ray tracer. However it's worth this because it can truly render all lighting in a physically correct way. Classic ray tracing bakes in assumptions about shadow rays and simple reflections, which is why images made with it have a very stark unrealistic appearance (think sphere and pyramid floating over a checkerboard style images).

ksec 4y ago

There is a reason why Techspot.com is not on my list of RSS feeds to read. It is also unfortunate most decent tech journalism is completely gone. I am not entirely sure if I should flag it, but at least the comments on HN are 100x better than the article. I would also not be surprised, if this isn't being dealt with early on, the word "Path Tracing" will become another marketing hype and being over used in every single internet comment, just like Apple's "* unified memory* " was some special memory built into the chip or worst SRAM cache inside the chip etc....

supernes 4y ago

Another somewhat recent technique for getting better results quicker is path guiding, as seen in e.g. Intel's OpenPGL: https://github.com/OpenPathGuidingLibrary/openpgl https://github.com/OpenPathGuidingLibrary/openpgl

JoeyBananas 4y ago

Path tracing is really just a different implementation of the same algorithm that uses more sophisticated numerical methods. Path tracing tends to be better because it is only the simple implementations that do not have to resort to path tracing techniques.

darkteflon 4y ago

As far as I understand it, the recent Portal with RTX is the first fully path-trace rendered game to market, (re)built with Nvidia’s RTX Remix. Is that correct? Does anyone know of any other examples?