A Framework for an R to OpenGL Interface for Interactive 3D graphics

Abstract

We describe a framework for providing interactive 3D graphics in R. The key component is the interface between R and OpenGL, which provides a set of commands for specifying objects and operations that enable three-dimensional graphical visualization. An alpha version of the software, the core of which is written in ANSI-compliant C++, is available for testing and feedback (Win32 and X11).

Full text

Page 1

DSC 2003 Working Papers
(Draft Versions)
http://www.ci.tuwien.ac.at/Conferences/DSC-2003/
A Framework for an R to OpenGL
Interface for Interactive 3D graphics
Daniel Adler and Oleg Nenadi´ c∗
Abstract
We describe a framework for providing interactive 3D graphics in R. The
key component is the interface between R and OpenGL, which provides a set of
commands for specifying objects and operations that enable three-dimensional
graphical visualization. An alpha version of the software, the core of which is
written in ANSI-compliant C++, is available for testing and feedback (Win32
and X11).
An important goal in the design has been to facilitate portability to dif-
ferent operating systems. An object-oriented approach is used throughout. A
simple and intuitive user interface for navigating in 3D using a pointer de-
vice is provided by moving the viewer around the surface of a sphere that
surrounds the relevant space; the view is focussed on the centre of the sphere.
The focus of the current implementation is to manipulate 3D “primitives”
(for example points, lines, triangles, quads, spheres, text, etc.) which consti-
tute the building blocks for more complex 3D objects (such as histograms, per-
spective plots, scatterplot, axes, etc. ). A number of attractive OpenGL fea-
tures, such as multiple lighting, fog, texture-mapping, alpha-blending (trans-
parency) and side-dependent rendering are accessible directly from R via func-
tions that control shapes and appearance. Further functions control device-
and-scene management (opening closing windows, clearing selected objects),
environment setup (setting lights, bounding boxes, viewpoints) and export
(making and exporting snapshots). The calling sequences are similar to those
used in the existing and familiar R graphics functions, such as persp.
∗Institut f¨ ur Statistik und¨Okonometrie, University of G¨ ottingen

Page 2

DSC 2003 Working Papers
2
1Introduction
RGL1is an add-on library that extends the R system[2] with a 3D visualization
device system with interactive viewpoint navigation. It is implemented in C++
using OpenGL[4] as the realtime rendering backend.
A major goal of the project was to develop an appropriate abstraction to the
underlying operating system services (such as the windowing system and OpenGL),
so that porting to major R platforms with slightly different base services is possible.
The software can be delivered as an add-on package with no modification to the
original R source tree.
The RGL device system runs as an autonomous subsystem in the R run-time
process as the R device interface has been designed for plotting devices and lacks
interface requirements for 3D visualization.
The render engine and supported data objects are optimized for large dataset
geometry and appearance visualization using several speed-up techniques such as
display lists, fake visualization tricks and eye-candy special effects.
The library has been ported to the Win32 and X11 platforms so far, with support
for MinGW, GCC and Visual C++ (win32 only) compiler systems.
2 Visualization Model
Background
Viewpoint
Lights
Shape
Bounding?Box
Figure 1: A typical scene
The visualization model uses five base object types, that describe a complete
1Accidently, our project name collides with an R package written by Duncan Murdoch[3].
Allthough both projects deal with the same problem, our approach differs substantially in the
architectual part with the most evident difference beeing the cross-platform portability.

Page 3

DSC 2003 Working Papers
3
scene (see figure 1).
• Shapes are basic geometry informations and constitute basic building blocks.
Currently eight basic shape types are supported: Points, lines, triangles,
quadrangles, texts, spheres, surface and 3d sprites (screen-aligned quadran-
gles). Several attractive appearance properties can be applied to the geometry
such as solid colouring, lighting material, texture-mapping, alpha blending,
gouraud shading and side-dependant fill mode.
• The Viewpoint surrounds the overall geometry is focused on the center. In-
teractive navigation is provided using the pointing device which controls the
viewing direction (using polar coordinates), zoom and field-of-view.
• Directional Light sources define the lighting conditions.
• The Bounding Box tracks the range of the geometry and optionally displays
axis labeling.
• The Background provides either solid colour or an environmental sphere en-
closing the scene.
3Programming Interface
The RGL API comprises 21 R commands. Care has been taken to be semantically
compatible with the R plotting facilities where appropriate.
• Device Management Functions provide support for multiple devices. Devices
are automatically opened, in case one is required and none is already opened.
• Scene Management Functions provide support for undo operations.
• Shape Functions consitute the basic building blocks that can be combined to
build complex visualization scenarios.
• Environment Setup Functions provide control to background and bounding
box decorations, axis labeling, lighting conditions and viewpoint.
• Export Functions allow for making still picture exports.
• One Apperance Function is used internally by API functions to setup appear-
ance properties in a generic way.
Most functions call a counter-part C++ function in the shared library. A de-
tailed overview of the API is appended at the end of this paper.
4Architecture
To allow a seamless integration into the R system, the software design requires a high
degree of abstraction, so further to achieve the overall design goal of cross platform
portability. Due to the fact that R lacks a portable interface to the windowing
system and OpenGL, our architecture provides these services.

Page 4

DSC 2003 Working Papers
4
4.1Modules
api
scene
device
devicemanager
rglview
client
device
foundation?layer
x11?port
win32?port
lib
gui
types
math
pixmap
libpng
win32gui
win32lib
x11lib
x11gui
Figure 2: Architecture
Figure 2 gives a brief overview of the software modules involved in the archi-
tecture. The foundation layer represents the platform abstraction which consists of
five core services.
4.2 Foundation Layer
The lib module provides library initialization and destruction entry-points where
a platform specific integration strategy into the R system is implemented. The
gui module provides a portable object-oriented framework of components to build
graphical user-interfaces with support for OpenGL contexts and fonts. Back-end
modules represent the peers to the actual windowing system. Matrix/Vector arith-
metic classes with support for homogenous transformations, a common technique
in realtime rendering, are implemented in the math module. Common fundamental
datatypes and structures can be found in the types module. Datatype abstraction
for pixmap import and export is provided in the pixmap module. A png pixmap
datatype handler is currently implemented.
4.3Device system
The client infrastructure and device is implemented on top of this layer.

Page 5

DSC 2003 Working Papers
5
The api and device manager module constitute the client, while the device pro-
vides the interface and composes the device semantics using the graphical user-
interface component implemented in rglview. The core 3D engine is implemented
in the scene module.
4.4 Data model
Shape?Stack
Shape
Shape
...
Shape
Light?Stack
...
Light
Light
Background
Viewpoint
Bounding?Box
Slots
Figure 3: logical data model
The scene description is stored in a composite object model, which gets evaluated
by the render engine at a highly frequent rate. Figure 3 shows a logical data model.
Multiple shapes and lights are managed simulatenously, using a stack semantic.
Three additional object slots are managed which hold one object at a time. Slot
objects are replaced, while stack objects can be popped or optionally cleared at
once.
4.5 Minimalistic GUI toolkit
The GUI abstraction model has been designed using software patterns. Software
patterns support decision making in software design and might prevent from com-
mon pitfalls. The abstraction model can be characterized by two common patterns,
namely the Bridge and the Factory pattern taken from [1] (see figure 4). We sepa-
rate the windowing system abstraction and implementation using two class hierar-
chies. The abstraction hierarchy represents the base for user-interface component
development. The implementation interface hierarchy provides core base services
required to get the user-interface working (e.g. a specific windowing resource and
further specializations). A concrete factory object encapsulates concrete implemen-
tation instances of that platform, so that the abstraction uses the factory interface
to initiate an implementation object. Both hierarchies are bridged, so that win-
dowing events are injected into the abstract objects and core service requests (e.g.
drawing) are provided by implementation objects. The bridge gets built by pass-
ing an abstract factory interface at early startup to the abstract gui classes which
constructs their implementation counter-part at run-time.