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

51–60 of 69 posts

Re: John Carmack's Comment on Hardware Ray Tracing

#51

Post by mynameismiek »

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

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.

Its called Foveated Rendering (http://research.microsoft.com/apps/pubs/default.aspx?id=1766...) and is based on foveated imaging (http://en.wikipedia.org/wiki/Foveated_imaging).

Re: John Carmack's Comment on Hardware Ray Tracing

#52

Post by raverbashing »

Tloewald wrote: post #48
InclinedPlane wrote: post #22

Earlier quoted context omitted.

An even more physics based rendering method is called radiosity, but it's also hugely computationally intensive.

Physically Based Rendering - often GPU accelerated - is the new thing -- check out Octane Renderer, Lux-Render, Indigo, the Cycles renderer in Blender. These renderers start at the light source and stochastically generate and follow photons. Like a digital camera they suffer from noise :-)

"These renderers start at the light source and stochastically generate and follow photons."

Yes, that's similar to ray tracing, but going 'backwards'

Rasterizing is certainly faster, requiring more work in the 'intelligence' of scene assembly.

With raytracing (or physics rendering) you have lights, objects 'naturally interacting' with each other so shadows, reflection, radiosity comes ""automatically"" (still hard to do)

With rasterizing you have triangles with different colors, and it's up to you to paint them accordingly.

Re: John Carmack's Comment on Hardware Ray Tracing

#53

Post by MrScruff »

Tloewald wrote: post #49
danwills wrote: post #45

Earlier quoted context omitted.

I work in the VFX industry, and I agree. We often need to make a choice between a rasterisation-like method - which in VFX usually means micropolygon rendering like Pixar's REYES algorithm - or a raytracing-based method, like SideFX Mantra's Phsically-Based-Rendering. It is also possible to hybridize the two, which usually means casting rays in order to shade micropolygons. Both approaches have their own advantages.…

Minor note: as far as I am aware (i do not write 3d engines for a living but have written games and small 3d libraries for my own use) instancing works fine with both (all?) rendering approaches in just the same way.

The benefits of instancing are felt more keenly in ray tracing because of the need to keep geometry in memory. If you're just dealing with direct lighting it's very easy to load and discard geometry as required as you rasterize the frame. One you start casting secondary rays you end up having to keep more of the scene in memory in order to shade a particular surface, since the lighting contribution from other geo can't be localised.

Re: John Carmack's Comment on Hardware Ray Tracing

#54

Post by duaneb »

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

Naive question: Does your last paragraph have any implications for VR? Could something like the Oculus Rift benefit from raytracing technology? Or have I misunderstood what you are saying?

The idea is that raytracing can degrade gracefully, so there's a sliding scale between rendering time and rendering quality for every pixel. And yes, this means that, theoretically, the computer could naturally degrade pixels that you're not currently looking at.

I suspect this would look highly unnatural in practice, though, as even static scenes would flicker and change, especially with reflections and any surface or technique that uses random sampling methods (which is virtually every algorithm that is both fast and looks good).

Re: John Carmack's Comment on Hardware Ray Tracing

#55

Post by duaneb »

danwills wrote: post #45
gsg wrote: post #20

Earlier quoted context omitted.

Ray tracing enjoys a ridiculous amount of inherent parallelism. That's not much of an advantage though, since rasterisers also enjoy a ridiculous amount of inherent parallelism. Large scale "render farms" that exploit both already exist and are in commercial use in the VFX industry.

I work in the VFX industry, and I agree. We often need to make a choice between a rasterisation-like method - which in VFX usually means micropolygon rendering like Pixar's REYES algorithm - or a raytracing-based method, like SideFX Mantra's Phsically-Based-Rendering. It is also possible to hybridize the two, which usually means casting rays in order to shade micropolygons. Both approaches have their own advantages.…

> Another thing that doesn't seem to have been mentioned on this post is that raytracing can be accelerated massively (where applicable) by using instancing. A single object can be used many times in a scene, only differing in its transformation. This allows the geometry to be stored in ram once and re-used, incoming rays that are incident on an instance's bounding box can simply be transformed into the local space of the instance. Of course this is of no help in an extremely complex scene full of unique objects, but in practice you can make great savings (and create very complex scenes that are cheap to raytrace) this way.

You're also forgetting about the flip-side. A classic benefit of scanline renderers was that a scene could be split into multiple parts, which (via a z-buffer) could then be combined without any further rendering. A raytracer, on the other hand, has to have access to the whole scene (if you consider reflections, which make culling objects essentially impossible) to calculate any given pixel sample.

I don't know whether this is still an issue, but for a while it was a barrier to raytracing scenes on a Pixar level.

Re: John Carmack's Comment on Hardware Ray Tracing

#56

Post by duaneb »

gavanwoolery wrote: post #43

I think he is not wrong at all, but personally, I've been on both sides of the debate, and then I kind of formed the opinion that it's not worth debating about. The one thing I would strongly, strongly push for is general purpose hardware (we are kind of headed in that direction with OpenCL and CUDA, but industry-wide interest in these things is really low). Don't force me to use rasterization or raytracing (or even…

> just give me a really powerful, flexible parallel processor

Isn't that exactly what a GPU is? They aren't terribly fantastic at traditional computation, but then again we're talking parallelism here.

Re: John Carmack's Comment on Hardware Ray Tracing

#57

Post by yk »

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

Naive question: Does your last paragraph have any implications for VR? Could something like the Oculus Rift benefit from raytracing technology? Or have I misunderstood what you are saying?

I only skimmed the paper referenced below [1]. But what I understand at the moment is, that you essentially measure the area of the screen where high quality is important (using an eye tracker). And with this you can allocate your resources better. The downside is, that the rendering looks rather strange for anyone who looks on it without proper alignment of the high quality region. So VR goggles seem to be a good candidate for the technology, if they include an eye tracker, because they guarantee a single viewer and provide a frame to attach the eye tracker.

[1] http://research.microsoft.com/apps/pubs/default.aspx?id=1766... thanks mynameismiek

Re: John Carmack's Comment on Hardware Ray Tracing

#59

Post by yk »

dualogy wrote: post #30
cmccabe wrote: post #14

Earlier quoted context omitted.

Rasterization also requires "acceleration structures," kept in memory. I could be wrong here, but I think the point John was trying to make was that there was again a constant factor handicapping ray-tracing. But constant factors are, well, constant, and in 2050 we may well have ray-tracing done in hardware delivering scenes that are indistinguishable from reality. I wrote a ray tracer once, but it was primitive. So…

> Rasterization also requires "acceleration structures," kept in memory Yeah but surely not for the geometry itself. In rasterization, we may use simple low-overhead acc. structures to efficiently traverse a relevant sub-set of the whole (but coarsely described) scene for some fancy culling, collision detection (OK that's not really rendering ) ... but geometry (vertices, polygons, vertex attributes) does not need to…

> This would also require a high dynamic range output device. Looking directly into perfectly raytraced sunlight still won't glare and blind me like the real world does, but indeed, by 2050...

You could try to look directly into a beamer instead of onto the screen, if glare is all you want. ( And by 2050 I would suspect that the scene is directly copied into the frontal lobe, bypassing the visual cortex.)

Re: John Carmack's Comment on Hardware Ray Tracing

#60

Post by jerf »

javanix wrote: post #58

I wish I could sit down and talk with him for an hour or so. I'm a Unix programmer but I suspect I could learn as much from him about software design as from weeks of talking with just about anyone else.

Here's a link you may enjoy: http://news.ycombinator.com/item?id=3388290 , which goes to http://www.altdevblogaday.com/2011/12/24/static-code-analysi... .
Post reply on HN