Nov 00 Online
Volume Number: 16 (2000)
Issue Number: 11
Column Tag: MacTech Online
Online
by Jeff Clites <online@mactech.com>
A few months ago we covered Quartz, Mac OS X's new 2D graphics technology based on the imaging model of Adobe's PDF. Quartz will be responsible, directly or indirectly, for most of what the user sees on the screen. What we didn't emphasize directly is that Quartz is 2D-only. Under Mac OS X, 3D graphics will be based on OpenGL. So what's OpenGL?
OpenGL is in, QuickDraw 3D is out
OpenGL is a 3D graphics library developed by SGI (then called Silicon Graphics). It's a high-performance, cross-platform library, available on Mac OS 9, Mac OS X, Windows, and many Unix variants, and many video cards provide hardware acceleration. It is the library of choice for sophisticated 3D development, most notably the gaming industry. In particular, OpenGL is the basis if id software's Quake games, and according to the company allows them to develop their products with only a tiny amount of platform-specific code. This is important for the Macintosh community, because it makes it that much more likely that games and other 3D-graphics-intensive software (such as scientific data visualization, CAD, and architectural design packages) will be available.
If you've done any 3D programming on the Macintosh in the past, you probably used QuickDraw 3D, the 3D library on Mac OS 9 and, technically, part of QuickTime (and therefore available on Windows as well). The sad news is that OpenGL is replacing QuickDraw 3D on Mac OS X, not just providing an alternative. The worst part is that, while OpenGL is the industry standard, QD-3D is much easier to use for simple 3D graphics. In fact, you could make the argument that OpenGL has a prohibitive learning curve for anyone wanting to do something simple—for instance, creating a 3D bar graph. It has a large procedural API, and it's yet another conceptual barrier you have to cross to get your application written. It also lacks QD-3D's elegant object-oriented (though still C-based) API, and well as its file format for storing 3D objects. On the other hand, you could make a strong counterargument that "simple" uses of 3D graphics are few and far between, and somewhat of an oxymoron—when's the last time you saw 3D graphics outside of a game, a screen saver, or a splash screen? In this light, there are certainly more people cheering the availability of OpenGL than are mourning the loss of QD-3D, but it would have been nice to retain an easy-to-use, high-level API, possibly layered on top of OpenGL. Although they seem to fit well together, there's no indication that Apple will go this route, and if there really are very few developers using QD-3D, it makes sense not to devote the resources to it.
Enter Quesa
Now the good news. The good news is Quesa, a third-party, open-source (LGPL) effort to recreate QD-3D from scratch—in other words, and independent library which is API-compatible with QD-3D. This approach is really a win-win situation for the Macintosh community, because it frees Apple from the burden of maintaining an API which may not be widely used, yet it will still be available to those who need it, for as long as anyone is interested enough in it to maintain it. The needs-based focus of many open-source projects is clearly present in Quesa, which was started because its founder wanted to be able to run his 3D screen saver on Mac OS X. The project is under active development, and in fact is mostly complete at this point. As a side benefit of the open-source approach, it is now truly cross-platform, available now on Mac OS 9, Mac OS X, Windows, and Linux, and coming to the BeOS as well. And as you might expect, Quesa can run on top of OpenGL, and so it will benefit from OpenGL hardware acceleration. As mentioned above, QD-3D (and hence Quesa) is object-oriented although written in C. This is interesting from a design standpoint, and is similar in spirit to Apple's new CoreFoundation API, which gives C-based access to key data types and APIs which originated in Cocoa. You can read more about Quesa's structure on its documentation page.
Quesa Resources
If you are moving into 3D graphics, there are several places you can start in order to get up to speed. If you are interested in the QD-3D/Quesa approach, you'll get a good overview from a series of articles which originally appeared in Apple's develop magazine, and you'll also want to become familiar with Apple's QD-3D documentation, which is available through the QuickTime section of their developer web site. Next, of course, you should take a look at Quesa itself, and download the libraries or source code. There is an active Quesa mailing list, which you'll want to subscribe to, as Quesa is still evolving and there are sure to be discussions of current problems and future directions. You might also want an overview of how QD-3D and OpenGL compare, so that you can make an informed choice about which approach you want to take. You can start by checking out an article "Must-See 3-D Engines" from BYTE Magazine, which compares OpenGL, QD-3D, and Direct3D, and then take a look at the information and resources in a past MacTech Online column from March 1998, written by my predecessor. Both of these are somewhat old and may no longer be accurate in their details, but they'll give you a feel for how the APIs differ in their approaches as well as their consequent strengths and weaknesses. Also, there is an FAQ, as well as several link lists which you can consult to find further information.
OpenGL Resources
OpenGL itself is an open standard, and the hub of information about this library is at the OpenGL home page. Here you'll find an overview for developers, links to tutorials, and information about the large assortment of books available on OpenGL (including the reference standards The OpenGL Programming Guide: The Official Guide to Learning OpenGL and OpenGL Reference Manual). As I mentioned above, OpenGL has a large API with a significant learning curve, but it is probably worth the effort if you plan to do hard-core 3D. To make your job a little easier, read up on GLUT, the OpenGL Utility Toolkit. It's a simplified, window-based API which is geared toward those learning OpenGL or using it to writer smaller programs. (GLUT does ship with Apple's OpenGL implementation, by the way.) You can find links to additional resources at the site of the Mesa project, which is an independent library with an OpenGL-compatible API. If you just want to get a flavor for the OpenGL API, try out a recent article on the O'Reilly Network which describes how to use OpenGL to simulate a black hole (really), and also links to additional introductory articles. Finally, keep an eye on Apple's sample code pages for examples of using OpenGL from Cocoa and Carbon, and download the SDK to get you started.
3D Graphics Foundations
Before you dive into a particular API, you may want to get a feel for the field of 3D graphics in general. If you've never worked with it before, there's quite a bit of conceptual background you'll need, and if you plan to work with it extensively there is also quite a bit of math. The classic text is Computer Graphics : Principles And Practice by Foley, Feiner, and Van Dam (ISBN 0201848406), and it is thorough and dense, covering both 2D and 3D graphics. For some lighter reading try the two book's by Jim Blinn, Jim Blinn's Corner: A Trip Down the Graphics Pipeline (ISBN: 1558603875) and Jim Blinn's Corner: Dirty Pixels (ISBN: 1558604553). They're not a full curriculum but they will give you a feel for some of the interesting and often intricate parts of the field.
3D and Cocoa
Another "interesting" facet of the move to OpenGL for Mac OS X is that we seem to be without a Cocoa-based API for 3D graphics. Certainly, you can use OpenGL from within Cocoa applications—Objective-C was designed to be an extension to ANSI C, so there is no technological barrier to using a C-based API from within a Cocoa application, but it would be more convenient to have a fully object-oriented API to work with, and developers are likely to create their own object-based wrappers for the parts of the API they are using. It would be nice for someone to do this once and for all, and develop a higher-level Cocoa-based library that everyone could use. There is some hope for such an animal as part of the MiscKit project. The MiscKit is a collection of Cocoa-based classes and utilities, assembled under an open-source model before "open source" became a household term. There are all kinds of useful tidbits in the MiscKit, although they are still in the process of being updated for the current Cocoa libraries (as most of the Kit was developed for NEXTStep or OpenStep). Of immediate relevance is something called the 3DKit, which was originally developed by NeXT and later transferred to the MiscKit maintainers (it remains a logically separate project). There appear to be a few licensing issues which may need to be worked out, but with a little luck this could serve as a strong starting point for a high-level 3D framework for Cocoa, or at least as an API model for such a framework.
Moving Forward
With OpenGL as a first-class citizen on the Macintosh platform, developers have a real choice of solutions for 3D graphics. It isn't a direct result of the open-sourcing of the core of Mac OS X as Darwin, but open-source projects are becoming more and more relevant (and more an more important) to the platform, and are signaling a cultural shift in the Macintosh community as well as the programming community at large. The Macintosh platform is becoming less and less proprietary, and Macintosh developers are becoming more aware of valuable resources which originated on other platforms, and of their own ability to take part in the process of moving these technologies to the Macintosh. And although it's easy to overlook at first, this is completely in line with the original motivation for the Macintosh, and for Apple as a company: bringing the power of technology to the individual, and letting him make his own choices. Now, more than ever, this means giving this power and choice to the individual developer, as well as to the end user. It's our responsibility to take advantage of this freedom, and participate in driving the platform forward.
