This paper describes shear-image order ray casting, a new method for volume rendering. This method renders sampled data in three dimensions with image quality equivalent to the best of ray-per-pixel volume rendering algorithms (full image order), while at the same time retaining computational complexity and spatial coherence near to that of the fastest known algorithm (shear-warp). In shear-image order, as in shear-warp, the volume data set is resampled along slices parallel to a face of the volume. Unlike shear-warp, but like the texture-based methods, rays are cast through the centers of pixels of the image plane and sample points are at the intersections of rays with each slice. As a result, no post-warp step is required. Unlike texture methods, which realize shear and warp by transformations in a commodity graphics system, the shear-image ray casting methods use a new factorization that preserves memory and interpolation efficiency. In addition, a method is provided for accurately and efficiently embedding conventional polygon graphics and other objects into volumes. Both opaque and translucent polygons are supported.We also describe a method, included in shear-image order but applicable to other algorithms, for rendering anisotropic and sheared volume data sets directly with correct lighting.The shear-image order method has been implemented in the VolumeProTM 1000, a single chip real-time volume rendering engine capable of processing volume data at a pipeline rate of 109 samples per second. Figure 1 on the color page shows a shear-image order gallery of volumes rendered with different translucency, lighting, and some embedded geometry.

(Article begins on next page) The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters.

The development of Pilot, an operating system for a personal computer, is reviewed, including a brief history and some of the problems and lessons encountered during this development. As part of understanding how Pilot and other operating systems come about, an hypothesis is presented that systems can be classified into five kinds according to the style and direction of their development, independent of their structure. A further hypothesis is presented that systems such as Pilot, and many others in widespread use, take about five to seven years to reach maturity, independent of the quality and quantity of the talent applied to their development. The pressures, constraints, and problems of producing Pilot are discussed in the context of these hypotheses.

The Pilot operating system is designed for the personal computing environment. It provides a basic set of services within which higher-level programs can more easily serve the user and/or communicate with other programs on other machines. Pilot omits certain functions sometimes associated with “complete” operating systems, such as character-string naming or user-command interpretation; higher-level software provides such facilities as needed. On the other hand, Pilot provides a higher level of service than that normally associated with the “kernel” or “nucleus” of an operating system. Pilot is closely coupled to the Mesa programming language and runs on a rather powerful personal computer, which would have been thought sufficient to support a substantial timesharing system of a few years ago. The primary user interface is a high resolution bit-map display, with a keyboard and a pointing device. Secondary storage generally takes the form of a sizable local disk. A local packet network provides a high bandwidth connection to other personal computers, and to server systems offering such remote services as printing and shared file storage.

Second generation computing systems rarely had an aggregate of peripheral devices with high enough data transfer rates to tax memory speed or to degrade central processor ( CP) performance. Whenever they did, there was no attempt to overlap transfer with computing, and the CP remained idle. But in many third generation systems, there are several processors-both I/O devices and arithmetic units-operating asynchronously and independently, each of which has a high transfer rate to main memory. Thus, the question of designing sufficient bandwidth into memories and buses is significant. Experience with some of the commercial multiprocessing systems (e. g., UNIVAC 1108 or IBM 360/67) shows, however, that sufficient bandwidth is not enough. The system must be organized so that the full bandwidth, or at least a large fraction of it, can be used effectively. It is this problem to which the author has ably addressed his paper.