This reminds me of http://en.wikipedia.org/wiki/Euclideon ... Not trying to draw a comparison, i just find these "future of gaming" technologies interesting, vapor or not.
John Carmack's Comment on Hardware Ray Tracing
61–69 of 69 posts
Re: John Carmack's Comment on Hardware Ray Tracing
#62Earlier 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…
When CPUs have millions of cores and cost next to nothing to produce, the superior algorithm may be the one which scales linearly with parallel hardware. He mentions the problem of the log2 vs linear with rasterization, but that's just moving the log2 problem to hardware. Ray casting may still win out due to it's simplicity of throwing more hardware at it.
Re: John Carmack's Comment on Hardware Ray Tracing
#63Within his comment is a great example / reminder to consider constant factors when doing your 'big-oh' analysis of different approaches to a problem.
""" Because ray tracing involves a log2 scale of the number of primitives, while rasterization is linear, it appears that highly complex scenes will render faster with ray tracing, but it turns out that the constant factors are so different that no dataset that fits in memory actually crosses the time order threshold. """
Re: John Carmack's Comment on Hardware Ray Tracing
#64Earlier quoted context omitted.
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…
> I suspect this would look highly unnatural in practice
In pair tests test subjects were unable to see a difference between the foveated image and the normally rendered one. The flicker can be removed by blurring the image to the point where flicker no longer exists. Because your brain is used to a very low sampling rate outside the fovea, it actually helps in hiding the artifacts, because they occur naturally in your vision.
Re: John Carmack's Comment on Hardware Ray Tracing
#65I 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.
Check out his QuakeCon keynote. It's basically him talking for an hour about technical things that interest him.
Re: John Carmack's Comment on Hardware Ray Tracing
#66I 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.
Yes, GPUs are becoming increasingly flexible, but they are still limited by CPU-GPU bottleneck, GPU memory (which for the most part has been limited to 2 GB per card), really poor branching performance and limited ability to modify data in any other way than 1:1 correspondence. They are first and foremost designed to pump out polygons at high fill rates, which is fine unless you want to do some untraditional rendering or computation. :) Again, CUDA and OpenCL are paving the way for a new path, but I still think we should be using general purpose silicon underneath it instead of hardware designed to to do things like MSAA, interpolation, triangle setup, etc.
Re: John Carmack's Comment on Hardware Ray Tracing
#67I 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.
Limitations force you to come up with creative solutions to problems that should have been easier in the first place. :) But sometimes limitations force you to focus on the important things (if you could render absolutely anything, you could spend forever building an engine instead of a game).
Re: John Carmack's Comment on Hardware Ray Tracing
#68Earlier quoted context omitted.
Typically limitations aid creativity, not hamper it.
Limitations force you to come up with creative solutions to problems that should have been easier in the first place. :) But sometimes limitations force you to focus on the important things (if you could render absolutely anything, you could spend forever building an engine instead of a game).
I think sometimes the creative solutions end up being better than the simple "obvious" solutions that were apparent before the limitations were put in place.
Re: John Carmack's Comment on Hardware Ray Tracing
#69Earlier quoted context omitted.
> 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.
Yes, GPUs are becoming increasingly flexible, but they are still limited by CPU-GPU bottleneck, GPU memory (which for the most part has been limited to 2 GB per card), really poor branching performance and limited ability to modify data in any other way than 1:1 correspondence. They are first and foremost designed to pump out polygons at high fill rates, which is fine unless you want to do some untraditional renderin…
Sure, but I still believe it's far closer to the ideal parallel hardware than this n-core-shared-memory business that is really hard to program well.