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., , ). 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.
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
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  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  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.
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.
4. Twomey Fosnot, C. Constructivism. Theory, Perspectives, and Practice.
NY: Teachers College Press, 1996.
CID 1996-2000 | About this website | email@example.com
Cybermath - a virtual museum created in Wasa
Real light captured in photographs lights a virtual
rabbit in realtime