RAY-CASTING AND RAY-TRACINGLike 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 ray-tracer needs to trace 320x200 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. |
Quality: resulting image is not very realistic. Often, they are blocky (Figure 3). | Quality: resulting image is very 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. Notice the blocky look. The
objects (lamp, gun) and enemies are
just transparent bitmaps being
scaled and blitted over the
background.![]() | Figure 4:
Scene from the 7th Guest.
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).![]() |