Microsoft had licensed OpenGL from SGI in the mid-1990s to be put into their Windows NT operating system as its basic 3D system. At the time OpenGL was rapidly becoming the de-facto 3D standard on workstations, and as MS was attempting to position NT as a workstation-class system, OpenGL was a requirement.
Confusing matters somewhat was the fact that Microsoft had recently purchased RenderMorphics to gain access to their RealityLab 2.0 product, a 3D API aimed primarily at the "low end" market. After renaming it as Direct3D 3.0, Microsoft released it as the primary 3D API for Windows 95 and game programming. This sparked off a massive debate, both in Microsoft and out, about the merits of the two APIs and whether or not Direct3D should be promoted.
Through the mid-90s SGI had been working on a series of efforts to provide a "higher level" API on top of OpenGL to make programming easier. By 1996 this had evolved into their OpenGL++ system, a retained-mode C++ API on top of OpenGL. They proposed that a modified version be used as a single API on top of either OpenGL or a new high-performance low-level API that Microsoft was known to be working on. This would not only hide the implementation details and make the OpenGL/DirectX war superfluous, but at the same time offer considerably better high-level interfaces for a more robust object oriented development environment.
In late 1997 both SGI and Microsoft started work on the system as the Fahrenheit project. SGI was to provide the primary "mid-sized" API used in most applications, Fahrenheit Scene Graph, as well as a modified version for handling very large models from CAD applications, Fahrenheit Large Model. Microsoft would provide a new low-level rendering engine for Windows known as Fahrenheit Low Level, essentially a replacement for Direct3D. The project was officially announced at SIGGRAPH 1998 for release in late 1999 or early 2000.
Fahrenheit became the primary focus of development at SGI. Their MIPS-based workstations were quickly losing the performance lead they had in the early 1990s, and the company was in serious trouble as the average PC slowly but surely encroached on the high-end graphics market. SGI saw Fahrenheit as an exit strategy; once complete they would be able to move to a PC-based lineup while still offering the best development tools for a now universal API. At the same time they started porting their existing widely-used toolkits such as Open Inventor and OpenGL Performer to be hosted on Fahrenheit, meaning that they could deliver a single fully-functional development system for Fahrenheit when it shipped, supporting both their existing customers as well as new ones.
By 1999 it was clear to SGI that Microsoft had no intention of delivering Low Level. Although officially working on it, almost no resources were dedicated to actually producing code, and at the same time MS was in the process of investing massively in DirectX 7.0 (similar to 3.0 largely in name only). Without Low Level, Fahrenheit couldn't be delivered, and the project stalled. Since SGI's primary interest in the project was to provide an exit strategy from their MIPS based machines onto Windows-based PCs, SGI was in the terrible position of watching Microsoft destroy their business plan without really trying. Eventually SGI gave up, asigned their rights to Microsoft, and re-wrote their business plan.
By 2000 DirectX 7.0 was in the marketplace, and proving quite popular. It became the primary 3D interface during the rise of 3D games in the late 1990s. Microsoft did release Scene Graph as XSG the same year, but did so with a note saying it would not be supported. No new versions of XSG were ever released, and all of the pages related to either Fahrenheit or XGS on both the Microsoft and SGI web pages have since disappeared. OpenGL support was dropped in Windows 2000.
As compared to Open Inventor or Iris Performer, the design of the XSG included some novel ideas. The composition primitives and traversal methods allowed applications to construct scenes in a manner best suited to the structure of the data being visualized, but then to apply a scene graph optimizer to restructure the scene for more efficient rendering without changing the scene's appearance. The developer simply did whatever seemed natural, and the system made it work quickly.
Pipelined rendering allowed a multithreaded application to construct the scene, cull its primitives, and render it in different threads (borrowing from the Performer app-cull-draw pipeline). The representation of primitive scene data was optimized to minimize the amount of data stored so as to avoid completely duplicating it on a thread-by-thread basis.
One of the unique features of XSG was the ability to replace most of the built-in methods for walking the graph with your own versions. Developers could write new functions for quickly traversing their known methods of storing data inside XSG, and then chain them into existing rendering paths.