An architecture for an extensible 3D interface toolkit.
This paper presents the architecture for an extensible toolkit used in construction and rapid prototyping of three dimensional interfaces, interactive illustrations, and three dimensional widgets. The toolkit provides methods for the direct manipulation of 3D primitives which can be linked together through a visual programming language to create complex constrained behavior. Features of the toolkit include the ability to visually build, encapsulate, and parameterize complex models, and impose limits on the models. The toolkit's constraint resolution technique is based on a dynamic object model similar to those in prototype delegation object systems. The toolkit has been used to rapidly prototype tools for mechanical modelling, scientific visualization, construct 3D widgets, and build mathematical illustrations.
Introduction
There have been many advances in 2D user interface toolkits [8][10][11][12]
which allow developers to rapidly prototype 2D interfaces. Recent attempts
have been made to advance user interfaces into 3D [3][4][5][7][13][15] and it is
natural to develop a toolkit that aids in the rapid prototyping and
construction of 3D interfaces. Visual toolkits have the added benefit that non-programmers
can also be interface developers. Due to the difficulty in
specifying complex behavior in 3 dimensions, the task of specifying interfaces
in 3D is difficult and time consuming, but a visual 3D toolkit provides the
means to make interface construction in 3D feasible for both programmers
and non-programmers.
In this paper, we present an architecture for a toolkit used in constructing
three dimensional widgets, interactive illustrations, and three dimensional
interfaces [5]. The toolkit provides direct manipulation of 3D primitives
through a visual language. These primitives are used to construct widgets,
interface objects, and application objects whose geometry is affinely
constrained. Constraints can apply not only to the geometry but also to other
non-geometric attributes such as color, visibility, and transparency. The
toolkit has been improved over the prototype (described in [18]) by enhancing
the visual language to support parametrized procedures through
encapsulation, inequality relationships through limits, and constraints of non-geometric
attributes. We have also enhanced the interface for specifying
relationships between primitives in three ways. First, we have provided
options for linking behaviors. Second, we included mechanisms for breaking
constraint relations. Finally, we added visual feedback for displaying
constraint relations. This paper presents the underlying architecture of the
toolkit. For further information on the UI see [22].
The visual programming paradigm of our toolkit has significant advantages
over methods used by other toolkits, such as libraries [12][15] and graphical
networks [1][8][10]. The traditional approach to designing user interface
toolkits is to use libraries of software objects which are created using standard
programming languages. This makes the task of visualizing the complex
relationships between these objects difficult. It also rules out the possibility of
non-programmers using them to do interface prototyping. The second
paradigm is based on the graphical manipulation of function networks. In this
paradigm, the developer wires together 2D boxes that have no direct relation
to the application objects they represent. Our toolkit's direct manipulation
paradigm has both the advantage of direct manipulation of application objects
and a visual language that allows non-programmers to use the toolkit for
interface protoyping.
We have used the toolkit for creating mathematical illustrations, such as the
Decastelljau algorithm (Figure 7 (a)) that are used as teaching tools,
constructing many of the 3d interface widgets (Figure 7 (b)) presented in
[5][9][14], building tools for scientific visualization (Figure 7 (c)), and in a
collaborative project between Brown University and the University of Utah
building interactive tools for mechanical modeling operations such warps,
blends, and sweeps (Figure 7 (d)).
In section 2.0 we explain the toolkit architecture and fundamentals. In section
3.0 we discuss the visual language. In section 4.0 we present the conclusion of
our work. In section 5.0 we discuss future work.
(a) (b)
(c) (d)

Figure

Example uses of the toolkit (a) Mathematical Illustrations (the Decastelljau algorithm)
(b)3D Widgets (the rack), (c) Interfaces for scientific visualization (the rake), (d) Tools for
interactive mechanical modelling (the warp tool).
2.0 Toolkit Architecture and Fundamentals
The toolkit was designed with two main goals in mind: to enable both
programmers and non-programmers to rapidly prototype 3D interfaces, and to
provide a design that can be extended to easily add new primitives and
behaviors between primitives.
To allow rapid prototyping for non-programmers, we base our toolkit on direct
manipulation of visual primitives. Each primitive has a set of characteristic
traits that uniquely defines the primitive. For example, a vector primitive is
defined by its position and direction. To allow interface designers to create
objects with complex interactive behavior, we need the ability to relate
characteristic traits of one visual primitive to those of another. We think of
complex objects as many simple objects that are constrained to each other
[18]. These constraint relationships can be bi-directional (related objects affect
each other) and, in the limit, these relationships can become extremely
complex and contain cycles. We call this relating of traits linking. Links are
established through the toolkit's visual interface. The toolkit also allows for
the modification of these traits. The traits are modified when a link is
established, or a primitive is manipulated by the user. Primitives, therefore,
know about input devices, so they can modify themselves in response to user
interaction. These modifications must be made without violating previously
established relationships.
To create a toolkit that can easily be extended, we chose an object oriented
design for the underlying toolkit structure. Since a primitive changes its
behavior dynamically, we based our primitives on dynamic objects similar to
those in prototype delegation based object systems [19][20]. The dynamic
objects are instanced from a class that represents each primitive. Each class
contains data fields called slots, which represent the characteristic traits of
the primitive. Conventional languages provide no support for the linking
operations described above. We must, therefore, provide mechanisms to
specify constraint relations (which slots are related and how) and to maintain
constraints (ensuring consistency between slots during user interaction).
These constrained relationships could be maintained through a variety of
techniques, but each has it associated problems. Numerical solvers [21] have
problems with performance and numerical error, and forward propagation
solvers [23] have problems with priorities, invertability, and cycles. For
simplicity, ease of extension, and speed, we chose a simple resolution scheme
where for each slot in a primitive, the class designer supplies inquiry and
assignment constraint methods to get and set the value of a slot. We make this
scheme manageable by exploiting dynamic inheritance mechanisms in our
class design. As constraints are added to a primitive's slot, the inquiry and
assignment methods are updated to maintain the new constraint behavior
(see section 3.2.1). Although our solution technique lacks some of the
expressive power of the techniques mentioned above, we have found that a
wide variety of interfaces [5][14][9][18] can be represented with a small
number of reusable constraint methods. Our technique has no
unpredictability in its solution as do numerical solvers, no problems of
invertability and priorities as forward propagation solvers, and has the
additional benefit that the toolkit is interactive for even complex models.
Though we have chosen this particular solution technique for solving
constraints, this does not preclude the possibility of other solution techniques
being plugged in as a back end to the toolkit in the future.
3.0 Visual Language
We introduce a visual language for constructing 3D interfaces. This language
provides the framework for the visual construction of constraint relationships
between toolkit primitives. The language consists of classes represented by 3D
toolkit primitives. These classes contain typed variables called slots. Slots on
classes can be linked to establish constraint relationships between primitives.
We can then create new classes by encapsulating complex collections of
constrained primitives. These encapsulations add new primitive classes to the
toolkit and can be optionally parametrized and called (like a subroutine) to
recreate complex constructions.
3.1
A class is an abstraction of the geometry and behavior of a toolkit primitive. A
geometric object is associated with each class to provide a visual
representation. The class behavior is defined by the slots on the class and the
class's interaction technique. We define a constraint relationship between two
class instances by linking slots on those classes.
3.2 Slots
Slots are typed variables in our visual language and represent the
constrainable quantities of a class. Each primitive has a geometric
representation and one or more slots which define its behavior. The slots are
used to establish constraints on a primitive. Each primitive is initially
unconstrained.
A linking operation is effected through the interface by the selection of a
destination primitive slot and a source primitive, followed by explicit user
confirmation. This link sets up a bi-directional data flow between the slot on
the destination primitive and the source primitive.
Interaction techniques specify how to modify a slot during user interaction
while maintaining the constraint relationships of the other slots. For
example, if a point's position is constrained to a line and the point is then
manipulated, the constraint can be resolved either by moving the point along
the line or by moving the line with the point. The interaction technique chosen
is one of, or a combination of, these solutions. When a link is established, a
new interaction technique is associated with the primitive to reflect this new
constraint. The toolkit supports translational and rotational interaction
techniques. We could have selected a fixed interaction technique for each type
of link but this would prevent the user from selecting the interaction
technique best suited for a particular problem. We, therefore, provide options
and leave the choice to the user.
3.2.1 Slot Inquiry and Assignment
An inquiry method computes the value for a constrained slot. For example, if a
vector's position slot is linked to a point and the vector is resolved (see section
3.2.2) then the vector position's inquiry method is invoked with the point
being passed as a parameter (Figure 2).
In this simple constraint the vector's position slot inquiry method simply gets
the value of the points position slot (Figure 3).
Alternatively, if the vector's position is modified we must assign the new
position back to the point. The assignment method determines how a
constrained slot maps back to the primitive to which it is constrained.

Figure

2 Data flow between the vector primitive and the point primitive when linking the position
slot of the vector to a point.

Figure

3 The Result of inquiry for a vector's position slot from a point
Destination
Source
Position
Direction
Length
Vector Primitive
Point Primitive
inquiry
Destination Source
Position
Direction
Length
Vector Primitive Point Primitive
Position
Assignment methods give the constraint its bi-directional behavior. Inquiry
and assignment methods can be more complex: they may apply some function
to one or more slots on the primitive to which the slot is constrained to
determine the value of the constrained slot.
The inquiry/assignment solution could be burdensome: it might require the
specification of both methods for all possible combinations of data types. But
our toolkit bases these constraint methods on the type of the slot and the class
of the primitive to which it is constrained. This scheme allows the reuse of
these constraint methods thus decreasing the number of methods a class
designer needs to write.
3.2.2 Constraint Resolution
We provide a detailed example to illustrate the linking process and how
constraints are resolved. In this example, we link a vector primitive's position
slot to a point primitive. We first select a vector primitive as the destination
primitive, and then a point primitive as the source primitive. In the toolkit UI,
an arrow is drawn between the two primitives to indicate the pending link

Figure

4).
We then select the slot of interest (in this case, the Pos slot) on the destination
primitive through a MOTIF window (Figure 5). We are now presented with a
list of possible options for establishing the constraint.
(a) (b)

Figure

Linking Primitives (a) link pending for vector's position slot to a point primitive, (b) link
established.

Figure

5 The vector primitive's slots and the linking options for linking to a point primitive.
These options combine the inquiry and assignment methods, the interaction
technique, and the methods for establishing the constraint. In this case, we
choose the default which has the behavior of basing the vector at the point. An
alternative behavior could be positioning the base vector a relative distance
from the point. Finally, we confirm the link by clicking on the glue bottle. The
link is then established between the position slot on the vector primitive and
the point primitive. A link is created internally by storing a pointer to the
source primitive in the linked slot of the destination primitive and by storing a
pointer to the destination primitive in a list on the source primitive.
Constraint establishment is accomplished through an establish method.
Establish methods exists for each particular type of link and do the work of
setting up and initially satisfying the constraint. After the link is established
and the user translates the point, the toolkit intercepts the mouse interaction
and passes the mouse information to the point primitive's interaction
technique. Since there are no constraints placed on the Pos slot of the point
primitive, the interaction technique sets the value of the position slot to the
new mouse location. The interaction technique then calls the point's resolution
method. A resolution method is a method defined on each primitive that
resolves the slots of the primitive, updates the graphical representation of the
primitive, and, finally, calls the resolution methods of all of the primitives
linked to it. If a slot is linked, then the slot is resolved by inquiring its value
from the primitive to which it is linked.
Continuing with our example, the point primitive's interaction technique
wrote a new value into the point's Pos slot and called the point's resolution
method. Since the Pos slot of the point is not linked, the resolve method has
no further effect on the Pos slot and the point is redrawn at its new position.
Next, the point's resolution method calls the vector primitive's resolution
method. When the vector primitive's resolution method resolves its Pos slot, it
updates the slot by inquiring its value from the point primitive. The return
value of the inquiry is the value of the Pos slot of the point primitive. Since
the vector's Dir and Len slots are not linked they are not changed. The vector
is now redrawn with its base at the position of the point primitive. A summary
of the flow of control is depicted in Figure 6.
Now when the user translates the point, the base of the vector follows the
point. Similarly, if the user attempts to translate the vector, the interaction
technique of the vector allows the vector to freely translate and then assigns

Figure

6 Flow of control summary in constraint resolution when a vector's Pos slot is constrained
to a point.
Mouse interaction with point
Point's interaction technique
Point's resolution method
Vector's resolution method
Resolution of vector's Pos slot
the new value of the position back to the point, which in turn updates the
vector.
3.2.3 Dynamic Slot Creation
A link may not necessarily constrain all of the degrees of freedom of a slot.
(The degrees of freedom of a slot are the ways in which a constrained slot is
free to vary.) These remaining degrees of freedom are represented by a
dynamically created new slot on the primitive. For example, if we constrain a
point primitive's position slot to a vector, then the point gets projected onto the
vector and the point's new interaction technique allows it to move along the
line defined by the vector. A new slot, therefore, is created on the point
primitive, called the T slot, which represents the parametric position of the
point along the vector. This slot is now constrainable and can be used to
restrict the point's location along the line.
In a more complex constraint resolution example with a point's Pos slot being
constrained to lie on a vector, the resolution method for the point resolves the
Pos slot by first resolving the T slot, and then passes the value of the T slot
and the vector to the inquiry method for the point's Pos slot which returns a
position along the vector. These dynamically created slots are defined on the
primitives on a case-by-case basis.
3.3 Description of Toolkit's Core Primitives
In this section, we describe the core set of primitives defined in the toolkit.
There is a fundamental difference between this toolkit's primitives and those
in the prototype widget construction toolkit [18]. The difference stems from
the definition of a primitive. The original toolkit had primitives, consisting of
multiple pieces of geometry, and constraints between these pieces of geometry.
In some ways, the name primitive was a misnomer. In our toolkit, each of the
primitives has exactly one piece of geometry to represent it and all of the slots
start out unconstrained. We designed our primitives to be simple, but
powerful enough to build the more complex primitives in the prototype toolkit.
This approach reduces the unnecessary and confusing clutter of complex
primitives. The philosophy of this toolkit is based on the idea that more
complex entities can be created from the simpler primitives using the
encapsulation methods described in Section 3.4.
As in the prototype toolkit, we base the basic primitives on the Euclidean
coordinate system metaphor (i.e., points, vectors, planes, and volumes).
Previous experience has shown that this allows for the expression of a wide
variety of constructions. It should be noted that this primitive set, although it
has a fair amount of expressive power, is by no means adequate for all
conceivable constructions. The toolkit was designed to allow for the easy
addition of new primitives or the extensions of existing primitives as the need
for new behaviors arise.
The toolkit contains four basic primitives: the point primitive, the vector
primitive, the plane primitive, and the graphical object primitive. Each
primitive has an associated class which is an abstraction of the geometry and
behavior (including interaction methods) of the primitive. Figure 7 shows the
4 basic primitives.
The point primitive, represented by a small sphere, has one constrainable slot,
the Pos slot, which is of the type position. The Pos slot is an abstraction of a
three space position. The default interaction technique on this primitive is the
translation of the point in 3-space.
(a) (b)
(c) (d)

Figure

7 Toolkit primitives (a) point primitive, (b)vector primitive, (c) plane primitive, (d)
geometric object primitive.
The vector primitive, represented by a small arrow, has three slots, a Dir slot
of type direction, a Pos slot of type position, and a Len slot of type length. The
Dir slot represents the direction of the vector, the Pos slot represents where
the base of the vector is in 3-space, and the Len slot represents the length of
the vector. The default interaction technique of the vector primitive is the
rotation of the vector, which sets the value of the Dir slot. By default the
vector's Pos slot is located at the origin and the Len slot is set to 1.0.
The plane primitive, represented graphically by a flat sheet, has five slots, the
Normal slot of type direction, the Center slot of type position, two Size slots
for the length and width of the sheet both of type length, and the Up slot of
type direction. The Normal slot represents the normal to the sheet, the Size
slots represent the scale for the length and width of the sheet, and the Up slot
represents the orientation of the sheet (similar to PHIGS VUP).
The final primitive, the graphical object primitive, encompasses all of the 3D
modeled objects (e.g., cubes, spheres, CSG's) available in UGA, Brown's
modeling and animation system [16]. This primitive is similar to the plane
primitive in that it has slots that represent the local 3D coordinate system of
the modeled object, i.e., Normal, Up, Center, and Size in three dimensions.
We extend these slots to include other non-geometric attributes of the modeled
object; for example, we have added Red, Blue, and Green slots of type real to
represent the object's color.
3.4 Encapsulation
Encapsulation is the process by which networks of linked primitives are
stored and recreated by the toolkit. The toolkit supports two types of
encapsulation, structural encapsulation and class encapsulation, both of
which can be optionally parametrized using a technique called parametrized
encapsulation.
3.4.1 Structural Encapsulation
Structural encapsulation aids the user by reproducing a network of linked
primitives. For example, we might link a vector to two points so that the
vector spans the two points (Figure 8).
(a) (b)

Figure

8 Vector primitive spanning two point primitives (a) before linking, (b) after linking
This is a construction we will use repeatedly, so we encapsulate it and name
the encapsulation "line". The encapsulation process creates a new "line" menu
item (

Figure

9).
A user who clicks on the "line" menu item gets a vector and two points with all
the links of the original network that were encapsulated. The new network's
behavior is identical to the original.
Structural encapsulation is implemented by traversing the constraint
network of a construction and creating copies of all of the primitives and the
links in the network. These copies are then stored by the toolkit but not drawn
on the screen. When a structurally encapsulated object is requested, copies of
all the primitives and links associated with network are created. These new
primitives are then drawn.
(a) (b)

Figure

9 Primitives menu (a) before "line" creation, (b) after "line" creation
3.4.2 Class Encapsulation
Class encapsulation is similar to structural encapsulation in that the
constraint network is traversed and copies of all the primitives and links in
the network are created. It differs in that we associate a new class with the
collection of primitives in the encapsulated construction. We can think of this
as creating a new primitive in the toolkit. Let's change our ``line'' example
above to use class encapsulation. Now when we encapsulate the vector and
points construction, we also specify a class for the encapsulated construction,
in this case the class "Line". The point and vector primitives' classes are
changed to the class Line. This class modification changes the linking
behavior of the primitives. When we link to a structurally encapsulated
construction, we link directly to the simple primitive the user clicks on. For
example, if we link a primitive to the vector primitive in the structurally
encapsulated line, we are actually linking to the vector primitive, which is of
the class vector. In class encapsulation, when we link to the vector primitive
within the line, we actually link to the Line primitive. This allows new
constraint behavior to be defined on the class encapsulated primitive. The new
class encapsulated primitive behaves identically, during interaction, to a
primitive created with structural encapsulation, but its behavior can be
overridden as described below.
New classes are implemented by creating a new primitive which has slots for
each primitive in the encapsulated network. These slots can optionally be
named by the user when the object is encapsulated. In the line example, a
Line primitive is created with slots for the two points and the vector called,
respectively, start_point, end_point, and center_span (see Figure 10).
Assigning new classes to networks of primitives provides a mechanism for
changing the interactive behavior associated with a network of primitives. For
example, if we try to rotate an endpoint of the structurally encapsulated line,
nothing happens because a point primitive has no rotational interaction
technique. If we use class encapsulation, then when we click on the point
primitive, we are actually referring to the Line primitive. In class
encapsulation, by default we get the same interactive behavior as the
structurally encapsulated line. Perhaps we want the Line primitive to rotate
around its center when we rotate an endpoint. Since the Line primitive
knows about all of its components, we can associate a rotational interaction
technique with the Line primitive that rotates the line about its center,
maintaining the constraints associated with the construction. Now a user who
tries to rotate an endpoint of the Line gets the desired behavior.

Figure

10 The slots on the line primitive created by class encapsulation
Line Primitive
start_point
end_point
point primitive
point primitive
vector primitive
center_span
3.4.3 Parametrized Encapsulations
The ability to encapsulate and recreate constructions can be thought of as
invoking a subroutine to create a complex primitive. We introduce the ability
to parameterize these subroutines which we call parametrized encapsulation.
Often when we encapsulate a new class there are primitives in the network
that we would like to keep as parameters. In our visual programming
language, the primitives are the parameters to our subroutines. For example,
if we create a line primitive as illustrated above, we might want to create it in
such a way that we can create a line between any two existing points. In
effect, we create a "line subroutine" that takes two endpoints as parameters.
In our line subroutine, the endpoints can be any two points or any other
primitives with the following restriction: the parameter passed must have a
slot with the same slot type as the original primitive in the encapsulation. In
this example, the parameters must each have a Pos slot.
To create a parametrized encapsulation, we specify the primitives which are to
be parameters and name them. When the class is created, the named
primitives are marked as parameters. When users create a new primitive
from a parametrized class, they are first prompted for primitives for the
parameters. If no parameters are specified when the new primitive is created,
then a duplicate of the primitive with which the encapsulation was originally
created is used. One could say that the original parameters act as defaults for
the parameters of the encapsulated object.
The ability to parametrize encapsulations greatly increases the usability of
widgets like the interactive shadow widget [9]. The interactive shadow widget
creates a shadow of an object by creating a scaled copy of the object and
projecting it onto a shadow plane. These shadows are then used to
interactively position objects. In the previous prototype, there was no way of
creating a shadow widget on different objects without re-specifying all of the
linking operations. In our toolkit, we might use a structurally encapsulated
class, but this would create fixed primitives for the shadowed object and the
shadow plane, which is of limited usefulness. By using parameterization we
can specify that both the object to be shadowed and the shadow plane as
parameters to the encapsulation.
3.5 Limits
There are many problems for which equality constraints are insufficient. As
an example, consider a color picker made from three lines with points
constrained to each of the lines. The three points slide up and down their
respective lines, representing each point's distance from the start of its line as
a fraction of the total line length. This fraction represents the percentage of
red, blue, and green that are in the color of an object. In the standard RGB
color model, color values are restricted to the interval between zero and one,
but the toolkit allows the point to slide freely on the line. This produces values
that can be greater than one or less than zero, which results in the color
functions receiving invalid parameters.
We support comparison operators on slot variables, such as "greater than" and
"less than", through limits. Limits impose additional restrictions on the data
that flows between slots in the toolkit. Limits are imposed by associating
limiting functions to slots. When a primitive's resolve method is called, it in
turn calls methods to resolve each slot on the primitive. After the slots have
been resolved, the slots are then limited. The limiting methods checks the slot
value to insure that it falls within a given range. If it does not, the value is
adjusted to be within the desired range.
To continue with our color picker example, we can limit the point to lie on the
line between the endpoints (as shown in Figure 11). This is accomplished by a
limiting function which limits the value of the T slot of the point to the values
between zero and the length of the vector. If the line segment is of unit length,
then the color routines will receive valid values. An additional benefit to limits
is that the point does not move past the ends of the line, providing the user
with visual feedback on the valid point positions.
With this ability to limit values we can enhance the representation of our color
picker by making an RGB cube and limiting a point to lie within that cube, or
making an HSV cone with a point limited to lie within the cone. This greatly
extends our flexibility for interactive widget design.
4.0 Conclusions
Our toolkit provides a framework for the construction of a wide variety of
interactive 3D models used in modeling, animation, and scientific
visualization. The visual language provides an environment for both non-programmers
and programmers to conceive and rapidly prototype these 3D
models. Encapsulation and limiting mechanisms allow interface designers to
build more complex models than were possible in the past. Although our
(a) (b)

Figure

11 Limiting a point (a) point primitive without limits (b) point primitive with limits
imposed.
dynamic object model has its limitation in the types of relationships that can
be specified, it does not have the numerical inaccuracy or efficiency problems
of numerical solvers.
5.0 Future Work
Currently, when the user requests an encapsulation the entire network is
encapsulated. A user may wish to encapsulate a subcomponent of a complex
network. An interface for specifying the encapsulation of a sub component of
the network needs to be developed.
At this point we have no method for the visualizing how a constrained
primitive can be interacted with. For example, when a point is constrained to
lie on a line there is no visual feedback to indicate that the point can only
translate in the direction of the line or that the point cannot rotate.
Possibilities for this visualization are arrows indicating in which direction the
primitive may move, or altering the geometric shape of a primitive when it is
constrained (e.g., changing the point's sphere to a flat disk when the point is
constrained to lie in a plane).
To date, the slots on a primitive can only be linked to a single primitive. It
would be useful to be able to constrain a slot on one primitive to a slot on
another primitive or a slot on a primitive to more than one primitive. This
would allow for a wider variety of constructions to be built with the current
primitive set.
In our toolkit constraints are solved procedurally. Although this has
advantages, such as scalability, and the elimination of problems related to
numerical error and predictability that numerical solvers suffer, its main
disadvantage is that it leads to a combinatorial explosion in the number of
constraint methods as we add more primitives and types to the toolkit. As
numerical solvers become more robust, we will consider using one as the
constraint solver for the toolkit.
All of our primitives constrain physical attributes of objects. Primitives that
represent abstract non-physical quantities could be useful. For example,
temporal primitives might be useful in specifying how primitives change over
time, allowing us to build animations visually.
Slots on primitives are presented to the user via a Motif window. Slots should
be visual quantities of the primitive (perhaps depicted as a little socket). The
user could then wire the slots together directly instead of going through the
auxiliary window.
6.0

Acknowledgments

This work was supported in part by the NSF/ARPA Science and Technology
Center for Computer Graphics and Scientific Visualization and by ONR
Contract N00014-91-J-4052, ARPA Order 8225. We also gratefully
acknowledge the sponsorship of IBM, NCR, Sun Microsystems, Hewlett
Packard, Digital Equipment Corporation, and NASA. We thank Cindy
Grimm, Nate Huang, Kenneth Herndon, Andries van Dam and the members
of the Brown University Graphics Group for their help and support. We also
acknowledge the University of Utah for the surfaces provided for the
mechanical modelling examples and the use of the Alpha 1 modeler.
7.0



--R


Global and local deformations of solid primitives.

The information visualizer

Computer Graphics: Principles and Practice.

A visual programming language for interactive graphics.
Interactive Shadows.

GARNET: comprehensive support for graphical
OSF/Motif Reference Guide.
Graphics Interaction Techniques in constraint based geometric modeling.
Using deformations to explore 3D widget design.
An object-oriented 3D graphics toolkit
An object-oriented framework for the integration of interactive animation techniques
Aldus Inc.

The Power of Simplicity.
Sharing Between Graphical Objects Using Delegation.
A Graphics Toolkit Based on Differential Constraints.
A Toolkit for the Construction of Three Dimensional Interfaces.

--TR
Self: The power of simplicity
Computer graphics: principles and practice (2nd ed.)
Snap-dragging in three dimensions
Garnet
The information visualizer, an information workspace
An object-oriented framework for the integration of interactive animation techniques
CONDOR: constraint-based dataflow
Through-the-lens camera control
An object-oriented 3D graphics toolkit
Using deformations to explore 3D widget design
Interactive shadows
Three-dimensional widgets
An interactive 3D toolkit for constructing 3D widgets
A graphics toolkit based on differential constraints
Global and local deformations of solid primitives

--CTR
Jurriaan D. Mulder , Jarke J. Van Wijk, 3D Computational Steering with Parametrized Geometric Objects, Proceedings of the 6th conference on Visualization '95, p.304, October 29-November 03, 1995
Mark Green , Joe Lo, The Grappl 3D interaction technique library, Proceedings of the ACM symposium on Virtual reality software and technology, November 10-12, 2004, Hong Kong
Cindy Grimm , David Pugmire, Visual interfaces for solids modeling, Proceedings of the 8th annual ACM symposium on User interface and software technology, p.51-60, November 15-17, 1995, Pittsburgh, Pennsylvania, United States
M. C. Chuah , S. F. Roth , J. Mattis , J. Kolojejchick, SDM: malleable information graphics, Proceedings of the 1995 IEEE Symposium on Information Visualization, p.36, October 30-31, 1995, Atlanta, Georgia
Wai Leng Lee , Mark Green, Automatic layout for 3D user interfaces construction, Proceedings of the 2006 ACM international conference on Virtual reality continuum and its applications, June 14-April 17, 2006, Hong Kong, China
Mei C. Chuah , Steven F. Roth , Joe Mattis , John Kolojejchick, SDM: selective dynamic manipulation of visualizations, Proceedings of the 8th annual ACM symposium on User interface and software technology, p.61-70, November 15-17, 1995, Pittsburgh, Pennsylvania, United States
Leonidas Deligiannidis , Robert J. Jacob, Improving Performance of Virtual Reality Applications Through Parallel Processing, The Journal of Supercomputing, v.33 n.3, p.155-173, September 2005
Robert J. K. Jacob , Leonidas Deligiannidis , Stephen Morrison, A software model and specification language for non-WIMP user interfaces, ACM Transactions on Computer-Human Interaction (TOCHI), v.6 n.1, p.1-46, March 1999
constraints;delegation;visual programming;user interface toolkits;direct manipulation;interaction techniques