Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Path Tracing vs. Ray Tracing (2016)

dusterwald.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Path Tracing vs. Ray Tracing (2016)

#21

Post by zamadatix »

jcfrei wrote: 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.

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.

Re: Path Tracing vs. Ray Tracing (2016)

#22

Post by thedaemon »

jcfrei wrote: 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 is much more to a game engine than rendering graphics. Networking, input handling, ai, collision, all kinds of stuff.

Re: Path Tracing vs. Ray Tracing (2016)

#23

Post by blooop »

GolDDranks wrote: post #5

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

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

Re: Path Tracing vs. Ray Tracing (2016)

#24

Post by pzone »

wheelie_boy wrote: post #12
berkut wrote: 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...

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.

Re: Path Tracing vs. Ray Tracing (2016)

#25

Post by atq2119 »

pasta wrote: post #14
peterbraden wrote: post #10

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…

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

Re: Path Tracing vs. Ray Tracing (2016)

#26

Post by pcwalton »

tinymint wrote: post #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…

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

Re: Path Tracing vs. Ray Tracing (2016)

#27

Post by tossandturn »

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

Re: Path Tracing vs. Ray Tracing (2016)

#28

Post by pcwalton »

GolDDranks wrote: post #5

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

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

Re: Path Tracing vs. Ray Tracing (2016)

#29

Post by kllrnohj »

jcfrei wrote: 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.

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?

Re: Path Tracing vs. Ray Tracing (2016)

#30

Post by TheLoneAdmin »

tinymint wrote: post #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…

> You can use Russian roulette techniques

Did you mean Monte Carlo?

Post reply on HN