World Library  
Flag as Inappropriate
Email this Article

Rendering Acceleration Virtual Engine

Article Id: WHEBN0007392930
Reproduction Date:

Title: Rendering Acceleration Virtual Engine  
Author: World Heritage Encyclopedia
Language: English
Subject: Unreal, MorphOS, RAVE
Collection:
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Rendering Acceleration Virtual Engine


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.

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 APIs such as OpenGL or Direct3D.[1] 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, QD3D used a number of Apple-specific ideas about how 3D hardware should work, and initially performed poorly due to the lack of hardware acceleration.

Apple abandoned work on QD3D after Steve Jobs took over in 1998, and announced that future 3D support would be based on OpenGL.

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.

RAVE

In order to deal with the performance-critical rasterization operation, Apple designed QD3D to sit on top of a separate package known as RAVE (Rendering Acceleration Virtual Engine). The result was something much closer to OpenGL — more primitive to program, but with increased control over rendering.

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 repeatedly watched the “next big thing” come out of Apple only to see it be killed off in the next company reorganization, and were increasingly wary of putting any effort into supporting Apple’s latest developments. 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 soon clear to everyone that it was destined to be ignored in favor of Direct3D.

At the same time the expected market for 3D desktop applications simply didn’t materialize. Most exiting 3D users stayed with their workstation-based modelers for performance reasons, and most other users proved to have limited 3D needs. 3D games, on the other hand, took off at about this time, and drove the widespread availability of consumer-level 3D hardware.

Although RAVE was designed to be cross-platform, only Mac hardware developers (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.

Switch to OpenGL

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.

Today there remains no standard high-level API for 3D graphics. Several attempts have been made, including OpenGL++ and the SGI/Microsoft Fahrenheit graphics API, but none of these have made it to production.

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).

Applications

Applications published employing RAVE include

See also

References

External links

  • 3D Graphics Programming with QuickDraw 3D 1.5.4 — QD3D manual (archived)
  • QuickDraw 3D: A New Dimension for Macintosh Graphics — prerelease article, June 1995
  • QuickDraw 3D: Questions and Answers
  • Quesa project home page
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.