QuickDraw 3D, or QD3D for short, was a 3D graphics API developed by Apple Inc., originally for their Macintosh computers, but delivered as a cross-platform system. QD3D provided a high-level API with a rich set of 3D primitives that was generally much more full-featured and easier to develop than low-level API's such as OpenGL or Direct3D. Below this was a cleanly-separated hardware abstraction layer known as RAVE that allowed the system to be ported to new hardware easily. On the downside, Q3D used a number of Apple-only ideas about how 3D hardware should work, and generally performed poorly due to low-quality implementations on common hardware. Apple abandoned work on QD3D after Steve Jobs took over in 1998, and announced that future 3D support would be based on OpenGL.
3D in general
Most 3D toolkits concentrate on the lowest levels of the problem. This includes the basic geometry of the "world", as well as systems for describing objects based on that geometry. Key to high performance in 3D applications is limiting the data that needs to be manipulated, and storing that in an efficient way in order to reduce the amount of memory that needs to be transferred during drawing. Computer bus operations can be many times slower than the processing of that data, so every effort must be made to reduce the overall load.
For instance, the OpenGL system consists primarily of a system for describing geometry in various ways that eliminate common vertexes from the data, along with commands for manipulating the objects and drawing them in the world. To further reduce traffic, OpenGL is a "stateful" system, in which the the result of drawing an object into the world will depend on the state of the system set up in previous commands. The advantage is that many operations sharing common state only need to send setup information once. This also means that complex programs have to carefully track and restore state during drawing, an expensive operation that can actually lead to decreased performance if done too often.
Higher-levels of the 3D world are generally not included in low-level libraries. For instance, OpenGL has no system for storing the relationships between parts or building objects out of other objects. This is particularly important in 3D graphics, where objects are generally constructed out of a number of parts that are moved together to produce a larger model. This grouping, known as a scene graph, is typically left to the end-user to develop on their own, although a number of attempts to provide a standardized stateless scene graph were made several times over OpenGL's history. Even common issues such as interacting with the model or placing the view in a window are generally left to add-on libraries, in order to give the developer complete control over the system. However this also means that developers are writing the same basic code over and over again, just to get started.
To add to the problems, OpenGL was not truly low-level. It included about 250 calls in the basic API, making it too large to implement fully on consumer-level graphics cards of the era. This made the overall development task more difficult; it supported none of the high-level features that eased development, nor was it small enough to fully run on the hardware, thereby forcing the card developers to emulate many of the functions in software. In order to address the later issue, the Glide API, a subset of OpenGL, was developed for use on the Voodoo series of 3D cards.
QD3D had the disadvantage of running on machines with considerably less power than the SGI boxes OpenGL was designed for. This guided the developers to cleanly separate the system into a high-level and low-level set of APIs, and since the high-level API was not intended to run directly on hardware, it could be made as feature packed as it 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 with ease, in a way that was consistent with 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 in the library.
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 a considerable amount of code that would normally be needed for 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 "behaviour" 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 contents of this file into a list of vertexes, place the vertexes into a structure, create a display list with the structure, load this bitmap into the list, load this bumpmap into the list, etc.... 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. While it would be possible for QD3D to do this internally, culling is not a one-size-fits-all issue and without direct control over the scene graph it is not terribly difficult for the same application in OpenGL to outperform it.
In order to deal with these sorts of performance-critical operations, Apple later offered RAVE on it's own as a high-speed low-level API, instead of "just" a hardware layer. The result was something much closer to OpenGL -- more difficult to program, but faster as a result of putting in the effort.
Unfortunately QD3D did contain one serious performance limitation even with RAVE; the higher level geometry was based, for some unknown reason, on quadrilaterals instead of triangles, whereas all of the hardware used triangles. This meant that all drawing had to have its geometry converted in the RAVE layer unless the developer deliberately used triangles only. While this was possible for RAVE-only programs, the high levels of QD3D made extensive use of quads and therefore ran slower than it should have.
Although RAVE did what it intended to do, the effort was essentially doomed. Good low-level 3D performance relies not only on the programmer to provide efficient models, but high-quality drivers for the hardware as well. This is where RAVE failed. Developers had repeated watched the "next big thing" come out of Apple only to see it be killed off in the next company reorganization, and were increasingly gun-shy of putting any effort into supporting their latest system. By 1996 the market generally felt Apple was doomed to bankruptcy, making matters considerably worse. Microsoft was at the same time trying to introduce their own similar library, Direct3D (D3D), and even though QD3D beat it to market and was technically superior, it was clear to everyone that it was basically being ignored in favor of D3D.
At the same time the expected market for 3D desktop applications simply never materialized. Most users stayed with their workstation-based modelers for performance reasons, and most other users have limited 3D needs. One of the few common uses was charting software, and even this is not at all universal. 3D games, on the other hand, took off at about this time, and while RAVE's cross-platform capabilities, generally cleaner API and clear layering made it arguably the best of all the APIs available, Microsoft's market dominance made any efforts in this arena a non-starter.
Switch to OpenGL
As support for QD3D in the marketplace dwindled, the Mac platform was left with few games. Developers were simply not willing to support RAVE for the small Mac market, and hardware support disappeared. Over this period graphics cards had evolved to the point where they could support the vast majority of the OpenGL API, which was becoming the "other system" to MS's D3D.
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. This was instrumental in opening up the field for more 3D game developers on the Mac platform.
Today there remains no standard high-level API for 3D graphics. Several additional attempts have been made, including OpenGL++ and the SGI/Microsoft Fahrenheit graphics API, but none of these have made it to production. A new system combining QD3D's higher levels using OpenGL as its HAL is an interesting idea.
Sources and References
|This page uses Creative Commons Licensed content from Wikipedia. (view authors)|
- QuickDraw 3D: A New Dimension for Macintosh Graphics
- Must-See 3-D Engines
- - compares QD3D, OpenGL and Direct3D