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

Ray Tracing Essentials, Part 1: Basics of Ray Tracing

news.developer.nvidia.com

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#31

Post by logfromblammo »

datashow wrote: post #3

Interesting video. I didn't get how the Ray casting process formulates the final picture in the eye.

There's a point in space that represents the lens of the observer's eye, and a rectangle in space that represents the viewport. This rectangle is divided into pixel-equivalent square areas. For each area, a sampling of one or more rays is drawn from the lens point through the bounds of the area, until it encounters a surface of the scene. At that point, the material rules of the surface might generate another ray for specular reflection, a cone for diffuse reflection, another ray for refraction, and also add the emissive light value from that material. If the specular or diffuse reflections encounter a light source or ambient light, they add some of that light to the pixel-equivalent.

The diffuse cones send out a sampling of rays and attenuate the light from the light source, based on how many of those rays hit it, instead of some other object.

Instead of drawing light onto the scene and calculating how much passes through the viewport to the lens, ray-tracing cheats by working backwards, because photons traveling backward in time follow exactly the same rules as those traveling forward in time. Every photon that can travel backwards in time from the eye to hit a light source must have emanated from a light source with exactly the right direction and polarization to enter the eye. So the only photons calculated are the ones that contribute to the scene as viewed by the eye.

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#32

Post by daniel-thompson »

BubRoss wrote: post #16
pests wrote: post #15

Earlier quoted context omitted.

I was reading through and noticed he does not normalize his vectors for (so far) things like ray direction or surface normals for lighting. He does give warnings but I'm curious what type of bugs or rendering issues will manifest from this decision?

Incorrect results will manifest. If you take the dot product of a surface normal and another vector and they aren't the same length, the dot product will be distorted by the lengths of the vectors. Ray direction and ray length might be combined into one vector that just stretches from the origin for ray tracing, but using the direction with a surface normal for dot products, reflection vectors etc. is going to give a…

What you say is true; however, not automatically normalizing ray directions after transformation can be useful in some cases, e.g. to avoid introducing floating point error when calculating points from t values.

See http://www.pbr-book.org/3ed-2018/Shapes/Spheres.html#Surface..., the paragraph beginning "A natural question to ask..."

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#33

Post by sbeckeriv »

dkersten wrote: post #21
Buttons840 wrote: post #10

Earlier quoted context omitted.

It is a great project for learning a new language. I used it to practice Rust. You get to implement vectors, with basic operations on them, this gives you a chance to practice some abstractions. It's also good to create some unit tests to ensure your vector operations are correct. There's also good reason to parallelize your code and perform benchmarks. Abstractions, unit tests, parallelism, benchmarks, you have an e…

Oh, that’s a great idea! The main reason I still haven’t learned Rust is I didn’t have a project to use with it, but this tutorial is something else I’ve wanted to do, so it’s a perfect match.

I love seeing this book listed. I picked it up 4ish years ago while learning Rust. I was converting the code to Rust and I found a small bug[1] because I could not convert the code as it was. Peter was amazingly responsive and encouraging. I highly recommend this and the second second book.

[1] https://github.com/RayTracing/raytracing.github.io/blob/7e2a...

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#34

Post by BubRoss »

daniel-thompson wrote: post #32
BubRoss wrote: post #16

Earlier quoted context omitted.

Incorrect results will manifest. If you take the dot product of a surface normal and another vector and they aren't the same length, the dot product will be distorted by the lengths of the vectors. Ray direction and ray length might be combined into one vector that just stretches from the origin for ray tracing, but using the direction with a surface normal for dot products, reflection vectors etc. is going to give a…

What you say is true; however, not automatically normalizing ray directions after transformation can be useful in some cases, e.g. to avoid introducing floating point error when calculating points from t values. See http://www.pbr-book.org/3ed-2018/Shapes/Spheres.html#Surface... , the paragraph beginning "A natural question to ask..."

I literally gave using the non normalized ray for ray tracing as an example.

(Also in practice floating point inaccuracy doesn't become a huge problem since you have to design around floats not being exact in the first place. Spheres can also wind up being more finnicky with precision but are rarely used as primitives to trace against in production renderers. There isn't a single right way to do the tracing, but the shading does need normalized vectors for a lot of common operations.)

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#35

Post by hellofunk »

BubRoss wrote: post #34
daniel-thompson wrote: post #32

Earlier quoted context omitted.

What you say is true; however, not automatically normalizing ray directions after transformation can be useful in some cases, e.g. to avoid introducing floating point error when calculating points from t values. See http://www.pbr-book.org/3ed-2018/Shapes/Spheres.html#Surface... , the paragraph beginning "A natural question to ask..."

I literally gave using the non normalized ray for ray tracing as an example. (Also in practice floating point inaccuracy doesn't become a huge problem since you have to design around floats not being exact in the first place. Spheres can also wind up being more finnicky with precision but are rarely used as primitives to trace against in production renderers. There isn't a single right way to do the tracing, but the…

> Spheres can also wind up being more finnicky with precision but are rarely used as primitives to trace against in production renderers.

I've never heard this before! Interesting. Why is this?

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#36

Post by dahart »

hellofunk wrote: post #35
BubRoss wrote: post #34

Earlier quoted context omitted.

I literally gave using the non normalized ray for ray tracing as an example. (Also in practice floating point inaccuracy doesn't become a huge problem since you have to design around floats not being exact in the first place. Spheres can also wind up being more finnicky with precision but are rarely used as primitives to trace against in production renderers. There isn't a single right way to do the tracing, but the…

> Spheres can also wind up being more finnicky with precision but are rarely used as primitives to trace against in production renderers. I've never heard this before! Interesting. Why is this?

It's because tracing a sphere is quadratic equation solve. The guy in the video, Eric Haines, published an article about how to improve sphere tracing precision. It's in the freely available Ray Tracing Gems book.

https://link.springer.com/content/pdf/10.1007%2F978-1-4842-4...

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#37

Post by daniel-thompson »

hellofunk wrote: post #35
BubRoss wrote: post #34

Earlier quoted context omitted.

I literally gave using the non normalized ray for ray tracing as an example. (Also in practice floating point inaccuracy doesn't become a huge problem since you have to design around floats not being exact in the first place. Spheres can also wind up being more finnicky with precision but are rarely used as primitives to trace against in production renderers. There isn't a single right way to do the tracing, but the…

> Spheres can also wind up being more finnicky with precision but are rarely used as primitives to trace against in production renderers. I've never heard this before! Interesting. Why is this?

Spheres are the "hello world" shape of ray tracing, but are generally not used for production renderers for the following reasons: Spheres are not that interesting to render, because hardly anything in the real world is a perfect sphere; and determining a ray-sphere intersection point requires solving at least one quadratic equation, which requires a square root, which is slow

Triangle meshes are better choices for the same reasons: they can be used to model arbitrarily complex shapes, and it's faster to compute ray-triangle intersections.

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#38

Post by datashow »

logfromblammo wrote: post #31
datashow wrote: post #3

Interesting video. I didn't get how the Ray casting process formulates the final picture in the eye.

There's a point in space that represents the lens of the observer's eye, and a rectangle in space that represents the viewport. This rectangle is divided into pixel-equivalent square areas. For each area, a sampling of one or more rays is drawn from the lens point through the bounds of the area, until it encounters a surface of the scene. At that point, the material rules of the surface might generate another ray for…

Thanks. I think I got most of what you described.

If I understand it correctly:

1) a point / pixel in the scene (as viewed by the eye) sends out a cone of rays, and the final color of this pixel is a combination of what those rays hit. This is the ray casting process, the reverse of light traveling.

2) the overall picture of the scene is the combination of pixels each calculated by the above ray casting process.

Am I right?

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#39

Post by mattpharr »

falcolas wrote: post #4

Dear NVidia, While I and many others appreciate the quality of your video, in an age where people are distributing ray-tracing code on business cards, there’s not a ton of value in producing even more “Basics” or “Essentials” of ray tracing educational material. What would provide most of us with interest in ray tracing real value is expanding on the territory covered by the PBRT book, making the material it covers m…

Workin' on it. :-)

Note that the third edition came out roughly 5 years ago now, not 10.

Re: Ray Tracing Essentials, Part 1: Basics of Ray Tracing

#40

Post by logfromblammo »

datashow wrote: post #38
logfromblammo wrote: post #31

Earlier quoted context omitted.

There's a point in space that represents the lens of the observer's eye, and a rectangle in space that represents the viewport. This rectangle is divided into pixel-equivalent square areas. For each area, a sampling of one or more rays is drawn from the lens point through the bounds of the area, until it encounters a surface of the scene. At that point, the material rules of the surface might generate another ray for…

Thanks. I think I got most of what you described. If I understand it correctly: 1) a point / pixel in the scene (as viewed by the eye) sends out a cone of rays, and the final color of this pixel is a combination of what those rays hit. This is the ray casting process, the reverse of light traveling. 2) the overall picture of the scene is the combination of pixels each calculated by the above ray casting process. Am I…

Yes. The problem with working backwards is that some optical calculations have probability elements. A photon that hits a half-silvered mirror has a 50% chance of (specular) reflecting and a 50% chance of transmitting.

So for ray-tracing, you calculate along both paths and give 50% weight to each. Every time a ray hits a triangle in the scene, the material properties determine how the various components sum up to determine the color of the pixel.

Post reply on HN