QuickDraw 3D - QD3D

QD3D

QD3D had the advantage of running on computers with considerably less power than the SGI systems OpenGL was designed for. This guided the developers to cleanly separate the system into a high-level and low-level set of APIs, so that the lower levels could be implemented entirely in hardware. Since the high-level API was not intended to run directly on hardware, designers could pack it with as many features as they wanted.

The result was that QD3D offered a considerably richer programming system for developers, one that dramatically reduced the workload for basic applications. QD3D provided functionality not only for storing and manipulating a scene graph, but also added a number of easy to use 3D objects, UI elements, and even input controllers. The suite allowed developers to add 3D support to their applications with ease, in a way that had a consistent UI when compared to other 3D applications using the platform. Apple additionally introduced the 3DMF file format in order to allow developers to exchange 3D models between applications, providing all the needed code for loading and saving 3DMF files.

Additional functionality included a “plug-in” rendering system, which allowed an application to render a scene in a variety of styles. Without changing the model or their code, developers could render the same scene interactively or (with suitable plug-ins) using methods such as ray-tracing or hidden-line.

The QD3D API was an “object-like” system based on pure-C code. The various structures were carefully constructed to contain pointers to other important objects. Objects knew all the drawing state they needed, thereby eliminating code that would normally be needed when developing under OpenGL. For obvious reasons the APIs were also tightly integrated with the Mac OS, allowing the developer to bring up an interactive 3D view in a window with little code. The developer’s task was essentially to provide the models and “behavior” for the world, as opposed to the basic 3D framework that was needed for lower level libraries.

To contrast the two approaches, consider this sort of task that QD3D could directly support:

load the model “human”, load the style “t-shirt”, apply “t-shirt” to “human”, draw

Under OpenGL this task would resemble something more like:

load the model “human”, load the texture “t-shirt”, enable the texture “t-shirt”, draw

On the downside, QD3D’s layering introduced performance issues. For instance, the system stored and automatically set state for every object before drawing. This made development much easier, but also made the performance drop in a way the developer had no direct control over. Under OpenGL the user was forced to handle state themselves, but in doing so could often avoid the majority of state-setting commands and thereby improve performance.

Another area of concern is that the scene graph was hidden from view, and considerable improvements in rendering performance can be made by carefully “culling” the graph to remove those objects that are not in view. Although later releases of QD3D gained the ability to automatically perform visibility culling (based on the grouping of objects in the scene graph), OpenGL’s lack of support for this feature typically forced developers to implement it from the start.