Live data from Hacker News

Path Tracing vs. Ray Tracing (2016)

dusterwald.com

11–20 of 34 posts

Re: Path Tracing vs. Ray Tracing (2016)

#11

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...

Re: Path Tracing vs. Ray Tracing (2016)

#12
post #8

A bit outdated, and not entirely accurate, at least for film VFX... 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…

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...

Re: Path Tracing vs. Ray Tracing (2016)

#13

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.

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

Re: Path Tracing vs. Ray Tracing (2016)

#14

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.

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.

Re: Path Tracing vs. Ray Tracing (2016)

#15
> 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.

Re: Path Tracing vs. Ray Tracing (2016)

#16
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?

Re: Path Tracing vs. Ray Tracing (2016)

#17
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.

Re: Path Tracing vs. Ray Tracing (2016)

#18
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)

Re: Path Tracing vs. Ray Tracing (2016)

#19

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 bo…

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.

Re: Path Tracing vs. Ray Tracing (2016)

#20
post #17

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.

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.

Post reply on HN