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

John Carmack's Comment on Hardware Ray Tracing

arstechnica.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: John Carmack's Comment on Hardware Ray Tracing

#31

Post by daeken »

ianb wrote: post #28

"For example, all surfaces that are shaded with interpolated normal will have an unnatural shadow discontinuity at the silhouette edges with single shadow ray traces." For some reason I really want to understand what this sentence means. I don't know why it jumped out at me, maybe because it seems both accessible and arcane, I want some path to even just tour the arcane concerns of someone so deep into a (this) parti…

In English: if you're only using one ray for shading, then you'll have areas that are completely in shadow directly next to areas that are completely not in shadow; what we call hard shadows. Soft shadows are a better approximation of reality, because they show the shades of grey between "covered" and "uncovered", but they require more ray intersections (unless you're using sphere tracing!).

Re: John Carmack's Comment on Hardware Ray Tracing

#32

Post by [deleted] »

ianb wrote: post #28

"For example, all surfaces that are shaded with interpolated normal will have an unnatural shadow discontinuity at the silhouette edges with single shadow ray traces." For some reason I really want to understand what this sentence means. I don't know why it jumped out at me, maybe because it seems both accessible and arcane, I want some path to even just tour the arcane concerns of someone so deep into a (this) parti…

[deleted]

Re: John Carmack's Comment on Hardware Ray Tracing

#33

Post by Tuna-Fish »

yk wrote: post #15
ChuckMcM wrote: post #12

Earlier quoted context omitted.

Pretty much agree, the only thing that we might disagree on is the 'billions' number, while I expect good ray tracing to trace billions of rays, if transistors are cheap enough this becomes more interesting. The typical HDMI 1080p display is 2 megapixels (or megatexels) if you have a rendering engine with 2,073,600 cores each of which is looking at a billion ray 'view' based on where it sits in the scene, its easier…

Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm. For almost all scenes you get better results with rasterization, the two exceptions I can think of is scenes where the geometry of light rays is not flat, so for example involving lenses or black holes, or where there is a lot more optical complexity than you can reasonably use. ( A forest where eac…

> Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm

Actually, it will when the complexity classes of the algorithms differ. Which is true in this case -- the time taken to ray trace a scene rises as the log(n) of the size of that scene, while the time taken to rasterize rises linearly with regards to the scene.

There exists a threshold of computing power/scene complexity above which raytracing beats rasterization in speed. However, like Carmack pointed out, the constant factors are massive, so this won't be reached in the near future, if ever.

The reason the constant factors are so huge is that complexity of raytracing rises linearly with the count of pixels to be drawn, while in rasterization a lot of the work can be shared by neighbouring pixels.

Intriguingly, this means that if you can reduce the pixel counts, you can vastly improve the value of raytracing.

Notably, if you can do eye tracking and rendering in less than 15ms, you can reach the same visual quality as a full-screen, high-resolution render by rendering only the areas you are actually looking at in high resolution, and rendering the rest of the scene at a progressively lower resolution farther from the focus point. The cone of high-precision vision is surprisingly small, something like tens of pixels when looking at a screen from a normal viewing distance. If you did this, you should be able to cut the amount of rays you need to send by at least two orders of magnitude, which would bring raytracing to real-time quality on modern hardware.

Re: John Carmack's Comment on Hardware Ray Tracing

#34

Post by yk »

willvarfar wrote: post #25
yk wrote: post #23

Earlier quoted context omitted.

Yes, but it perhaps more instructive to think of a curved mirror. In case of a raster engine, you need to calculate a texture for every triangle of the mirror. ( Which is essentially the same as rendering the scene in the first place.) On the other hand for a ray tracing engine you just need to reflect one ray on the mirror surface for every pixel the mirror occupies in the final rendering. So compared to the same sc…

I think John says not just one ray per pixel?

Yes, I was essentially using one ray per pixel as shorthand for constant amount of rays per pixel. (As in 'I did not think about that point.') One needs more than one to avoid creating artifacts like aliasing ( see [1] for a very nice example), or depending on how 'naive' or complex the algorithm is for stuff like shadows or caustics. But for nice scenes (which do not create artifacts) with mirrors and lenses, one ray per pixel would work fine.

[1] https://en.wikipedia.org/wiki/Aliasing

Re: John Carmack's Comment on Hardware Ray Tracing

#35

Post by yk »

Tuna-Fish wrote: post #33
yk wrote: post #15

Earlier quoted context omitted.

Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm. For almost all scenes you get better results with rasterization, the two exceptions I can think of is scenes where the geometry of light rays is not flat, so for example involving lenses or black holes, or where there is a lot more optical complexity than you can reasonably use. ( A forest where eac…

> Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm Actually, it will when the complexity classes of the algorithms differ. Which is true in this case -- the time taken to ray trace a scene rises as the log(n) of the size of that scene, while the time taken to rasterize rises linearly with regards to the scene. There exists a threshold of computing…

Yes, as I pointed out in the last sentence, perhaps I should have put a big-O somewhere into it. Do you have a link on the eye tracking/rendering combo? That technique sounds rather fascinating.

Re: John Carmack's Comment on Hardware Ray Tracing

#36

Post by kybernetikos »

ianb wrote: post #28

"For example, all surfaces that are shaded with interpolated normal will have an unnatural shadow discontinuity at the silhouette edges with single shadow ray traces." For some reason I really want to understand what this sentence means. I don't know why it jumped out at me, maybe because it seems both accessible and arcane, I want some path to even just tour the arcane concerns of someone so deep into a (this) parti…

Typically when ray tracing you follow one (or more) rays from the eye through a pixel on the screen until it hits something. Then you have to decide what that point on the surface of thing it hits should look like. Usually this breaks down into a combination of how much ambient light you're simulating, the material properties of the surface, the results of any reflection/refraction rays you fire off, and the effect of light sources on it.

The simplest way to calculate the light sources is to follow another ray to each of your light sources, and if there's nothing in the way, you add the intensity of that light to the pixel.

The problem with this simple approach is that something is either blocking your path to the light source or it isn't, which creates absolutely sharp shadows because it's simulating the lights as if all the light's brightness is emanating from a single infinitesimal point.

In real life, lights tend not to be like that.

To get realistic looking shadows with ray tracing you have to send multiple rays to different parts of each of your lights, adding a portion of the lights brightness each time (you're essentially doing a monte carlo integration over the area of the light). The more you do, the better looking shadow edges you can get, but also the more effort you have to spend in calculating.

Raytracing is rather fun because you can get really interesting results with relatively little code and it's very visual - you actually see your bugs. Some people do simple ray tracers as katas. I did a basic one as a way of learning Scala. If you're interested in having a look it's here (very simple of course - I do treat my light sources as points): https://github.com/kybernetikos/ScalaTrace/wiki/ScalaTrace

Re: John Carmack's Comment on Hardware Ray Tracing

#37

Post by bcoates »

Tuna-Fish wrote: post #33
yk wrote: post #15

Earlier quoted context omitted.

Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm. For almost all scenes you get better results with rasterization, the two exceptions I can think of is scenes where the geometry of light rays is not flat, so for example involving lenses or black holes, or where there is a lot more optical complexity than you can reasonably use. ( A forest where eac…

> Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm Actually, it will when the complexity classes of the algorithms differ. Which is true in this case -- the time taken to ray trace a scene rises as the log(n) of the size of that scene, while the time taken to rasterize rises linearly with regards to the scene. There exists a threshold of computing…

Is raytracing still linear with pixel count if you're doing something like Metropolis light transport to get global illumination effects?

Re: John Carmack's Comment on Hardware Ray Tracing

#38

Post by ohwp »

I think path tracing is one of the most promising methods for realtime ray tracing.

Brigade is one example: http://igad.nhtv.nl/~bikker/ Here an in-game example: http://www.youtube.com/watch?v=6_DrgiwLABk

And a nice blog with posts about Brigade, Octane and others: http://raytracey.blogspot.nl/

Re: John Carmack's Comment on Hardware Ray Tracing

#39

Post by hayksaakian »

damian2000 wrote: post #4
hayksaakian wrote: post #2

Its so cool that someone as high up in the games industry as carmack actually knows his technical shit.

He might be high up now, but he started off as a programmer. He co-founded id software and (along with others) developed Wolfenstein 3D, Doom, etc. http://en.wikipedia.org/wiki/Id_Software

I was aware of this, but Mark Z. Also started in the programming, today he's mister CEO, too important for code.

Re: John Carmack's Comment on Hardware Ray Tracing

#40

Post by ericmj »

bcoates wrote: post #37
Tuna-Fish wrote: post #33

Earlier quoted context omitted.

> Throwing more ( or finer etched) silicon at an algorithm will not help the algorithm, compared to a superior algorithm Actually, it will when the complexity classes of the algorithms differ. Which is true in this case -- the time taken to ray trace a scene rises as the log(n) of the size of that scene, while the time taken to rasterize rises linearly with regards to the scene. There exists a threshold of computing…

Is raytracing still linear with pixel count if you're doing something like Metropolis light transport to get global illumination effects?

Yes. But the "constant factor" will be very large, even larger than for traditional ray tracing, for some global illumination algorithms, even when you chose to only render a small part of the scene. For example photon mapping requires a pre-pass where you trace photons from the light source onto the scene, that means that reducing the pixel count doesn't decrease the time for the pre-pass. http://en.wikipedia.org/wiki/Photon_mapping
Post reply on HN