Spectrum is a modular, extensible architecture for rendering synthetic images. The system has been implemented in both the Cedar and C programming languages. Here's a description of the system proposal as presented at a Siggraph '93 course on large-scale graphics systems.

The general goals of this proposal are threefold: first, to provide a framework for a teaching tool for ray tracing and radiosity techniques, second, to allow developers of new techniques in those realms to develop their tools in a rich imaging environment without worrying about the rest of the system, and third, to promote the sharing of objects and techniques through sharing implementation code. These issues are addressed in order.

Many computer science texts promote the idea that computer science is a "hands-on" discipline, almost a laboratory science. Students can actually implement their ideas and see how they work, often entirely on their own. The excitement of carrying out your own creative work and producing a new result is a powerful force for human expression - novelists, painters, landscapers, and programmers have this in common. Computer science has a special bonus, which may be considered a mixed blessing common to many of the physical sciences: an implementation can be wrong. To realize that you are demonstrably wrong about something is both sobering and instructive, since understanding an error often provides a path to understanding the deeper principle that has been violated. One of the joys of computer graphics is that you can often see your errors. Every programmer has produced pictures that just don't look right. There's no question at such a time - something is wrong and needs to be understood and corrected.

Because computer graphics provides such a rich feedback and debugging mechanism - we actually see our errors (some of them, anyway) - it is natural to teach graphics through programming assignments. This architecture is designed to serve two teaching purposes. The first is to use the interface to fully specify an assignment (e.g. implement a shader for Phong shading, based purely on direct lighting of point sources and diffuse reflection). The student knows what information is available to the procedure, and can write the desired module. That module can then be plugged into an existing system and tried out, without worrying about any other image synthesis issues. The second goal is to provide example implementations of a wide variety of functions and procedures, which inherently provide complete, concrete detail on useful algorithms that are perhaps difficult to understand simply from a verbal description (as in a research paper). Many programmers learn their craft by studying the code of others, and different implementations of the same interface can provide a wealth of technique

On the left is a typical ray-traced image (note that the jpg conversion has introduced some dithering and quantization). The camera's focus is on the balls in the midground. On the right is the same picture, but this time viewed with a panoramic (cylindrical) camera. Note that the scene is illuminated by a sphere, not a point light. In Spectrum, any piece of geometry can be used as a light source.

I developed Spectrum while at Xerox PARC, and released the code into the public domain. I haven't worked on it much since then. The two images above show that the system is actually all in place; although it isn't obvious from the images, a great deal of substrate architecture was involved to handle sampling, light transport, radiometry, shading, and other issues correctly.

One of the techniques used by (and indeed, developed within) Spectrum is the efficiency method of dynamic stratification.

Many papers have been published in the last several years describing algorithms that blend ray tracing and radiosity techniques. The early categorizations of these techniques as applicable to direct vs. indirect lighting, flat vs. curved surfaces, and view-dependent and -independent optics have been blurred and sometimes eliminated, but many people believe that they are still different tools. Although both methods have been shown to be partial solutions to the rendering equation [Kajiya86], they still remain independent - we do not yet have a Grand Unified Rendering Program (GURP) which can handle all the effects supported by available algorithms.

This interface is designed to be open enough to support future work on a GURP by allowing both ray tracing and radiosity to use a common set of underlying support tools: I/O, object definitions and descriptions, light source definitions, sampling techniques, and so on. In addition to building new composite programs, the interface is modular, to allow development on the component algorithms. In particular, the system supports programmable, interchangeable modules to implement different techniques for shading, sampling, reconstruction, and imaging. Each of these are important research areas, and progress in any of these disciplines, which still fits the model of this system, can be implemented and shared immediately. For example, a new reconstruction strategy can be provided as a reconstruction procedure, and simply called in place of the old technique.

As with most ray tracers, the object database is meant to be extensible. In particular, abstract (or meta) objects are considered on the same basis as physical objects, and may be rendered or approximated as desired [Kirk86]. Additionally, as with other radiosity systems, every object may be considered a light source. Thus, any geometry that can be rendered can also be considered a light emitter, and have an attached radiation procedure. This includes complex and procedural geometry (e.g. helices or surfaces of revolution), vague geometry (e.g. glowing clouds of smoke), and even disjoint geometry (e.g. finitely-sized fractal dust). An advantage of a common architecture is that implementations may be shared. This helps the field make rapid progress, since everyone can stay near the leading edge of the quality of rendered imagery. It lowers the entry cost for users, since they need not learn a new system every time they want a new feature not available in a particular implementation. They need only get the appropriate module and add it to the system. ,he architecture must be general enough to admit new, unexpected techniques to be included without violating the design rules. In summary, this proposal is an attempt to create a framework for teaching, research, and code sharing.

In addition to the design features described above, the architecture supports the following features:

• Standard radiosity and distribution ray tracing features (energy balancing, soft shadows, depth of field, motion blur, spectral sampling, etc.)
• User control of most rendering parameters (with defaults)
  Programmable shaders, selected by the user at run time (including texturing)
• Programmable sampling techniques. Any sampling strategy may be used, including (but not limited to) static or adaptive, uniform or noisy. Any sampler may be used to draw samples on any two-dimensional distribution. Higher-dimensional samplers may be used as well.
• Programmable reconstruction techniques, appropriate for any two-dimensional signal, such as illumination spheres and screen images.
• Programmable radiation patterns for light emitters
• Programmable cameras, selected by the user at run time
• Easily-extended object and meta-object classes
  Still and animated sequence rendering
• Any geometric object may be a light emitter

Sampling and reconstruction are techniques unified across screen and object domains. All sampling procedures are interchangeable, whether they are sampling the image plane, the illumination arriving at an object surface, the texture in a region, etc. Similarly, reconstruction techniques are equally generic and applicable to all domains. A sampler is simply considered a technique for gathering information on a two-dimensional distribution. Callback procedures are used to control a sampler for the different purposes of screen sampling, shading, texturing, etc.

Shaders receive as input a description of the illumination sphere. They are not responsible for determining the incident illumination at a point, and they may reconstruct a sampled illumination signal before processing.

The incident illumination sphere is described as a collection of samples of the incident light. Typically, one determines this sphere by first building a set of set of samples that are directed to light-emitting objects; they return the color of the light found along the ray, whether it actually reached a light emitter or not. Then this set may be passed to an adaptive sampler as a "seed", or starting signal. This increases the likelihood that light emitters are sampled, and allows the incident illumination sphere to be adaptively sampled until the sampled signal meets the criteria for that sampler. This illumination sphere is then passed to a shader for modulation by the bidirectional reflectance distribution function of the surface at that point.

Objects may be queried by a shader for information. This contrasts with the RenderMan model, where a shader may expect a number of variables to be precomputed and available. Since the shaders in this system are not precompiled from a special-purpose language, it is difficult to determine a priori what information a shader requires from an object. Thus each object contains a procedure that accepts a request from a shader in the form of a list of requested geometric values, and returns the relevant information. There is a performance penalty for this process, but it only occurs once per shading point. I consider the penalty worth it.

Colors may be specified in a variety of formats, including spectral distributions.

Meta-objects (accelerators, CSG trees, abstract structures, etc.) are considered "first-class".

You can read more about Spectrum in my articles on the subject; citations appear below. The alpha release of the C implementation of Spectrum has been successfully run on a dozen different types of computers. Right now, creating the beta release is not one of my top priorities; when I've made a new release I'll include a pointer to the code here.

Glassner, Andrew S., "Spectrum: An Architecture for Image Synthesis, Research, Education, and Practice", in course notes for "Developing Large-Scale Graphics Software Toolkits", Siggraph 1994

Glassner, Andrew S., "Spectrum: A Proposed Image Synthesis Architecture", in course notes for "Frontiers in Rendering", Siggraph 1991