You are right. The author has absolutely no clue what he is writing about. Just like what you pointed out.

He also claims raytracing does not solve photorealism, but does not back this claim. No single argument why! [Edit: But he's right here, for photorealism you probably want a combination of methods, like ray tracing and radiosity or ray tracing and photon mapping]

Complexity: For raytracing, you can store the scene in very efficient data structures, so you do NOT have to search your "billions of triangles" for each ray. Also, you can make sure rays degrade quickly since you trace them from the camera backwards to the light source, as you have pointed out.

"How do you raytrace stars"? They are a light source at infinite distance. This is a solved problem in computer graphics - And a pretty simple one at that.

Materials, Physics, Content and AI have nothing to do with computer graphics AT ALL.

Storing triangles in a super efficient data structure is precisely what I mean by traversing the scene. Do you really think that's a free operation when you have billions of triangles inside a data structure that must be dynamic by nature? You hit all sorts of arcane memory issues. I hit the same thing just developing a basic kd-tree for 2D culling.

The approximation algorithms I pointed out are exactly how raytracing is done backwards, but actually still must use a combination of camera rays and light source rays in a stocastic method in order to determine a path from the camera to the light source. Brute force raytracing is, in fact, just shooting out rays from the light sources. That's obviously inefficient, which is why we have the backwards lighting attempts, as discussed in the article.

Raytracing stars is not as simply as you think, not when you can visit them. They can no longer be point sources at infinite distance because the object itself is not infinitely far away, so you therefore can only substitute an infinite light source in when its essentially a point, which gets really nasty when you are dealing with entire galaxies as light sources, and if it isn't you must deal with all the lighting effects in between.

Materials are the most important part of computer graphics. If you don't think this, you have absolutely no idea what you are talking about.

I don't think anyone has ever done purely a from light source tracing, because it doesn't make sense. Tracing from camera is not an approximation.

Brute-force path tracing is random sampling from camera to every direction and bouncing/interacting until light source is hit. This is the standard Monte Carlo path tracing method which is unbiased and arrives at the accurate solution given enough time. This is unbiased, accurate and very simple to implement, but very slow to compute.

Metropolis and photon mapping are bidirectional methods where rays are selectively traced back from light source to forward direction, to speed up the path tracing computation.

Re: raytracing stars, the obvious answer is to use a lower detail representation when the stars are far away. In this case all the photons from the faraway galaxy will be arriving from almost exactly the same direction, so there won't be any noticeable loss of accuracy. This fits in pretty naturally with the hierarchical data structure you'll already be using (in practice) to hold the scene.

Regarding the data structure: the types of hierarchical structure commonly used to hold scene data for ray tracing actually lend themselves pretty well to level-of-detail, caching and streaming from disk; so it can be a help rather than a hindrance for managing memory. There's been some really promising work in the last few years on Sparse Voxel Octrees, for example.

> Materials, Physics, Content and AI have nothing to do with computer graphics AT ALL.

What do you mean by computer graphics? If you restrict the job of a computer graphics programmer to purely a function of how many polygons can be rendered at once at 60fps, you may be right... But such a programmer would ignore information about the scene at his or her peril.

Materials: what should this object look like when it interacts with other objects? Does dirt stick, what does it look like inside if it gets cut in two, would a smooth cut even be possible, what about just trying to make a dent with a blunt object? If a flashlight is shined at the material, how does the material react?

Physics: help define how materials behave. (Indeed if we could model everything on the level of real-life quarks the need for explicitly defined materials goes away.) What's fluid supposed to look like? What about when a player character is swimming? Can we sacrifice polygon counts for distant objects, or are distant objects important in the game's physical world? What does wind do to the grass polygons? Could we use less polygons to represent quickly-moving things where the level of detail is going to be poor anyway?

Content: Does an artist need to create two copies of Tree so we can model-swap the low-poly one when appropriate? Do we need to cut content to be able to render at reasonable speeds? Do we need more content to render something worth rendering? Do we have any content to put on the screen at all?

AI: Depends if you consider procedural generation of content AI or not. Also depends if you consider a subroutine that helps optimize your graphics pipeline during runtime AI or not. Then there's the problem of many and nice animations, which you may or may not consider important to "computer graphics".

"Physics" in the context of the article and the game development in general does not mean the natural science. It just means the part of the game that moves stuff around.

Same for the "AI", it only means the part that tells the "physics" when to move the stuff around.

And content is necessary for games but so is the air and food for everything. We don't usually talk about food when discussing technical issues in some field. Just because it's necessary does not make it relevant to the discussion.

Not really. First of all there's multiple samples per pixel for anti-aliasing and even more when doing stocastic sampling from the circle of confusion for DOF and motion blur, so you normally need 128-512 samples per pixel.

Then for each light (unless you randomly sample a light each time - which introduces more noise), you need to test occlusion from each surface hit to check for shadows. So each pixel sample that has a solid alpha (it hit an object) needs to be tested against lights with a ray.

Then with GI pathtracing, you need to bounce the light around the scene even for diffuse (non-shiny) surfaces.

The article's still mostly rubbish though...

Technically what you described is "reverse ray tracing" but yes, these days most people just call it ray tracing.

''It might seem that we would need only to run a conventional ray tracer "backward" from the light sources to the eye to achieve these effects. This concept has been called backward ray tracing, to indicate that it runs in the reverse direction from regular ray tracing, but it is also known as forward ray tracing to stress that it follows the actual path from the lights to the eye. We call it ray tracing from the light sources to avoid confusion!''

Foley et al., Computer Graphics: Principles and Practice, p. 792.

I find most people would call it raycasting (shooting rays from the screen/eye out into the world).