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

41–50 of 69 posts

Re: John Carmack's Comment on Hardware Ray Tracing

#41

Post by ericmj »

yk wrote: post #27
InclinedPlane wrote: post #21

Earlier quoted context omitted.

This is indeed ray tracing's huge advantage, of being highly amenable to parallelization. However, the same thing is more or less equivalently true for other rendering methods, such as rasterization. Modern GPUs have thousands of rendering sub-unit "cores". And with CUDA you can use those cores for almost anything, including ray tracing. But for a given scene and a given amount of finite computing power you're almost…

I think that rasterization is easier to parallelize than ray tracing, since raster engines essentially multiply each vertex with the same matrix, while for ray tracing you have to traverse an octtree for each step in each ray. ( Both are of course easy to parallelize, I just think that in general you will run into memory bandwidth problems faster with ray tracing algos.)

Yes, memory bandwidth is one of the biggest slow downs of ray tracing. Rasterization access memory very linearly which makes it very easy to cache and easy to optimize in hardware on the GPUs. But ray tracing access memory very randomly, two rays originating from pixels next to each other easily diverges and so hits objects far from each other in the scene. This means that ray tracing will spend most of its time waiting for memory.

Re: John Carmack's Comment on Hardware Ray Tracing

#42

Post by dualogy »

daeken wrote: post #31
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!).

Sphere tracing is awesome. So many effects can be so easily and cheaply approximated, apart from soft shadows also subsurface scattering, bloom/glare etc. Downside, while great for geometry describable by distance fields, it's quite useless with polygonal assets...

Re: John Carmack's Comment on Hardware Ray Tracing

#43

Post by gavanwoolery »

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 triangles), just give me a really powerful, flexible parallel processor...even if that means sacrificing a bit of speed. I think above all Carmack would appreciate such hardware...there was a kind of beauty in his old code you don't find any more -- you can do lots of tricks with GPUs, but overall it is a much more limited, less creative programming experience.

Re: John Carmack's Comment on Hardware Ray Tracing

#44

Post by James_Duval »

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…

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?

Re: John Carmack's Comment on Hardware Ray Tracing

#45

Post by danwills »

gsg wrote: post #20
chii wrote: post #5

Having no real knowledge of ray tracing (or rendering for that matter), can someone tell me why we can't be moving towards a massive cluster of gpu (in the order of 10,000) ray tracing a scene in parellel? I imagine each ray trace call is quite independent of any other. SOooner or later, cpu (and gpu) will have many cores available for such form of rendering. Is it because of the chicken/egg problem?

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.

There are some tools that allow you to render a frame quickly by using many hosts to parallelise the task. This is usually only practical when the data that generates the frame is relatively small, in other words not gigabytes of fluid simulation voxels. It's also not realtime, by any stretch!

A renderfarm is usually not technologically any different to local rendering on a workstation. We generally don't parallelize across hosts within a single frame, but at least you can render lots of frames simultaneously!

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.

Re: John Carmack's Comment on Hardware Ray Tracing

#46

Post by Peaker »

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…

Typically limitations aid creativity, not hamper it.

Re: John Carmack's Comment on Hardware Ray Tracing

#47

Post by samwillis »

jamieb wrote: post #19

Here's a commercial, realtime raytracing tool. Runs happily on a dual-core macbook pro. No custom card needed. Yes, it runs better on a $20,000 64-thread Tigerton, but it will run usably on a laptop. http://www.youtube.com/watch?v=yUiLBmioRI4 Carmack is right about games (surprise!). I can't imagine "Imagination Technologies" is pushing the Caustic R2500 at games.

We use KeyShot at work and its an amazing package, its the industry standard now for rendering product design CAD. The demo video showing the Caustic card running is about equivalent to KeyShot running on a $3000 PC. They have a way to go until they convince me that they have anything better than what KeyShot is capable of.

Re: John Carmack's Comment on Hardware Ray Tracing

#48

Post by Tloewald »

InclinedPlane wrote: post #22
yk wrote: post #13

Earlier quoted context omitted.

I think people rather think of ray-tracing as much better motivated by physics ( and intuition) compared to all the complicated matrices in raster engines. Instead of thinking it is superior because of some demos.

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

Re: John Carmack's Comment on Hardware Ray Tracing

#49

Post by Tloewald »

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

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.

Re: John Carmack's Comment on Hardware Ray Tracing

#50

Post by Keyframe »

As anyone who ever wrote a raytracer would know (or find out soon): Primary rays cache. Secondary rays trash! Brazil guys wrote a decent raytracer (entirely based on Glassner's book) and are really competent devs in general (both of them). Current state of the art, performance oriented, offline renderer is Arnold by SolidAngle, with more smart guys behind it. I think we will see convergence of offline and online RT soon enough. There are already steps being made in that direction, in offline world, towards RT previews.
Post reply on HN