OpenGL and Direct3D - what's the difference?
Given the apparent decline in single card APIs such as Glide and demise of Apple's QuickDraw3D, OpenGL and Direct3D Immediate Mode seem to be the only serious contenders for a generic low level 3d graphics API. On the basis that many people may be more familiar with D3D IM, here's my (supposedly unbiased) view on what's different about OpenGL.
Sections
Checking for Hardware Acceleration
As of DX7, D3D can be used from C, C++ or Visual Basic via the COM model. OpenGL has function bindings for C (C++), FORTRAN, Ada and Java (more or less).
As of December 1999, D3D is available on Windows 9X, Win2K, Windows NT, and Dreamcast. Of those, the NT version is stuck at DX3 for want of a kernel patch, which makes it fairly unusable. However, Win2K (which would have been NT5) should solve this. The Dreamcast version seems to be little used, probably because it requires Windows CE and performance issues with CE seem to have made most people avoid it on Dreamcast in favour of the Sega libraries.
Remy Saville adds that D3D is not hardware accelerated on NT4 in any case. However, Win2K should fix this.
OpenGL is available on Windows 9X, NT and 2K, plus accelerated Apple Macs (iMacs, G3s, G4s, etc), Linux and PlayStation 2 (via a "middleware" driver). The performance of the PlayStation 2 version is unknown at this time, although its supposedly being written with input from SGI for hardware which (according to unattributable sources) is fairly suitable, so there seems to be a good chance it will perform well.
In general, D3D is quite tied to Windows, and to some extent (in my opinion) to PC hardware. OpenGL, by contrast, does not require any particular windowing system (or indeed any windowing system; the open source clone, Mesa, runs well in DOS) as support. Operating system specific support libraries are supplied by the OS vendor (wgl for Windows, glx for X, agl for Macs). OpenGL also (in my opinion) has an interface which is more suitable for cross platform development, since it is generally more abstracted, or at least more formally specified.
Some people will undoubtedly prefer to write different engine versions to different APIs for each platform for the sake of greater optimisation. If, however, you're interested in trying to cut development costs by minimising the number of different 3d engine versions, I'd suggest concentrating on OpenGL rather than D3D.
D3D generally has good driver support on Windows. There are certainly issues with D3D support on Dreamcast, but they mostly seem to be associated with Windows CE rather than with the D3D driver as such.
OpenGL driver support has improved a great deal recently, and is now generally good, with some exceptionally high quality implementations, although you will need to use Chris Hecker's free GLSetup program to deliver working drivers to end users on 9X. Mac support is also good, with a free shippable installer available from Apple, and on the PlayStation 2 driver delivery at least clearly won't be an issue. On Linux there is no clear way of delivering or upgrading drivers across multiple OS distributions, a situation that does seem likely to change after the upcoming release of XFree86 version 4.0. Even XFree86 v 4 itself should make configuring 3d on Linux much easier, since it makes 3d support part of the standard install.
In practice, these days I can't see much difference between OpenGL and D3D driver support. Some OpenGL implementations have clearly identifiable bugs, but a number of D3D drivers have "issues" where its unclear from the documentation (at least to me) what the driver's supposed to do, and different drivers do different things. The frustration level for actually delivering games with D3D and OpenGL seems to be much the same.
See the support notes for more information on the details of current OpenGL support on different platforms, cards etc, including notes on the workarounds people normally use for several problems caused by inadequate OS support on Windows.
The flipside of OpenGL's cross platform nature is that it tends to allow less very low level access to the hardware than D3D. In a very loose sense, I'd say that OpenGL has a similar relationship to D3D to the one D3D does to Glide or PowerSGL, Metal, RRedline etc.
Whether this matters probably depends on the sort of programmer you are. Some people prefer to write to an abstract, tightly defined interface, in which case the OpenGL approach will probably be preferable even on a single platform. Certainly its not obvious to me that the level of detail provided by D3D interfaces is necessary for effective games development, and many games, such as the Quake engine ones, work fine without it. If, on the other hand, you have a strong preference for writing "to the metal", you'll probably prefer D3D immediate mode.
D3D Immediate Mode as of DX7 and OpenGL 1.1 / 1.2 probably operate at much the same general level of hardware abstraction. For example, both allow you to abstract texture caching, geometry transformation, and runtime lighting - essentially the whole immediate mode graphics pipeline. Both have mechanisms for batch transfer of primitives (vertex buffers in D3D and display lists and compiled vertex arrays in OpenGL). Both have drivers which accelerate functions such as geometry transformation via hardware support on the card (if available) or high end CPU instruction sets such as 3DNow! or Katmai.
In keeping with its generally slightly lower level orientation, in D3D you normally have to turn on more abstracted features such as driver controlled texture caching, while in OpenGL you will have to turn them off if you want to manage things manually. Specifically, passing screen space geometry to OpenGL drivers is achieved by setting the appropriate transformation matrices to identity to signal to the driver that it should not perform geometry transformation (see this link for sending screen space data and this one for clip space.)
OpenGL has an open specification, the core of which is controlled by the Architecture Review Board, an independent body made up of "industry leaders" such as SGI, NVidia, 3dfx, Microsoft, Intel etc. Anyone writing an OpenGL implementation can choose to export any extension they wish, although people generally prefer extensions to be submitted to the ARB for review and official approval.
D3D, by contrast, is a proprietary API controlled by Microsoft. An extensions mechanism was introduced in DX7, but extensions cannot be exported without Microsoft approval.
This sort of issue may or may not matter to you. One practical consequence of the OpenGL approach is that there is an open source clone of OpenGL (Mesa), which means the API can be implemented in standard Linux distributions, and is useful if you want to check the source code of a version against the documentation. Current Mesa source trees are competitive for speed with good quality commercial OpenGL drivers running on the same hardware (e.g. in Quake 3 tests on a Voodoo 3 in Windows, Mesa is about 5% slower as of February 2000) and it is written in C and has an internal interface for hardware drivers, which means it is a possible basis for full or partial ports to hardware without OpenGL support. (The current Mesa license is XFree86, which means that such ports can be done to NDA'd APIs without any need to release source code or provide object code in a form which is relinkable with Mesa.)
Note: as of January 2000, the source code for SGI's "reference implementation" of OpenGL, used as the basis for almost all commercial drivers, is also freely available, under a license similar to XFree86. This download may be even more useful than Mesa for the purposes described in the paragraph above.
Historically, OpenGL development has been much slower than D3D's. This now appears to be changing: the Architecture Review Board seems to have "officially" decided to move much faster on new suggestions, and a large number of official proposals for new extensions are being made by 3dfx and NVidia. OpenGL 1.2 drivers are also beginning to appear on consumer cards for Windows, and already exist on Linux.
The standard route for the growth of OpenGL remains the addition of new extensions, which essentially means that future development to match new hardware will occur as long as a reasonable number of games and other applications use the API on a given OS, so that the IHVs are motivated to supply new extensions.
Extensions which have proved popular and useful are generally "made official" by the ARB, and eventually moved into a new version of the core specification (OpenGL 1.0, 1.1, 1.2, etc).
Checking for hardware acceleration
In D3D the presence of hardware acceleration for a given feature is checked for using the device caps bits and ValidateDevice. It is then the application's responsibility to choose a set of calls which can be handled effectively by a given driver, and default to its own or a D3D software renderer if hardware acceleration is not present.
OpenGL, by contrast, guarantees that any feature present in the core specification (but not extensions) for the version (1.1 or 1.2) will work. This is achieved by defaulting to a built in software renderer if the application's request cannot be handled by the hardware driver. It is also legal for the driver to implement operations in software if the driver writers believe that that will be faster than the hardware version, e.g. if the card has hardware transform and lighting capability but its slower than doing the same operations on the CPU the card driver can legally use the CPU for these operations.
Nothing, however, is said about how fast any given core procedure may be on any piece of hardware. The practical consequence of this is that you should either test your OpenGL game before release on every implementation you expect it to be run on, and determine which operations are fast enough to use on each card (not something I personally would recommend, except on a console), or test the operations you're interested in for speed automatically on e.g. the first reboot after game or driver installation and use the results to guide your choice of runtime path. Sample source code for the second approach is available; see isfast and Glean.
Note that in practice the vast majority of OpenGL 1.1 and 1.2 drivers will accelerate almost all of the core functionality, and vary mostly in the availability of extensions, so this issue is much less awkward to deal with than it might at first seem.
Fahrenheit was a joint project between SGI and Microsoft to "define the future of 3d graphics". SGI have now pulled out of this completely, and Microsoft are carrying on alone.
Fahrenheit Scene Graph (a high level scene graph API) and the Fahrenheit Large Model Visualisation API are currently supposed to appear on Windows and proprietary Unices running on non Intel processors. They seem likely to become the successors to Direct3D Retained Mode (on which development has stopped) and the Microsoft / HP DirectModel project respectively.
To the extent that anyone outside Microsoft really knows the status of Fahrenheit Low Level (the projected successor to both OpenGL and D3D Immediate Mode), it seems that it will be another name for D3D IM as of DX8.
Here are SGI's and Microsoft's positions on Fahrenheit as of the 5th of December 1999.