[Prev] [Home] [Next]


Like ray-casting, ray-tracing "determines the visibility of surfaces by tracing imaginary rays of light from viewer's eye to the object in the scene" (Foley 701).

From both definitions, it seems that ray-casting and ray-tracing is the same. Indeed, some books use both terms interchangeably. From game programmers perspective, however, ray-casting is regarded as a special implementation (subclass) of ray-tracing.

This distinctions because is made because in general, ray-casting is faster than ray-tracing. This is possible because ray-casting utilizes some geometric constraint to speed up the rendering process. For instance: walls are always perpendicular with floors (you can see this in games such as Doom or Wolfenstein 3D). If it were not for such constraints, ray-casting will not be feasible. We would not want to ray-cast arbitrary splines for instance, because it is difficult to find a geometrical constraints on such shapes.

Table 1 is a general comparison between ray-casting and ray-tracing. The main point to remember is that there are "less number of rays" to trace in ray-casting because of some "geometric constraints." Or, it can also be said that ray-casting is a special purpose implementation of ray-tracing.

Ray-Casting Ray-Tracing
Principle: rays are cast and traced in groups based on some geometric constraints. For instance: on a 320x200 display resolution, a ray-caster traces only 320 rays (the number 320 comes from the fact that the display has 320 horizontal pixel resolution, hence 320 vertical column). Principle: each ray is traced separately, so that every point (usually a pixel) on the display is traced by one ray. For instance: on a 320x200 display resolution, a ray-tracer needs to trace 320x200 (64,000) rays. (That is roughly 200 times slower than ray-casting.)
Formula: in most cases, inexact. Formula: in most cases, exact.
Speed: very fast compared to ray-tracing; suitable for real time process. Speed: slow; unsuitable for real time process (at least not until we got a 500Ghz machine).
Quality: resulting image is not very realistic. Often, they are blocky (Figure 3). Quality: resulting image is very realistic - sometimes too realistic (Figure 4).
World: limited by one or more geometric constraints (simple geometric shapes). World: almost any shape can be rendered.
Storage: small. Rendered images are not stored on disk. Normally, only the map is stored, and corresponding images are generated "on the fly." Storage: Rendered images are stored on disk and loaded when needed. Presently, no hardware is fast enough for "on the fly" rendering.
Examples: Wolfenstein 3D (iD Software), Shadow Caster (Raven), Arena (Bethesda), Doom (iD Software), Dark Forces (LucasArts). Examples: Examples: 7th Guest (Trilobyte), Critical Path (Mechadeus), 11th Hour (Trilobyte), Myst (Cyan), Cyberia (Xatrix).
Figure 3: Scene from Wolfenstein 3D (iD Software). Notice the blocky look. The objects (gun) and enemies (a dog) are just transparent bitmaps being scaled and blitted (i.e.: pasted) over the background.
Figure 4: Scene from the game 7th Guest (Virgin Software/Trylobyte). The result of the rendering is stunning. However, player's movement is restricted to a pre-determined path (because the amount of pre-rendered images are limited).


[Prev] [Home] [Next]