There are a number of problems with this article. First, the way ray tracing is described is very odd. Rays aren't traced beginning from the light source that emitted them, but are shot from an "eye point" through a pixel on the screen and are <i>then</i> traced back to a light source (possibly with multiple bounces). Suppose all other operations are constant time, this yields a linear time rendering algorithm (linear with screen resolution). For some data structures this is ridiculously effective. The way it is described in the article is horribly inefficient. Not just that, it won't ever terminate since a light source theoretically emits an infinite number of rays that have to be traced. Infinite number of rays => Infinite time => algorithm never terminates. There are ways to solve that, yes, but in general rays are traced starting at the camera and <i>end</i> at the light source.<p>On to the paragraphs on photorealism. Yes, ray tracing won't solve this because you haven't even given it a problem yet. They're basically three paragraphs going on about how we don't know how to define photorealism. Yes, it is a bad term. Now, let me have a shot at defining realism in computer graphics: The easier I can mistake it for a real scene, the more realistic it is. What ray tracing does here is substantial! One of the main reasons why we can easily distinguish a computer generated scene (except for some scenes in movies nowadays that have been rendered off-line using thousands of hours of processor time) is lighting. We instinctively "feel" things that are odd about lighting. We're very sensitive to that. Ray tracing can provide better reflections and better shadows than almost any other rendering method and basically does them with just a couple of additional bounces. Given an efficient data structure this is one of the quicker ways to do real time lighting effects properly. To top that off, ray tracing can do proper refraction, proper ambient occlusion, interactive indirect illumination and a few other nice effects. Altogether this means one thing: stepping closer towards realism.<p>Concerning complexity, ray tracing itself doesn't offer a solution. As I've pointed out already, time complexity of ray tracing algorithms depends <i>heavily</i> on the data structures that are used for looking up collisions of rays with geometry. There are good ones, there are bad ones. What ray tracing does though is free occlusion. Only geometry that is visible is ever rendered. That is pointed out in the article as well. What rubs me the wrong way here is "it still has to navigate through the scene representation". Obviously that is true, but as I just said, a lookup algorithm is <i>not</i> part of ray tracing. RT merely paves the way to use good data structures with it. It's not a problem ray tracing can solve, because it is a <i>rendering algorithm</i>, not a data structure.<p>The scale problem with the stars. Well that is really a memory problem. Again, an efficient data structure will work no matter the spatial distance a ray has to travel. How are entire solar systems simulated? Well, on that scale you get away decently with not loading everything at once into memory and fetching data when needed. I suspect that this is exactly what is done with current approaches and there's nothing that prevents you from doing the same while ray tracing the scene.<p>Materials like aerogel or clouds are volumetric effects. Ray tracing is <i>perfect</i> for this. In fact, off line rendering uses ray tracing almost exclusively to perform those stunts.<p>The physics argument doesn't hold properly because it assumes that we've implemented the renderer on the CPU and are therefore eating processor time in big lumps. It would be suboptimal to implement the ray tracer on the CPU, because RAM access times are usually slower than video memory access times from the GPU. Since we're dealing with large amounts of data in all 3D processing, it's a <i>much</i> better choice to use CUDA, Stream or OpenCL to program the GPU to do the entire raytracing and merely use the CPU for occasionally shovel data into video memory. To top that off, ray tracing is easy to parallelize, since the algorithm operates the same for each screen pixel. Modern GPUs are bloody brilliant at that. Use them! This leaves some room to process physics on the CPU, as well as game logic, AI, event processing, network code, etc.<p>I don't really get the content argument either. The content has to be made <i>regardless of the rendering method</i>. It's the same content after all. How does ray tracing make "it worse"(sic)?<p>TL;DR: Ray tracing is not a solution to all our problems but a good step forwards in real time rendering. What's really keeping is from implementing it in commercial engines yet is that it's not easily compatible with the polygonal representation of geometry. <i>This</i> is the problem that we should actually be solving.<p>Oh and by the way, the link labelled with "boring" is actually pretty impressive and <i>far</i> above anything any real-time rendering engine available today produces.