Game Engines for Visualization - The Study Stream

Game Engines for Visualization
Nick Green and Alex Pang
Computer Science Department
University of California, Santa Cruz
ABSTRACT
Game engines include several specialized components for supporting
different aspects of computer games. They often include a
graphics engine, a physics engine, an artifical intelligence engine,
a sound engine, network support and user interface toolkits to handle
different modes of input and game play displays. A resource
manager or a scene management system may also be part of a game
engine. Because of the realtime nature of computer games, these
components are usually highly optimized and very efficient. In this
paper, we investigate how one can take advantage of these capability
in building visualization systems. Specifically, we revisit the
Spray Rendering system, describe how its functionality can be implemented
and enhanced with the use of game engines, and describe
a sample implementation.
1 SPRAY RENDERING
It has been 15 years since Spray Rendering [4, 5] was first introduced.
Spray rendering is a visualization framework that uses the
metaphor of spraying paint to visualize data. It uses smart particles
(sparts), delivered from spray cans, that can seek specific targets
and follow specific behaviors. A primary difference between spray
rendering and other visualization systems is that rather than pumping
data through a network of modules, spray rendering sends sparts
(one can think of these as intelligent agents) through the data. As
a result spray rendering can theoretically handle massive data sets,
whether gridded or particle-based, more efficiently than a data flow
approach. However, the efficiency of spray rendering is dependent
on a number of factors – primarily the complexity of the sparts and
the number of active sparts. Optimizing interactions among large
numbers of semi-intelligent entities, such as sparts, and the 3D environment
environment, which includes the data and its artifacts,
is something game engines that support massively multiplayer online
role playing games (MMORPG) excel at. It allows for more
complicated and optimized spray rendering techniques to be rapidly
implemented. Next, we discuss how different components of game
engines can be used to carry out visualization tasks in the context
of spray rendering.
2 ARTIFICIAL INTELLIGENCE
Game engines often provide a set of libraries to assist with steering
behavior of a non-player character (NPC), in this case a smart
particle, to navigate around its world, seeking out a given target
while avoiding what it sees as threats. Steering behavior can also
make decisions based on the actions of peers, in this case, other
sparts. Game engines provide a means for sparts of the same group
to share information, and act upon this conveyed information [1].
Using steering libraries from a game engine, particles may actively
seek out their targets, they can choose where to travel in their n-
dimensional data set based on information from other smart particles,
or from the data itself.
3 NETWORKING
One of the most powerful feature of spray rendering is the ability
of sparts to communicate with each other. Sparts may communicate
directly with other sparts within their local neighborhood just
as boids communicate with each other [6]), or indirectly by leaving
messages in the form of rendered or non-rendered artifacts for
other sparts, or by posting to a common “message board” that other
sparts can access. The ability to communicate allows sparts to work
as a team to identify more complex targets than an individual spart
is capable of finding. Game engines provide a means for NPCs
to act as a group, communicating information amongst each other
and basing behavior such as steering upon the information passed
among these entities. Sparts may use this same inter-entity communication
to form groups and identify complex structures located
within a data set and then render a visualization of these structures.
Furthermore, these NPCs can step through time-varying data just
as easily as multivariate data sets. The optimization of this communication
and group-based behavior in game engines allows these
groups to be fairly large, contain complex target definitions, and
still be feasible in real-time.
4 PHYSICS
Collision detection and handling are usually found in physics engines.
We can use the collision detection system for its rich spatial
partitioning schemes to help sparts efficiently navigate through data
space – quickly skipping regions where there is no data. Game engines
generally maintain a scene graph associated with a spatial partitioning
scheme, and this graph can keep track of the data density
of particular regions and whether or not data within the bounds of
the target is present. Scene graphs can also be used to keep track of
which data has been visited, and relay information from sparts who
have already been to a given space to sparts who later encounter
the same space. And where there may be data, bounding volume
checks provide another layer of efficiency.
5 GRAPHICS
Fast hardware based rendering is the forte of graphics engines. The
artifacts found by sparts can be passed to graphics engines for efficient
rendering allowing the users to see the data as they are being
discovered. Fast rendering allows interactive exploration of large
data sets in conjunction with the ability of sparts to vary their scope
of interest (e.g. by adjusting their neighborhood size) which in turn
varies the level of detail of data visualization. Points of interest can
be zoomed in for more detailed exploration. Scene graph hierarchy
can also be exploited by the graphics engine to further improve its
rendering speed.
6 THREADS
Game engines also provide a set of valuable libraries for efficient
multi-threading. As spart visualizations require many instances of
different algorithms to be simultaneously active, multi-threading
is an important optimization to make spray rendering attractive.
Multi-threading in game engines is fairly young, but most game
engines do partition physics, rendering and other code into separate
threads [2, 3]. Thread support for sparts will need to be more
fine-grained – at the level of individual NPC. This is one area where

spray rendering will need to drive further development of support
and management of large number of threads.
7 SOUND
The goal of understanding and gaining insight from data sets is not
restricted to mapping data to visual channels. Sonification have
been found to be effective in communicating information as well.
Sound in games adds realism and reflects the mood of the game.
This is supported by sound engines that can dynamically adjust
playback parameters, be triggered by proximity sensors, etc. These
capabilities can also be used to map data to sound. The combination
of scene graphs and audio engines allow sound clips to have
fairly advanced behaviors. For example, an audio clip could only
be triggered if the conjunction of the output of two sparts produce
a positive outcome. Allowing such complex behaviors would help
preserve the significance and meaning of sound and keep it from
over-use. 3D positional sounds e.g. OpenAL, can allow users to
know when one or more of his sparts have found an important piece
of data and intuitively localize where the data was found.
8 GUI
User interfaces for playing games must be intuitive whether it is
controlling a first person shooter (FPS) game or directing an entire
army. The metaphor of using cans of spray paint is ideal for an
FPS type interface. In our sample application described below, the
user’s ability to shoot sparts from the camera’s viewpoint was implemented
with basic a GUI API. Game engines provide efficient
yet simple to use features such as firing and switching weapons i.e.
spray cans and hence type of sparts being fired.
9 SAMPLE IMPLEMENTATION
We have some initial results of implementing this idea using Open-
Steer (http://opensteer.sourceforge.net/) as the game engine.
The primary strength of OpenSteer is in controlling crowd behavior
– which corresponds to the primary task of controlling the behavior
of sparts. We describe how some spray rendering visualization
techniques can be realized using OpenSteer.
9.1 Isosurface Rendering
In this visualization, the user chooses the target (scalar threshold)
that the sparts are searching for. Upon finding their target, the sparts
render a small polygon that is oriented on a plane perpendicular to
the gradient of the data at that point, centered at that point. The
color of the polygon can be mapped to the scalar magnitude at
that point. Alternatively, the red, green, blue components can be
mapped to the components of the gradient.
9.2 Streamline Rendering
In this visualization, sparts will set their trajectories to that of the
data they have encountered. Each spart will proceed to travel along
the trajectory of the data at its current location. As each spart travels,
it will leave behind a polyline to indicate its path. A target may
also be associated with each spart e.g. velocity magnitude, which
can be used to control the generation of a streamline. For example,
if the velocity magnitude has fallen below a specified threshold, the
streamline may be terminated.
9.3 Explosive Tracing
Typically, an FPS interface is used to deliver the sparts into the
data space. An alternative is to allow sparts to spawn themselves.
As before, the spart are fired towards the data until it finds its target.
It then analyzes its six immediate neighborhoods and for each
of the adjacent points that also satisfies its target conditions, this
spart spawns another spart traveling towards that direction. Positions
that have been visited are marked. This procedure is applied
Figure 1: Image shows results using two types of sparts. Isosurface
sparts render the low-magnitude portions of the data, while streamline
sparts show the flow pattern.
recursively. For sparts that find streamlines, spawned sparts traveling
within valid data also leave behind a color mapped line.
Figure 2: This visualization starts from one spart that recursively
sends sparts to adjacent spaces where target data is found. Each
new spart renders a small segment of a streamline. All data matching
the original sparts target, and reachable from the first target data
found is discovered. The gray area visible on some edges are many
sparts, still finding target data and spawning new sparts.
10 CONCLUSION
We are interested to find out how one can take advantage of game
engines to perform visualization. The different components of a
game engine i.e. AI, physics, graphics, networking, sound, etc. can
be readily mapped to the Spray Rendering paradigm. Our initial investigation
uses the OpenSteer game engine. Results are promising,
and we plan to incorporate other game engine functionality such as
networking and physics.
REFERENCES
[1] Valve. http://source.valvesoftware.com/SourceBrochure.pdf, 2008.
[2] R. Chabukswar, A. Lake, and M. Lee. Multi-threaded rendering and
physics simulation. Technical report, Intel, 2005.
[3] H. Gabb and A. Lake. Threading in 3D game engine basics.
www.gamasutra.com/features/20051117/gabb 01.shtml, 2005.
[4] A. Pang and N. Alper. Mix & Match: A construction kit for visualization.
In Proceedings: Visualization ’94, pages 302–309. IEEE Computer
Society, 1994.
[5] A. Pang and C. M. Wittenbrink. Collaborative 3D visualization with
CSpray. IEEE Computer Graphics and Applications, pages 32–41,
March 1997. Special issue on: 3D and Multimedia on the Information
Superhighway.
[6] C. W. Reynolds. Flocks, herds and schools: A distributed behavioral
model. Computer Graphics, 21(4):25–34, 1987.