The Bove and Rhodes ReportInsight on computers and media | by Tony Bove and Cheryl Rhodes | Mar. 27, 1997
Direct3D vs. OpenGL: Which is Built to Last?
These days I am writing technical material about developing immersive 3D worlds in VRML () for playback on the Internet. I keep bumping into a very tricky problem for those developing such worlds: how to make VRML tools that are capable of creating worlds that run with any VRML-compatible browser plug-in. One major trick is deciding which type of to support.
It's happening all over again: a proliferation of display cards for the PC that are vastly different in capabilities and inherently susceptible to obsolescence. It was once the case with 2D accelerator cards; now it is true about 3D.
The problems involved with making 3D environments run fast on PCs have not been solved, so expect this proliferation of weird solutions to continue for a while, even though has thrown its weight around to "directly" address the problem.
Microsoft's answer is the Direct3D application program interface (API), which is designed to insulate the commercial game developer from the specifics of different 3D accelerator cards. There are Direct3D drivers for nearly every shipping 3D accelerator. According to Microsoft, Direct3D's main purpose is to provide a standard driver model for consumer-oriented 3D hardware acceleration. Direct3D's "Immediate" mode (as compared to the "Retained" mode, useful for supporting 3D tools) is designed to give game developers the fastest possible access to a diverse range of hardware accelerators.
By comparison, OpenGL, developed by (SGI), is an industrial-strength 3D API designed to serve the needs of high-end CAD, modeling, and scientific visualization. SGI recently announced that , , accelerator chip companies and , and card makers and have licensed it.
OpenGL's many strengths include displaying high-resolution color images, strong documentation and sample code (as compared to Direct3D), and developer familiarity. For example, id Software's engineers ported Quake to OpenGL quickly and easily, but had considerable trouble porting it to Direct3D's Immediate mode.
However, OpenGL has no driver model because it was originally designed to support a proprietary pixel-accurate rendering pipeline. While there are OpenGL drivers for some popular consumer 3D cards, the rendering pipeline approach is not something that will appear in consumer-oriented cards in the near future. And yet, the debate rages as OpenGL is modified to run on everything from low-cost to $250,000 infinite reality systems. At the same time, Direct3D has a real edge over OpenGL in the area of software-only 3D display.
Game developers are caught in the middle. A developer might want to write code to take advantage of specific features in a particular card, but it's a complete guess whether that card will be popular 18 months later. Some cards are slower than the CPU on some 3D rendering tasks. Next year, PCs will have buses that go much faster than current hardware, and some cards will take advantage of this performance increase while others will not. Game developers have to decide which tasks are to be performed by the CPU and which are to be performed by the accelerator. Of course, the operating system itself might change in 18 months and the allocation of CPU cycles might change with it.
Both APIs deliver important functions for game developers. OpenGL is said to offer features that are more suitable for high-end CAD and visualization applications, while Direct3D is supposed to have nice game-like features including specular blend at each vertex and color key transparency. Neither API is complete, which brings up the problem of extensions. OpenGL can be extended by the hardware driver, but Direct3D imposes a layer between the driver and the API (some say this is a good thing, others do not). The net result is that only Microsoft can extend Direct3D.
One major point in the debate among game developers is the capability to find out what the hardware can do. With OpenGL, a developer pretty much writes to the API knowing that there is a guaranteed set of functions implemented either by the hardware or by the driver (in software). With Direct3D, the developer has a harder task -- that of querying to find out what the hardware can do and write code for different cases. While it is more work to write code for Direct3D, the developer can decide how to implement certain features depending on the hardware, which lets the developer fine-tune performance. Direct3D might therefore allow for faster implementations on a broader range of hardware.
However, if a game developer has to write code that detects and then decides whether to implement certain features depending on the hardware, the capability to port this software is much harder. OpenGL requires the entire set of core functions to be implemented, making porting easier. There is also the not-so-trivial issue that Direct3D is supported only by Windows 95, while OpenGL is supported by the Mac OS, OS/2, the X Window system, and Windows NT, as well as Windows 95.
One thing Microsoft has acknowledged is that the documentation for the current version of Direct3D is poor, and there is a lack of conformance tests, which means that Direct3D drivers can vary widely in functionality. OpenGL has better conformance tests and is a much easier API to develop for. My prediction: game developers who write directly to hardware will most likely adopt OpenGL first, perhaps bundling OpenGL cards with their games, while VRML tools developers will have to support both. Game developers using VRML rather than writing to a specific API will be somewhat insulated from this problem, but then, VRML developers have a host of other problems to deal with, not the least of which is performance over the net.
There are plenty of other differences, too numerous to mention in this column. Try SGI's for more specific information on OpenGL, and Microsoft's for more information about Direct3D. I'll be writing more on this topic as developments occur.
Be seeing you...
-- Tony Bove, Mar. 27, 1997. Comments?
