5 ms·
> "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 w
by 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 agoThis 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 agoI 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.
- jasonwatkinspdx 4y agoI was skimming this years Siggraph papers a bit ago and all the work on neural representations really made an impression. I think we'll see big jumps from integrating these into path tracers.
- elihu 4y agoI haven't kept up the latest in graphics research. Is the idea that you have a machine-learning system that learns a sort of rough internal representation of the 3D model based on the rendered image (or multiple successive images), and then uses that to help denoise, or interpolate features that are missing from the original dataset? Something I've wondered about is whether these denoising algorithms are always purely used as a last stage of post-processing at the end of the graphics pipeline, or whether they're able to, in effect, go back and say "hey, this area right here I'm pretty uncertain about, so I think we should trace some more rays" and so you might go back and forth between the raytracing engine and the denoising engine a couple times before you get a final image. It seems like the latter could be pretty effective.
- jasonwatkinspdx 4y agoSo here's the paper that got everyone fired up: https://www.matthewtancik.com/nerf https://www.matthewtancik.com/nerf My very short summary: Let's model the scene as a function (x,y,z,u,v)->(R,G,B,d). That is for a given ray origin and direction, give us the corresponding radiance and density. Take a deep network, and train it to approximate this function on a scene produced from renderings or video/photos. Now you can use techniques from volumetric rendering (ray marching as used for clouds and such) to render novel views of the scene. I'd really suggest watching the video part way down the page though. These representations do shockingly good at occlusion, which is the difficult problem in rendering. I think this paradigm opens up a lot of interesting possibilities. The elephant in the room is training time, but with good enough compositing of static assets this could still make sense. The trained models are extremely compact. Edit: Oh forgot your second idea. With offline path tracers there are techniques like that. The most elegant is perhaps Metropolis Light Transport, which uses a random walk through the space of possible paths, adjusting step size based on how "interesting" the region its in is. There's also Importance Sampling... lots and lots of ideas in the research literature. But also for cinema rendering a lot of the time it's just "oh we shoot 64 paths per pixel no matter what" because that produces very even noise grain and very good antialiasing. If you use some technique that has temporal biases about noise across sequences of frames it tends to get picked up by the viewer easily.