QuickDraw 3D

QuickDraw 3D, or QD3D for short, is a 3D graphics API developed by Apple Inc. (then Apple Computer, Inc.) starting in 1995, originally for their Macintosh computers, but delivered as a cross-platform system.

Mac OS Scrapbook version 7.5.2 (1996), showing a QuickDraw-3D-based 3D model

QD3D was separated into two layers. A lower level system known as RAVE (Rendering Acceleration Virtual Engine) provided a hardware abstraction layer with functionality similar to Direct3D or cut-down versions of OpenGL like MiniGL. On top of this was an object-oriented scene graph system, QD3D proper, which handled model loading and manipulation at a level similar to OpenGL++.[1] The system also supplied a number of high-level utilities for file format conversion, and a standard viewer application for the Mac OS.

QD3D had little impact in the computer market, both as a result of Apple's beleaguered position in the mid-1990s, as well as several fateful decisions made by the design team about future changes in the 3D hardware market that did not come true. Apple abandoned work on QD3D after Steve Jobs took over in 1998, and announced that future 3D support on Mac OS would be based on OpenGL.

OpenGL in the 1990s

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 release is from 2008.

Applications

Among hundreds of applications published employing RAVE are:

gollark: Do I require further apiodata?
gollark: ```sqlCREATE TABLE guild_config ( id INTEGER PRIMARY KEY, achievement_messages INTEGER);CREATE TABLE user_config ( id INTEGER PRIMARY KEY, achievement_tracking_enabled INTEGER);CREATE TABLE stats ( user_id INTEGER NOT NULL REFERENCES user_config (id), stat TEXT NOT NULL COLLATE NOCASE, value BLOB NOT NULL, UNIQUE (user_id, stat));CREATE TABLE achievements ( user_id INTEGER NOT NULL REFERENCES user_config (id), achievement TEXT NOT NULL, achieved_time INTEGER NOT NULL);```
gollark: Just configure some things to support "passwordless sudo" technology.
gollark: Do you have a debian addiction?
gollark: Why not just arch or void or 3 (three) apioforms?

See also

References
  1. http://legacy.macnn.com/thereview/features/covert/covert10.2.shtml
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.