Fahrenheit: No Spontaneous Combustion Here!

Game developers who work with 3D graphics got an unexpected surprise this holiday season in the form of a joint SGI/Microsoft announcement on a new 3D API, just a week after the joint SGI/Microsoft announcement of the OpenGL ICD DDK. The DDK announcement (that Microsoft will license and support the Independent Client Driver DDK while SGI will do the coding) was generally seen as Microsoft's graceful admission that OpenGL is here to stay, and no matter who's OpenGL it is, it's going to be seen as part of the operating system. That OpenGL is going to be supported de facto as well as de jure was welcomed by just about everybody. However, the announcement of SGI and Microsoft working together on a new set of 3D technologies lumped together under the title "Fahrenheit" was welcomed with much head scratching * after all, didn't the joint DDK announcement mean that Microsoft had given up trying to get rid of OpenGL? Now SGI is teaming up with Microsoft for a new, non-open, 3D API? What in tarnation is going on here?

Being the curious guy that I am, I decided to find out. First of all let's take a look at the announcement itself. (You can read the press release in full here.)

The Announcement

The following statement from the press release is particularly interesting:

"[The] Fahrenheit low-level API will become the primary graphics API for both consumer and professional applications on Windows. The Fahrenheit low-level API will evolve from Direct3D, DirectDraw, and OpenGL while providing full backward compatibility with applications and hardware device drivers written for Microsoft Direct3D and functional compatibility with Silicon Graphics' OpenGL technologies."

This tells us that Fahrenheit will be the successor to OpenGL and DirectDraw/Direct3D * in other words, one API for 2D and 3D graphics, at least on Windows platforms. The API wars will really be over then, except for those folks still holding onto legacy DirectX or OpenGL code. Now the interesting thing is that they claim that they'll open the spec for review by interested parties, and that they will be getting Intel involved in the API code to make Fahrenheit run particularly well on Pentium IIs. It's nice that Intel is involved, and I'm sure that Intel will be helpful in assuring that the API code runs particularly well on Pentium II, as well incorporating MMX and MMX2/Katmai instructions and the new 64-bit instruction set. And I bet that the little chipset that Intel sells called the Intel740  (see Gamasutra i740 Interview) is also looked after. The effect that suggestions from interested parties such as game developers, video chip makers, and AMD and Cyrix will have remains to be seen. It's also difficult to see how the fact that the low-level API is Windows-only will be played in relation to the other parts of Fahrenheit.

Fahrenheit is made up of three pieces: a Scene Graph API, a Large Model Visualization Extension package, and a Low-Level API.

The Scene Graph API
The Scene Graph uses technology taken from SGI products such as Performer, OpenInventor, and Cosmo 3D. SGI was already taking the experience of creating these products that incorporate scene graphs into their OpenGL++ design. The OpenGL++ design will be the starting place for Fahrenheit Scene Graph. If the term is new to you, a scene graph is a layer that sits on a low-level API and optimizes calls to that API. It has interfaces and data structures to create a world, specify objects, textures, and behaviors, and so on. The interesting thing about a scene graph, particularly one being built from technology based upon prior work done by SGI, is that SGI knows how to rearrange data to send to a hardware accelerator. The was the thing that SGI did better than anyone else in the world. Coupled with the technology that's supposed to be going into the Large Model Visualization Extensions, the Scene Graph API could revolutionize the way that applications such as games are currently written for the PC. It could be as good as Retained Mode was ignored. The Scene Graph is supposed to be done sometime in 1999, and will run either OpenGL or DirectX as the low-level API. Fahrenheit will supposedly transition seamlessly, so any code that uses Scene Graph will run when the Fahrenheit Low-Level API becomes available.

What good is a Scene Graph if it isn't better than what you can do yourself with 1/10th the code? This is where Fahrenheit shows its muscle. The Scene Graph will take technology from SGI's Optimizer and Performer APIs and Hewlett-Packard's DirectModel API. Dynamic level-of-detail for models, automatic state-dependency reordering, and scene data management are all techniques that allow user to take things such as 10,000 polygon models and manipulate them in real time.

The Large Model Visualization Extensions
The Large Model Visualization Extensions serve two goals. The primary reason for the existence of the Large Model Visualization Extensions is to make it easy to use complex models (say, from a CAD application) and render them interactively in real time. However, the key word is "extension." Microsoft has embraced the extension mechanism in Fahrenheit in the sense that it's designed to be a very friendly environment for "plug-in" technology, and the Large Model Visualization Extensions serve to illustrate this fact (as well as providing functionality to an existing vertical market). The extension mechanism is designed to encourage third-party software developers to write extensions that add value to the basic Fahrenheit package.

The Large Model Visualization Extensions will operate in conjunction with the Scene Graph API. The Large Model Visualization Extensions add functionality that will allow the interactive manipulation of large 3D models such as an entire automobile. The Large Model Visualization Extensions add functionality such as multiresolution simplification to the Scene Graph API, so developers can easily write applications that will interact with extremely large visual databases. This technology will also be designed to enhance legacy applications with new large model visualization capabilities.

The Low-Level API
This is where there's the least amount of information. The low-level API is, as I see it, Microsoft's way of gracefully admitting that it's tired of fighting the API wars, that Direct3D isn't the best model for 3D graphics, but then again, neither is OpenGL. OpenGL's pace of improvement is pokey at best, while Direct3D's is fast and uneven. Neither API fits into the "modern" 3D hardware accelerated needs of the future PC user. SGI is a natural partner to help Microsoft design the "next generation" of API. The low-level API is intended to address the short-comings of Direct3D and OpenGL, and provide a well designed API that will provide for future needs.

So, what does Fahrenheit mean to legacy applications? Will my OpenGL and DirectX applications still run? Will I have to give up my 3D library and code to Fahrenheit? The answer is yes, legacy applications will still run. Microsoft intends to keep OpenGL alive as long sufficient demand exists. Let's face it, Microsoft did just about everything but kill OpenGL directly. There's such a demand for OpenGL that it's going to hang around for a while. Besides, all the IHVs that bought into Microsoft's party line, who had to dump their MCD drivers, then scramble to come up with an ICD rather than tell folks that their card couldn't run GLQUAKE, are not going to believe Microsoft if they say that Fahrenheit is the only API they need to write to. There's plenty of unemployed folks who believed this the first time around. So if you're happy with OpenGL, then Fahrenheit will probably not have much of an effect until you discover a need to move to Fahrenheit.

Direct3D is another matter. Fahrenheit is intended to replace Direct3D, but this time, Microsoft is actually going to ask around, submit questions, and try to do it right. They've seemingly learned their lesson about trying to push acceptance of an ill-thought-out API. That didn't work very well, so they've decided to rework Direct3D into a kind-of super-OpenGL API that has good high-level support, an extension mechanism, and the features that game developers have been asking for. Since Fahrenheit is intended to replace Direct3D, Direct3D as an API will die. (More properly, it's COM interface will continue to exist, but it won't be the focus of development effort.) Direct3D legacy applications will continue to run though Fahrenheit. You can still run your WinG applications, can't you? Direct3D applications will continue to work, but the new stuff will show up in Fahrenheit.

One of the interesting things that I did was to actually get SGI and Microsoft to sit down and talk about what they were planning. I asked a lot of tough questions and both companies were quite open, avoiding none of my questions. As you can tell, I'm not particularly enamoured with Microsoft's Direct3D/OpenGL efforts, but I will give them credit for continuously to try to improve 3D graphics on PCs, even if they made some bone-headed decisions along the way. I've come to see Fahrenheit as a large step in the right direction, one that could have profound effects upon 3D graphics, making it ubiquitous on Pcs - which is as it should be.

How?
There's been a lot of animosity between SGI and Microsoft, especially between the engineers. In most cases, they may not actually know each other, but the SGI guys wonder what-in-hell those Microsoft guys think they're doing, while the Microsoft engineers have put up a momentous struggle to improve an immature API to the point of acceptability (and are still working on it). This has created a lot of confusion in the 3D graphics area. Microsoft pushed Direct3D and eventually (essentially) ignored OpenGL, while the OpenGL zealots jumped at every opportunity to point out how crippled Direct3D was - justifiably or not. The OpenGL folks had the moral highground, while Microsoft had muscle, and the API wars raged. IHVs were lying to Microsoft (just ask any of them) while appearing to goose-step on command. Word quickly spread that it was tough to peddle chips that couldn't run GLQUAKE. Mini-GLQUAKE driver and ICD skunkworks sprouted up. Chaos reigned.

Microsoft - one of the richest software companies in the world, employing probably the single greatest collection of graphics talent on the planet, possessing market influence only dreamed of by most companies, and chock full of programmers - can't, in nearly three years, come up with a API that anybody says is good. The best that's said about Direct3D is it's usable (but these same folks are eyeing all those ICDs coming down the pike). The use-it-or-else/we-know-what's-best attitude has done nothing other than cause confusion and loathing. The attempt to control the API and reduce support calls is a dismal failure. Something has to be done.

SGI, once supremely smug in its own little workstation world has come to the shocking realization that NT workstations are rapidly gaining ground as people figure out that a $5,000 PC has nearly the same horsepower as a $25,000 workstation. SGI has done some soul searching and decided that it has to embrace change, embrace NT. Customers are demanding it. Besides, the layoffs and defections are really annoying. The company is losing ground at the low and middle end to NT machines, while Sun is being aggressive at the middle and high end. Something has to be done.

The stage is set.

Who?
The principles are Kurt Akley (co-founder, vice president, and chief engineer of SGI) and Jay Torborg (director of graphics and media at Microsoft and head of DirectX). They've know each other for years, generally from working on OpenGL issues. Since SGI is now "in the fold" (read as: an NT reseller), what's good for NT is good for SGI. Confusion as to the best graphics API was bad for NT, hence bad for SGI's PC-based workstation future. While working on the DDK agreement, Akley and Torborg speculated on fixing the other problems with graphics on PCs. What could be done? Fahrenheit!

So there ya go. That's how Fahrenheit came about.

When?
As mentioned before, Fahrenheit is composed of three different parts. Two of the parts are based upon existing code, and these pieces will be delivered first. The Low-Level API is still being designed and will be the last to make an appearance. With luck, this means that it will contain the best features of both OpenGL and Direct3D.

What does this mean for Direct3D? Well, you can pretty much draw the conclusion that, as an API, Direct3D is an admitted commercial-nonsuccess. In spite of the number of games written for Direct3D, generally even those adopters of the technology don't have a great deal of compliments. O.K., so Microsoft bites the bullet and comes out with a new API. If Microsoft can peddle two operating systems, a low-end and a high-end, then the transition to two 3D graphics APIs is easy. (Say, this sounds familiar.) Fahrenheit can be considered the next generation of 3D API, with the Direct3D API supported as a legacy API by Fahrenheit. Direct3D as found in DirectX 6, actually.

What does this mean for OpenGL? Well, Microsoft says that it will continue to support OpenGL as long as there is interest in the API. In reality, it's tough to get rid of an API entirely. You can still program WinG applications if you want, for example, but it's not actively supported. So it is with OpenGL. Since Microsoft is still an ARB member, you'll see OpenGL 1.2 for Windows 95/98 and NT. However, if Fahrenheit takes off, then you might see the twilight of OpenGL on the Windows platform - but not in this century.

What does this mean for chip makers? This is an interesting question. They're all interested in selling more chips. The processor companies are all putting graphics features on their CPUs. Better graphics means more sales because you can do lots of cool stuff with 3D. The 3D chip makers hate - with all their heart - the Direct3D/OpenGL fight, as they are caught in the middle. While most of them were totally blindsided by the Fahrenheit announcement, the low-level stuff is so far off that it gives them some breathing room. Intel is selling its own 3D chip now, so that (plus AGP plus MMX2) tells you that Intel thinks 3D is important. (Some folks think that Intel considers 3D so important that they are entering the market to show how 3D is "supposed" to be done.) I think that there'll be a "thinning" of the 3D IHVs, so that by the time that Fahrenheit Low-Level makes its appearance, we'll be left with some very focused companies

What does this mean for game developers? Nothing much yet, as it turns out. However, the two pieces of Fahrenheit that are coming out first are directly related to making it easy to create and manipulate large, complex scenes. The guys at SGI who wrote these things are tasked with the job of making SGI boxes run quickly - more quickly than anyone else's. One way SGI does this is to have the best hardware, but the other way is to reduce the amount of information that has to be sent to the graphics hardware. These guys have spent years refining techniques based upon real feedback from customers. I tell people that I like working with OpenGL on PCs because I get to bottom-feed all the optimization techniques that SGI pioneered years ago. Now SGI is getting into the act with both feet.

So suddenly there's going to be a tuned model library that will be able to reduce a huge, complex scene to a managable load. Automatic viewport culling, dynamic model LOD generation, caching, and more will all suddenly be made available. The complexity of scenes will jump, probably by more than an order of magnitude. The bar is going to be raised, and quite suddenly, by quite a lot. Now, this isn't to say that frame rates are going to increase dramatically. The standard framerate by Christmas 1999 will probably be at monitor refresh rates anyway. No, what it means is that you'll suddenly be able to tell your artists that the scene polygon budget has gone from 2,000 polygons to 20,000 to 30,000. Texture memory will jump from 3 or 4MB to 50 to 100MB (caching and AGP will help here). The release of MMX2/Katmai will mean that you'll let the API do the transformations and lighting calculations. Multipass renderings will become very common. And don't forget the Talisman features. Talisman is still being worked on (look at DirectX 6), and there are still benefits to its architecture. It'll be a whole new ball game.

This what I've been able to find out about Fahrenheit. In a nutshell, Microsoft has joined forces with SGI to come out with a new API. SGI wants to sell NT boxes, and wants 3D graphics to be really fast on its own systems - better performance than consumers will find anywhere else. SGI has lots of smart folks who've done nothing but think about how to make graphics faster, either by building better hardware or making full use of existing hardware. Microsoft has an interest in making graphics fast and in making the PC an excellent multimedia/gaming platform. It also wants to rid itself of the annoying support problems inherent with the current multiple-driver/API setup. (Something we all would like to see simplified.) What could screw it up is if Microsoft does the "create a low-level API in a vacuum" thing again, but it seems that they have gotten smart and have indicated they'll solicit feedback from developers.

How does all this cooperation affect the OpenGL DLLs?
TBD. There are no current plans to merge the DLLs. We're focusing on the ICD DDK right now.

How will the Low-Level API be built? The higher-level libraries are mostly coming out of existing or spec'd out SGI projects, so most of the work is/will be done on them by SGI. The low-level stuff isn't even designed yet. Who's going to do the work?
Probably pretty evenly divided. We don't want to break compatibility with existing applications, but we do want to incorporate new technology.

The SGI products that Scene Graph and Large Model Library are based upon were designed for different markets than gaming. What's being done to address the game developer's needs?
We're using these products as a starting base to bring them to market as quickly as possible, but we're going to make sure that they (and Scene Graph in particular) are made suitable to a broader set of markets, gaming in particular.

How does Fahrenheit relate to DirectX?
Fahrenheit will be released as a new version of DirectX, it won't replace DirectX. Fahrenheit is the code name of some components of a future DirectX release. Fahrenheit drivers will be compatible with the DirectX 6 driver model.

Will Fahrenheit run on Windows 9x or just Windows NT?
DirectX will continue to be distributed for Windows 9x. Some parts of the Scene Graph will not be supported in Windows 9x, such as the multiprocessing features.

Will Fahrenheit really be COM-based?
The APIs of all three will be COM-based, and, depending on performance and functionality tradeoffs, they will also be COM-based internally.

Will is run on any other platforms?
Support on SGI's IRIX and HP's HP/UX are planned for Scene Graph and LMVE. The Low-Level API will be Windows only.

Direct3D has no extension mechanism, while OpenGL does. (Extensions are a way of accessing a particular hardware feature in a standard way.) Will Fahrenheit be extensible?
The Scene Graph will be highly extensible and we will be encouraging IHVs to create extensions to support features found on their hardware. In fact, application developers can also extend the API to provide features for their applications. We expect that third-party developers will create and sell extensions for vertical markets. The Large Model Visualization Library will use this same extension mechanism. Microsoft is investigating ways in which it can provide an extension capability that offers enough flexibility to be useful without compromising driver quality or platform consistency. Also planned is support for a driver model specifically for high-end workstation vendors, which will allow them to add vertical market hardware extensions to meet unique market requirements. We do not expect this latter driver model to be used for consumer hardware products.