RT & REMRT Shared Memory Parallel and Network Distributed Ray-Tracing Programs

The ray-tracing procedure is ideal for execution in parallel, both in tightly coupled shared-memory multiprocessors, as well as loosely coupled ensembles of computers. RT, the ray-tracer in the BRL CAD Package, takes advantage of both types of parallelism, using different mechanisms. The presentation will start with a discussion of the structure of the ray-tracer, and the strategies used for operating on shared-memory multiprocessors such as the Denelcor HEP, Alliant FX/8, and Cray X-MP. The strategies used for dividing the work among network connected loosely coupled processors will be presented. This will include details of the dispatching algorithm, the distribution protocol designed, and a brief description of the "package" (PKG) protocol which carries the distribution protocol. The presentation will conclude by investigating the performance issues of this type of parallel processing, including a set of measured speeds on a variety of hardware . 1. Raytracing Background The objective of a model analysis application determines the most natural form in which the model might be interrogated . For example , extracting just the edges of the objects in a model would be suitable for a program attempting to construct a wire-frame display of the model. Applications also exist which need to be able to find the intersection between the paths of small objects such as photons and the model. Interrogations such as these are motivated by a desire to simulate physical processes, and each alternative is useful for a whole family of applications. Most physical objects have a significant cross-sectional area. Mathematical rays, however, have as their cross-section a point. Therefore, interrogating the model geometry with rays can result in sampling inaccuracies . While recent research has begun to explore techniques for intersecting cylinders, cones,l. 2 and planes with the model geometry, 3 ray-tracing is by far the most well developed approach. Fortunately, most applications can function well with approximate, sampled data . Data with statistical validity can be obtained by sampling the model with an adequate number of rays and computing the ray/geometry intersections . By choosing a ray sampling density within the Nyquist limit, these applications are satisfied by extracting ray/geometry intersection information, the well known "ray-tracing" algorithm. This approach is one of the easiest to implement, as the one-dimensional nature of a mathematical ray makes the intersection equations relatively straightforward, even with combinatorial solid geometry (CSG) models . Fourth USENIX Computer Graphics Workshop The origins of modern ray-tracing come from work at MAGI under contract to BRL, initiated in the early 1960s. Th~ initial results were reported by MAGI4 in 1967. Extensions to the early developments were undertaken by a DoD Joint Technical Coordinating Group effort, resulting in publications in 19705 and 1971 .6 A detailed presentation of the fundamental analysis and implementation of the ray-tracing algorithm can be found in these two documents. They form an excellent and thorough review of the principles of ray-tracing and solid modeling. More recently, interest in ray-tracing developed in the academic community, with Kay•s7 thesis in 1979 being a notable early work. One of the central papers in the ray-tracing literature is the work of Whitted. 8 Model sampling techniques can be improved to provide substantially more realistic images by using the "Distributed Ray Tracing" strategy . 9 For an excellent, concise discussion of ray-tracing, consult pages 363-381 of Rogers . 10 There are several implementation strategies for interrogating the model by computing ray/geometry intersections . The traditional approach has been batch-oriented, with the user defining a set of "viewing angles", turning loose a big batch job to compute all the ray intersections, and then post-processing all the ray data into some meaningful form. However, the major drawback of this approach is that the application has no dynamic control over ray paths, making another batch run necessary for each level of reflection, etc. In order to be successful, applications need: (I) dynamic control of ray paths, to naturally implement reflection , refraction , and fragmentation into multiple subsidiary rays, and (2) the abiiity to fire rays in arbitrary directions from arbitrary points . Nearly all non-batch ray-tracing implementations have a specific closely coupled application (typically a model of illumination), which allows efficient and effective control of the ray paths. However, the most flexible approach is to implement the ray-tracing capability as a general-purpose library, to make the functionality available to any application as needed. This is the approach taken in the BRL CAD Package, II a large modeling and analysis system based primarily on the ray-tracing of CSG solid models. The ray-tracing library is called librt, while the ray-tracing application of interest here (an optical spectrum lighting model) is called RT . This software is available from the author at no charge on a non-redistribution basis. 2. The Structure of librt In order to give all applications dynamic control over the ray paths, and to allow the rays to be fired in arbitrary directions from arbitrary points, BRL has implemented its second generation ray-tracing capability as a set of library routines. Librt exists to allow application programs to intersect rays with model geometry. There are four parts to the interface: three preparation routines and the actual ray-tracing routine. The first routine which must be called is rt_dirbuild(), which opens the database file, and builds the in-core database table of contents. The second routine to be called is rt_gettree(), which adds a database sub-tree to the active model space . rt_gettree() can be called multiple times to load different parts of the database into the active model space . The third routine is rt_prep(), which computes the space partitioning data structures and does other initialization chores. Calling this routine is optional, as it will be called by rt_shootray() if needed. rt_prep() is provided as a separate routine to allow independent timing of the preparation and ray-tracing phases of applications . To compute the intersection of a ray with the geometry in the active model space, the application must call rt_shootray() once for each ray . Ray-path selection for perspective, reflection, refraction, etc, is entirely determined by the application program. The only parameter to the rt_shootray() is a librt "application" structure, which contains five major elements: the vector a_ray.r_pt(P) which is the starting point of the ray to be fired, the vector a_ray .r_dir (i)) which is the unit-length direction vector of the ray, the pointer *a_hit() which is the address of an application-provided routine to call when the ray intersects the model geometry, the pointer *a_miss() which is the address of an application-provided routine to call when the ray does not hit any geometry, the flag a_onehit which is set non-zero to stop ray-tracing as soon as the ray has intersected at least one piece of geometry (useful for lighting models), plus various locations for each application to store state (recursion level, colors, etc). Note that the integer returned from the Fourth USENIX Computer Graphics Workshop . :