QuickDraw 3D

The canonical 3D API of the 1990s was OpenGL. This had been written by SGI and initially closely matched the capabilities of their workstation systems, operating as a hardware abstraction layer. The OpenGL API consisted mostly of state-setting instructions for setting up drawing modes like the paint color or camera position, and system for sending geometry into the system, normally as meshes of triangles. The combination of these instructions was saved into a display list which was then rendered to produce the output. OpenGL lacked many features that are needed to produce a complete 3D program. Saving and loading geometry data, collecting that data into groups to produce model objects, and the control of state was all left to the programmer. This was considered to be an advantage in an era when performance was limited and direct control over these sorts of functions was a route to improved performance. However, this lack of high-level functionality did make it more difficult to quickly write simple programs, as well as leading to a lack of interoperability. A number of efforts started to provide standardized higher level APIs, like OpenGL++ and (later) Fahrenheit, which handled many of the more common bookkeeping tasks like loading geometry from files and providing a display. These standardized scene graph systems meant the programmer only had to provide the GUI for the program. While OpenGL is mostly low-level, it did include some higher-level concepts that were only really used on SGI systems. This led to another series of APIs that removed these features to make it easier to implement on common hardware. The best known of these is MiniGL, which is not a separate API, but simply a list of those functions in OpenGL that are guaranteed to be supported across all hardware, thus ensuring that a program limiting itself to those calls will run with maximum performance. ==QD3D==

QD3D was designed from the start to operate on computers with considerably less power than workstations. This led to a concerted effort to cleanly separate the upper and lower layers of the API, with the lower-level RAVE system being closer to MiniGL from the start. This had the advantage of providing a clean and minimal API that could be more easily ported to different hardware. Since only RAVE needed to be ported, the upper layer APIs could be made as complex as desired, and the QD3D system included a complete scene graph, a standardized model file format, 3DMF, and even basic GUI objects that utilized them. To write a simple application in QD3D, the programmer only had to include a few libraries and then place the GUI elements in their program using ResEdit or similar tools. 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 phong shading. 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. 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. Those applications demanding performance over ease of programming could instead choose to use the RAVE layer directly. 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. ==Switch to OpenGL==

Good low-level 3D performance relies not only on the programmer to provide efficient models, but high-quality drivers for the hardware as well. Although RAVE was designed to be cross-platform, only hardware developers which supported Mac (ATI, NVIDIA, and 3dfx) produced drivers for it. This left any comparison between QD3D and alternative APIs one-sided, as outside of the Mac QD3D was forced to fall back to a software RAVE implementation. As OpenGL gained traction on Windows (often credited to id Software, who championed the API over D3D), hardware developers were increasingly designing future hardware against the future feature set planned for Microsoft's D3D. Through its extension mechanism OpenGL was able to track these changes relatively easily, while RAVE's feature set remained relatively fixed. At the Macworld Expo in January 1999, Apple announced that neither QuickDraw 3D nor RAVE would be included in Mac OS X. The company laid off the development staff in June 1999, replacing the in-house technology with OpenGL after buying a Mac implementation and key staff from Conix Enterprises. After Apple withdrew support for QD3D, an open source implementation of the QD3D API was developed externally. Known as Quesa, this implementation combines QD3D's higher level concepts with an OpenGL renderer. As well as cross-platform hardware acceleration, this library also allows the use of the QD3D API on platforms never supported by Apple (such as Linux). The latest update is from 2023. ==Applications==

Among hundreds of applications published employing RAVE are: • Graphing Calculator in the 1990s, shipped with every Power Macintosh • Quake • Descent II • Unreal • Carmageddon 2 • Future Cop: LAPD • WaterRace • StrataVision 3D • Infini-D • Bugdom ==See also==