WASA: A toolkit for producing interactive graphics applications

The Wasa system, developed at the Center for User Oriented IT Design (CID) at the Royal Institute of Technology (KTH), is a toolkit for the production of applications with a high-quality graphical content. It provides a flexible abstraction of the modern graphics hardware pipeline that can be configured through either program code or scripts. This makes Wasa suitable for rapid-prototyping work. Wasa also contains a number of higher-level entities that are used frequently in visualization, e.g. particle systems, scenegraphs and heightfields. Furthermore, the feasability of using Wasa in the teaching of interactive computer graphics is being investigated.

Modern graphics hardware is becoming increasingly complex: the fixed function graphics pipeline of yesterday is being replaced by flexible, programmable pipelines. Thus, there is a tendency in the state-of-the-art graphics application production industry to try and create programmable abstraction layers above this hardware (e.g., [2], [1]). Although many of these abstractions are efficient, they are frequently too specialized or inflexible for research work. They may be, for example, targeted at the computer gaming industry (which makes efficiency rather than extentionality and portability a primary goal) or at a specific application like the production of material property description (which makes it difficult to utilize the tool in other contexts).

At the Center for User Oriented IT Design, the Wasa system has been under development for the last two years. Its initial design as a scenegraph-based utility library has grown into a configurable abstraction of the computer graphics hardware pipeline, while retaining much of its original higher-level functionality. We are not aware of any other work that provides a similar combination of a flexible, easily configurable hardware pipeline abstraction with higher-level tools.
For the kinds of applications we are developing at CID, we find that a large amount of time is spent "tweaking" variables and parameters related to the graphical presentation and its supporting systems. If this "tweaking" involves editing computer source code and recompilation, this process can become very cumbersome and lengthy. Thus, one of the main goals of the design of Wasa is to reduce the time spent on "tweaking" as much as possible. Thus, the functionality of the toolkit can be accessed both from scripts and regular C++ code, which makes it possible to produce an initial prototype application rapidly through scripting, that can then be converted into more efficient C++ code at a later time.

Wasa overview
Figure 1 below shows an overview of the Wasa design. The central component of Wasa is the renderer, i.e., the abstraction of the graphics hardware pipeline. Modern programmable pipelines can roughly be divided into three stages:
1. Operations on vertices: transformation, lighting, projection. A vertex program can replace the standard functionality.
2. Clipping and rasterization into fragments/pixels, texturing.
3. Operations on fragments: color blending, depth testing. Additional functionality can be accessed through fragment programs.
The pipeline is largely configured through state variables, e.g., variables that determine what the hardware should do at each stage in the pipeline. Typically, some of these variables remain more or less fixed throughout the lifetime of an application (e.g., the state variables values required to achieve the illusion of a certain surface material), whereas other variables may change from frame to frame (e.g., transformation matrices). In Wasa, variables whose values change infrequently are configured through shaders that are defined in text files, while the remaining variables are modified directly through C++ code or scripts. The entities that are sent to the renderer for rendering are termed renderables.

Figure 1. The design of Wasa.

In Wasa, the sources of interactive graphical renderings are geometry and/or image data. Images are typically used for texturing and can be loaded from most popular file formats. Geometry is always reduced to streams, i.e., graphical primitives (e.g., triangles or quadrilaterals) consisting of connected vertices, in addition to optional data associated on a per-vertex basis (e.g., normals or texture coordinates). Streams can be imported from file formats supported by Maya and 3D Studio Max.

The combination of a particular shader with a specified set of geometries is termed an object (or model). Objects are example of higher-level Wasa entities. Examples of such entities include scenegraphs and heightfields. Each such entity defines its own API and configuration mechanisms. For example, objects are defined in text files or can alternatively be created through a C++ API. Wasa is designed to make the addition of new entities as seamless as possible: the only assumption is that new entities declare themselves as renderables by implementing a particular Wasa C++ class interface.
Most of the functionality of Wasa can be reached through scripts. In order to the use of multiple scripting languages, we use SWIG [3] to convert C++ interfaces into scripting language equivalents. Supported languages include Tcl/Tk, Python, Perl, Ruby and PHP.

If the scripting language supports the development of graphical user interfaces, it is also possible to prototype user interfaces. Figure 2 shows a simple Wasa application with a graphical user interface developed in Tcl/Tk.

Figure 2. A Wasa prototype with a Tcl/Tk user interface.

Wasa in graphics education
Because Wasa allows the graphics pipeline to be configured more easily than through commonly used APIs like OpenGL and Direct3D, we believe that Wasa is suited for the teaching of interactive graphics. As an initial test of this hypothesis, we held a three-hour workshop entitled 3D Graphics for "Dummies" in December 2002. The workshop had no prerequisites other than previous experience with computers (no programming skills were needed). It was divided into two parts. It begun with a large group discussion where the participants were guided to construct an understanding of the graphics hardware pipeline (see [4] for examples of this kind of didactics). Here, Wasa was used to provide examples that, due to the rapid prototyping features, could easily be modified "live" to provide different conceptual perspectives. In the second part of the workshop, the participants were allowed to experiment with Wasa and the graphics pipeline themselves.

Although we did not have time to do any formal evaluation of the workshop, all participants described it as interesting and useful. A majority also stated that the workshop helped them in understanding how interactive graphics work. We believe that this result had not been possible to achieve if we had used a standard graphics API like OpenGL.

References
1. Lalonde, P. and Schenk, E. Shader-driven compilation of rendering assets. In Proceedings of ACM SIGGRAPH 2002, 713-720.

2. Vlachos, A. Designing a Game's Shader Library for Current & Next Generation Hardware. Presentation held at the Game Developer Conference, 2002.

3. http://www.swig.org/

4. Twomey Fosnot, C. Constructivism. Theory, Perspectives, and Practice. NY: Teachers College Press, 1996.

Uppdaterade 2003-03-05

Cybermath - a virtual museum created in Wasa

Real light captured in photographs lights a virtual rabbit in realtime