The Fahrenheit Initiative

Feature

The Fahrenheit Initiative

The Fahrenheit Initiative promises major benefits for multimedia developers

Fahrenheit is the code name for the partnership between Silicon Graphics and Microsoft to design and implement new 3D graphics APIs for the Windows, IRIX, and HP-UX platforms.

The Fahrenheit APIs will enable a new class of graphics-rich applications with higher performance and graphics quality than ever before. Fahrenheit-based applications will enjoy the benefits of performance, standardisation and portability, and will make optimal use of available hardware resources.

The Fahrenheit initiative defines three new APIs that can be thought of as three "layers" of APIs. They are:

Fahrenheit Low Level API

Fahrenheit Scene Graph API

Fahrenheit Large Model API

The functionality of each of these APIs can be described as follows:

Fahrenheit Low Level ( this is a rendering API, similar to OpenGL and Direct3D Immediate Mode. Its function is to abstract the underlying hardware and to provide programmers with a way to render a simple set of graphics primitives such as points, lines and polygons.

Fahrenheit Scene Graph ( this is a Scene Graph API that provides programmers with a higher level of abstraction than that offered by a low-level API. The Scene Graph defines a data structure that holds all graphics information relevant to an entire scene, allowing programmers to manage all scene-related data in a consistent fashion. Because the Fahrenheit Scene Graph API works at the scene level, it can perform aggressive optimisations that cannot be achieved at a lower level.

Fahrenheit Large Model ( This API is an extension to the Fahrenheit Scene Graph API. It extends the base scene graph with features and capabilities that are especially useful to those applications dealing with very large models, typically found in the CAD environment. Fahrenheit Large Model adds functionality to simplify large models, convert mathematical descriptions of curves and surfaces to polygonal primitives, and enables interactive manipulation of large models.

The Fahrenheit Scene Graph will be strongly influenced by Silicon Graphics' experience in implementing several scene graph toolkits, including IRIS Performer, which is extensively used in high-performance, real-time visual simulation applications, as well as the broadcast industry and in high-end entertainment applications. The Fahrenheit Scene Graph will additionally benefit from other scene graph toolkits, including Open Inventor and Cosmo 3D.

The Fahrenheit Large Model API will be strongly based on the Silicon Graphics OpenGL Optimiser product and on technology from Microsoft and Hewlett-Packard's DirectModel product.

What is a scene graph?

A scene graph is a data structure that describes a 3D scene. It typically holds the geometry of all objects in the scene as well as their appearance such as colour, transparency, and textures. Other information contained in the scene graph can include light sources, camera position and more. The data structure used is a hierarchical tree-like structure in which the scene graph data is often organised spatially; i.e. objects that are close together in the actual scene are also close together in the scene graph.

The scene graph is traversed repeatedly by the scene graph toolkit to carry out different scene management tasks. A spatial organisation of the scene graph makes it possible for many common traversals to be very efficient. Each traversal can have a different purpose.

For example, one traversal of the scene graph might determine visible geometry from a certain viewpoint, while another might be used to determine whether two objects have collided. A common traversal is the "draw traversal," during which the visible geometry is sent to the rendering library for display.

For programmers one of the key benefits of a scene graph is the level of abstraction it provides when compared to programming to a low-level API such as OpenGL or Direct3D Immediate Mode. The scene graph frees the programmer from the minutiae of programming to the rendering API and allows the programmer to concentrate on what is to be drawn, rather than how it is to be drawn. Scene graph programming can be considered to be declarative as opposed to procedural. For programmers this means less code and less complexity.

The difference between programming to a scene graph API and a low level rendering API is similar to the difference between programming in assembly language and in a high-level language such as C++. Assembly language programming (like using a low-level rendering API) gives the programmer very fine-grained control of the machine and has the potential to be very fast. In contrast, C++ is much easier to program and the compiler can perform application-level optimisations. When high-level languages were first introduced, many skilled assembly language programmers resisted them claiming they were inefficient. Today's compiler technology has improved so dramatically that the benefits of high-level languages vastly outweigh the disadvantages. Similarly, modern scene graphs have become indispensable for many graphics applications.

To understand why many application developers choose to incorporate a scene graph in the design of their applications, it is helpful to trace the evolution of a typical graphics application.

When a graphics application is first developed and is still in a rudimentary stage, software developers often take the most direct approach to producing the desired graphical output in their application. The code is written to explicitly produce a desired scene, so that the code that does the calling of the appropriate low-level rendering API is intertwined with the code that defines the scene content. The advantage of this approach is that the application can quickly be built, and that results can be shown immediately.

The problem with this approach is that in order to change the scene content, a significant amount of program code needs to be added or changed. For all but the most trivial requirements the resulting complexity quickly becomes unmanageable. In order to reduce this complexity the drawing of the scene is de-coupled from the scene content.

This allows developers the freedom to change scene content without requiring corresponding changes in program code. To bring about this separation, the scene content needs to be captured in a suitable data structure, which then serves as input for the program's drawing process. This approach allows for scalability of the scene content and scene complexity.

As the scene content becomes increasingly large and more complicated, it becomes apparent that while the separation of scene content and program code has reduced complexity, improvements in efficiency are needed to maintain acceptable performance and memory usage. For example, many scenes are much larger than can be seen at any one time within the observer's field of view. It is obviously wasteful for the drawing process to spend time attempting to draw scene content that can't be seen by the observer. There is a clear need for scene management functionality to provide the required efficiency. One example of scene management could be to constrain the drawing process to render only those elements of the scene that fall within the current field of view.

It is through these steps of reducing complexity and improving efficiency that software developers implement scene graphs within their applications. One difference between those scene graphs and the Fahrenheit Scene Graph is that the self-developed scene graphs often solve scene management problems in a way that is very specific to the current application.

The Fahrenheit Scene Graph, on the other hand, is designed to be more generally applicable and, as such, has an advanced extensibility model, support for multi-processing and many other features that are appealing to developers but would be prohibitive to produce.

A scene graph provides the programmer with a convenient framework for managing objects in a scene, and also makes it easy to express the relationship between those objects. For instance, it is useful to group related objects in a common co-ordinate system so that even when an object is moved or rotated, the relationship with related objects is not disturbed. For example, if in a flight simulator application an airplane object has a landing gear object attached to it and the application software changes the orientation of the airplane to bank left, the relationship between the airplane and the landing gear would be maintained. The landing gear would automatically undergo the same rotation as the airplane.

In addition to expressing the relationship of objects in a scene, a scene graph can also improve the scene rendering performance. A common method is "level of detail" management. Because the scene graph knows the position of the eyepoint (the camera), it can easily determine which objects are near the eyepoint and which objects are far away.

Then, in order to improve rendering performance, the scene graph can use an alternate representation, with a lower level of detail, of the objects that are far away. It is not necessary to draw the chimney on a house that is far away. Similarly, when the eyepoint changes so that the house starts to come clearly into view, the scene graph can switch to a higher level of detail in which the chimney is now shown. If the hardware supports it, the scene graph could manage the transition from one level of detail to the next level by smoothly morphing between the different representations of the object.

Another example of a task often performed by scene graphs is "view frustum culling". Simply, once the scene graph toolkit knows the field of view from the current eyepoint, it can determine which objects in the scene are outside the field of view and consequently eliminate them from further processing. The result of this operation is that the graphics hardware can spend its time productively, rendering objects that can be seen instead of spending valuable time working on objects that are outside the field of view.

Once the scene graph toolkit has performed all the relevant operations on a scene, such as level of detail selection and view frustum culling, the toolkit has all the information it needs to actually start drawing the scene. It would be possible at this stage to simply send the geometry and appearance information to the graphics hardware for rendering.

However, at this point there is a further opportunity for the scene graph to optimise rendering performance by first sorting the data that is to be drawn. Most graphics hardware systems maintain a "state" in which rendering is performed. One of the elements of the graphics state includes the current colour, so that if a blue area is to be drawn followed by a red area, the graphics hardware needs to change its state from blue to red at the appropriate moment. Often, this change of state takes valuable time.

To improve rendering performance, the scene graph sorts the data to be drawn by state so that the number of state changes that the hardware needs to make is minimised. Drawing three red areas followed by three blue areas is much more effective than drawing the areas in the order red, blue, red, blue, red, blue. In the latter case, six state changes are needed compared to just two in the sorted case.

By minimising the required state changes the scene graph further speeds rendering. Once all scene graph processing has taken place, and the geometry and appearance relevant to the current scene can be identified, the state sorting stage can make an important contribution to reducing rendering time. Sophisticated scene graph processors such as Fahrenheit Scene Graph provide many more capabilities for managing scene content and optimising overall rendering performance. The preceding examples illustrate just some of the benefits that Fahrenheit Scene Graph brings to developers.

The key benefit of abstraction, which is provided by scene graphs in general, is also provided by Fahrenheit Scene Graph. It also offers many additional benefits.

Traditional scene graphs typically describe the polygonal geometry of a scene, but Fahrenheit Scene Graph also enables the additional storage of sounds, animations, volumetric data and so on. The Fahrenheit Scene Graph, through its extension mechanism, allows other scene-relevant data to be stored in the scene graph. One example of this capability is the Fahrenheit Large Model extension, which provides support for higher-order geometry such as NURBS, within the scene graph framework.

Another benefit for programmers using the Fahrenheit Scene Graph is in the area of performance tuning. No matter which graphics hardware is being used, from the simplest to the most advanced, making hardware-specific adjustments or tweaks to the software will always remain necessary to achieve the highest level of performance. In order to provide users with maximum performance, effective performance tuning requires developers to have an in-depth understanding of each of the different hardware platforms their applications will run on.

For example, certain operations will execute very quickly on some hardware, whereas the same operations (or combinations of operations) need to be avoided as much as possible on other hardware. Fahrenheit Scene Graph's broad extensibility capabilities make it possible for hardware vendors to ensure that Fahrenheit Scene Graph is cognisant of the performance characteristics of their hardware. The result is that a large part of the application programmer's burden in performance tuning shifts to the hardware vendor.

Another issue that developers have to contend with is the disparate feature sets of different graphics hardware, often forcing the software developer into a "lowest common denominator" approach. When programming to the Fahrenheit Scene Graph, the programmer can concentrate on the scene to be drawn and let implementers of the Fahrenheit Scene Graph for a specific hardware platform make sure that the Fahrenheit Scene Graph makes use of the features offered by that hardware platform.

Fahrenheit Scene Graph makes it possible for novice programmers to achieve professional results, and through its design and extension mechanism, enables professional programmers to have very fine-grained control over the workings of the scene graph and the hardware on which it is executing.

It also offers benefits to hardware developers. Hardware developers have typically been confined to implementing acceleration and optimisation of low-level rendering APIs. Fahrenheit Scene Graph offers a pervasive, industry-standard scene graph API that makes it possible for hardware vendors to expand their scope for innovation to a higher level than before. Because Fahrenheit Scene Graph "knows" a lot more about the scene as a whole, and knows a lot more about the intentions of the application software, it is able to support more aggressive optimisation than is possible by optimising at the rendering API level only.

Fahrenheit Scene Graph's extension mechanism makes it possible for hardware developers to selectively extend or re-implement portions of the scene graph in order to utilise special hardware capabilities, present the hardware with data that is optimally formatted for its internal architecture and re-order the drawing process to achieve optimal performance. The application software needs no specific knowledge of the graphics hardware but in this way can still achieve maximum performance and make automatic use of special hardware features.

There are numerous benefits for end users too. As Fahrenheit Scene Graph will lower the barriers to creating 3D applications, users will see an increase in the number of 3D applications, their capabilities, and quality. Fahrenheit Scene Graph's ability to incorporate many different types of data in the scene graph (such as polygonal, volumetric, image and audio) will result in applications that are more media-rich than before. End users also directly benefit from Fahrenheit Scene Graph's ability to use their graphics hardware to the fullest extent.

The Fahrenheit initiative and the Fahrenheit Scene Graph, in particular, are well matched to the challenges faced in computer graphics today. The increases in the availability of 3D graphics hardware and users' increasing requirements establish a clear need for an industry-standard scene management framework through which innovation can be delivered.

The increased availability of 3D graphics hardware is apparent across a range of hardware from low-end consumer level to high-end professional systems. It is estimated that there will be 30-40 million PCs with hardware 3D graphics acceleration produced in the next year. Moreover, it is estimated that the rate at which these products are released and adopted will continue to accelerate.

At the same time, there is a clear increase in the complexity and amount of information that users need to visualise. Across the entire spectrum of applications, from entertainment to scientific visualisation, from collaborative engineering to decision support, there is an insatiable demand for graphics computing power as users strive for increased realism, complexity, and interactivity.

While end users are becoming increasingly demanding, the intricacy of graphics programming has also grown enormously. Programmers are faced with the need to support a bewildering array of hardware and software platforms, which are being released more rapidly than ever before. As the amounts of data and complexity continue to grow, the need to support multiple CPUs in traditionally single-CPU environments is becoming ever more apparent. The need to deliver highly scalable solutions and cross-platform support is another important issue with which developers must contend.

Fahrenheit Scene Graph goes a long way toward addressing these issues. By providing a high-level, abstract interface, developers are shielded from many of the complexities brought on by different low-level rendering APIs and differing, incompatible hardware.

Fahrenheit Scene Graph's transparent, automatic support for multiple processors as well as its cross-platform availability will enable developers to concentrate on their core competencies and on adding value, instead of on chasing graphics features.

Compiled by Ajith Ram

( Microsoft 1999


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in June 1999

 

COMMENTS powered by Disqus  //  Commenting policy