Using OpenGL to Render in AWIPS

Michael Biere
29 October 2002

Overview

Some of the depictables that we render in AWIPS are CPU-intensive to calculate. Modern display boards have powerful display accelerators which might be used to advantage to offload some of the rendering from the CPU to specialized hardware. Using OpenGL provides a standard software interface for doing this. We propose prototyping certain AWIPS graphic operations with OpenGL, to determine likely performance gains, and overall feasibility.

Current AWIPS Rendering

AWIPS depictables currently render using X Windowing System calls. The X library is a low-level primitive graphics environment, with an integer coordinate space tied directly to the pixels in a window. To draw anything at a higher level of abstraction such as in latitude/longitude coordinates on one of the AWIPS map projections requires doing all the coordinate translation in advance before rendering. Minor viewing transformations such as zooming and roaming require redoing the calculations and re-rendering the entire window.

OpenGL and Modern Display Hardware

OpenGL is a 3D graphics software interface with broad industry support.  It includes a set of 2D drawing primitives as a special-case of the corresponding 3D primitives. OpenGL was designed to efficiently support modern graphics hardware accelerators, thereby offloading intensive rendering calculations from the host CPU.  Using OpenGL allows us to take advantage of specialized graphics hardware acceleration, but with an industry-standard software API.

The OpenGL coordinate space uses float coordinates which provides considerable flexibility over the integral coordinates of X.  OpenGL handles the coordinate transformation to the display window, with hardware support. Simple coordinate changes like zooming and panning can be handled by specifying a 3 by 3 coordinate transformation matrix, and having the hardware re-render.

OpenGL supports sophisticated color abstractions, such as alpha-channel blending, which might be used to more efficiently support certain AWIPS operations such as fade and combo.

OpenGL also supports display lists, which might be used for holding some AWIPS depictables in video card memory, making zooming and panning very efficient--possibly fast enough to support effectively instantaneous interactive panning.

The graphics primitives supported by OpenGL include large texture-mapped meshes, which appear promising as an efficient way to model a variety of meteorological imagery, from radar scans to model output.

Alternatives to OpenGL

Most 3D rendering libraries have been vendor-specific, such as Apple's QuickTime 3D, HP's Starbase, and Sun's XGL. OpenGL has generally supplanted all these, as platform-independence is now seen as a requirement for most applications. Standards-based alternatives include PHIGS and PEX, but these too have fallen behind OpenGL in general acceptance, probably because of the slowness of the international standards to react to new hardware advances. For example, texture mapping is not available in PHIGS or PEX. It is safe to assume that the 3D rendering wars have largely been won by OpenGL.

Prototyping OpenGL in AWIPS

There are a number of specific areas in AWIPS where we feel the use of OpenGL would yield significant performance or usability improvements. We describe prototypes of each of these areas sufficient to make an estimate of likely performance gain or usability enhancement. These prototypes are largely independent of one another, so we list them here as separate tasks, leaving some flexibility to pick and choose. Some initial overhead and familiarization with OpenGL will be required in any case, which we will call Task 0. To simplify the prototypes, we defer the messy AWIPS integration issues until after the basic OpenGL rendering concepts have been validated.

Task 0: Familiarization with OpenGL

This is the up-front overhead in becoming familiar enough with OpenGL to effectively use it for further prototypes. Expected level of effort is six weeks. Deliverables include a set of simple prototypes demonstrating various aspects of OpenGL, none of which have any particular relationship to AWIPS. Issues to be investigated include linking and building with the OpenGL libraries, exploration of the basic graphic primitives, color and lighting models, coordinate transformations, alpha-blending, double-buffering, etc.

Task 1: Rendering Radial Radar Data

The rendering of radial radar data is one of our more CPU-intensive operations in the AWIPS display. We theorize that a texture-mapped mesh might be an efficient way of rendering this data in OpenGL. To validate this, we propose a set of increasingly-accurate prototype activities. The first of these is a simplified display of sample radar data as an OpenGL mesh, with AWIPS-like zoom and roam. This is to validate the visual adequacy of displaying radar gates as elements of a quadrilateral mesh, and to estimate the computational efficiency of that display. We anticipate that this display will be visually adequate, but if not, further rendering experiments may be needed before continuing.

Once the basic OpenGL approach to radar data is adequate, we will want a more accurate performance prototype. We will combine multiple resolutions as AWIPS does, and animate a 32-frame loop of these, to get a better estimate of the loading and rendering overhead.

A rough estimate of the size of the OpenGL mesh follows. Assuming a typical case of 360 one-degree radials, each with 50 bins, yields 18,000 quadrangles (or 36,000) triangles, specified by 18411 vertices. Typical hardware rendering speeds are specified in millions of triangles per second, so rendering is not likely to be a significant overhead. On the other hand, several radar scans are likely be combined in each frame, so rendering overhead can't be dismissed out of hand.

Getting the data to the hardware may be more problematic. Roughly, each mesh will require 2 floats to specify x and y coordinate, plus a 32-bit color value.  That's 12 bytes per quadrangle, or a total of 216,000 bytes.  If we assume several scans per frame, we could easily exceed a Megabyte of data per frame.  If we keep the data on the graphics card, we'll need over 32 Meg of display memory. Otherwise, we'll need to shuffle over 10 Meg/second to the graphics card while animating.

In addition to the anticipated speed of rendering, zooming, and roaming, we anticipate being able to get rid of the radar transformation files that are currently created during localization. This should simplify localization and overall housekeeping within AWIPS.

Expected level of effort for this task is 4 person months (2 months elapsed time). I anticipate two weeks for the simple radar rendering, two weeks for the multiple-resolution animation demonstration, and four weeks for performance enhancements, other optimizations, and documentation and further discussions. Additional time is for support efforts (CM, staging, testing, admin, etc).

Task 2: Fade/Combo with Alpha-channel Blend

The hardware alpha channel can be used to specify the intensity or opacity of images. In this task, we will experiment with alpha-channel to efficiently implement single-image brightness, and multi-image combo. First, we will develop a prototype to use alpha-channel as a brightness control.  Then we will prototype using alpha-channel to fade between two images.  Finally, we will develop a prototype to fade between three images, a feat heretofore unheard of in AWIPS. Then, time allowing, we will add overall brightness control using OpenGL light sources.

Each of the above sub-tasks (one, two, three images, plus light source) is estimated to be a one-week task, the total level of effort for this task is one month plus one month of support.

Task 3: Continuous Roam Using Display-List Map Backgrounds

If map backgrounds were stored on the display card via OpenGL display lists, it should be possible to render them essentially instantaneously as we roam.  In this task we will write a prototype to do just that--display a map background which can be zoomed and roamed in AWIPS-like fashion, but with continuous drawing of the entire map as we roam.

This should be a reasonably simple thing to demonstrate. Level of effort is estimated to be two weeks plus 2 weeks of support.

Task X: Integration into AWIPS

Assuming one or more of the above tasks have been demonstrated to have sufficient merit for inclusion within AWIPS, we will tackle the rather difficult issue of integration into the AWIPS display capability, the IGC. Among the sticky issues to be addressed are:

Integrating OpenGL rendering with X drawables
Integrating alternative rendering mechanisms (OpenGL) into Depictables

This is likely to be a rather long task, since compatibility with existing code is a complex issue. Testing ramifications are likely to be significant as well. A rough estimate is on the order of 12 person  months for design, implementation, testing and documentation and
support.

The Risks

Since much of the current display software is highly optimized already, it may be that the performance gains we anticipate will not be realized in practice.

Some of the rendering algorithms we propose may require so much display memory that they don't work for more than a few frames, instead of meeting the full 32-frame AWIPS requirements.

Performance figures will be dependent on video card performance.