GEF goes 3D

Jens von Pilgrim

In his article, “Quo vadis Eclipse?”, Holger Voorman ventures a glimpse into the future. He describes, how model changes are visualized in a three-dimensional manner and how he can fly over layers of abstraction by his finger tips. The article explains how this is possible with GEF3D today – although we have to use the mouse for navigation.

In the area of model driven development, models play an
important role. Usually models are visualized by two-dimensional
diagrams, UML diagrams may be the most prominent examples. However,
in some cases two dimensions are simply not enough. Sometimes,
models require a three-dimensional representation, or multiple
two-dimensional diagrams should be displayed simultaneously. The
latter case enables the visualization of so called inter-diagram
relationships, that is connections between elements of different
diagrams. The GEF3D [2] framework enables the creation of
three-dimensional diagram editors in a very simply way.

GEF3D has been started as a tool in the context of the author’s
Ph.D. project, and it has become an Eclipse project in the autumn
of 2008. At the moment the project has only two committers – we are
always looking for more help from the open source community! Figure
1, an editor implemented by the author, gives an impression of the
capabilities of GEF3D. As foreseen by Holger Voorman, in the
future, two layers of abstraction are visible here, more precisely
a use case diagram which has been transformed into a robustness
diagram (cf. [3]). The elements of the diagrams are connected via
so called transformation traces. Traces are a typical example for
inter-diagram relationships, in this case they connect the source
and target elements of a transformation.

In the world of Eclipse, graphical editors are (almost always)
created using GEF [4] or GMF [5] (whereby GMF is based on GEF). The
basic idea of GEF3D is to extend GEF in order to support
three-dimensional editors. Thus, 3D editors can be implemented
using the same techniques and concepts that are used for 2D editors
– special knowledge in 3D programming is not required in most
common cases. Moreover, GEF3D provides techniques for adapting
existing 2D editors in order to use them within a 3D scene – we
call this phenomenon as “3D-fication” of 2D editors. This can be
achieved with a little effort. The overall strategy is to project
the output of the 2D editor onto a plane in 3D space, and to tweak
them a little bit for enabling 3D editing. A few example editors
are available in GEF3D to demonstrate this: The ecore editor (from
the EMF tools [6]) or a class-, activity-, and use-case editor from
the UML2 tools [7]. Actually Figure 1 shows the 3D-fied version of
the UML2 tools editor.

Below, we are going to present GEF3D in more detail. After a
brief explanation of GEF we will describe how GEF3D extends GEF. We
will then create a small 2D editor with GEF – and subsequently
3D-fy that editor.

Some basic knowledge of GEF is required for understanding GEF3D.
Hence we firstly highlight some design features of GEF and secondly
describe how these features can be used for 3D-fication. Figure 2
serves as a guidance, illustrating the main classes and patterns
used in GEF and GEF3D. Don’t worry, the figure looks a little bit
overwhelmed at the first glance, but things will get clearer soon.
We are going to describes the elements shown in the figure from
inside out.

In the center of GEF we can identify the model-view-control
(MVC) pattern, hence it is shown in the center of Figure 2 as well
(light blue background). The implementation of the MVC is very fine
grained, that is for each editable item, an MVC triple is required.
E.g., you will need an MVC triple for the diagram, for each node
and even for each label which should be editable. The model
containing the data can be implemented by simple Java classes, you
do not need to implement any interfaces or extend special classes.
However, the model is often implemented using the Eclipse Modeling
Framework (EMF [8]), and if GMF is used, EMF is even required. The
view part is implemented by a separate plugin which comes with GEF,
called Draw2D. Elements are visualized by so called
Figures. Figures are structured as trees, and its
root is contained within a class called LightweightSystem.
The LightweightSystem is a kind of adapter between the
figures and the SWT. It paints figures onto an SWT canvas and
delegates events from SWT to GEF. As mentioned earlier, a
controller has to be provided for each editable element.
Controllers are implemented by so called EditParts, which
do not only handle the event, but create the figures as well. In
contrast to other MVC implementations, the controller is the most
important part of the MVC triple in GEF, acting as a mediator
between the figure and the model. In particular, the figure does
not listen to the model, it even does not have any dependency to
the model elements at all. Just like the figures, the
EditParts are organized as a tree as well.

We now focus on the next level, the elements painted on the blue
background in Figure 2. These elements are still part of GEF, we
start at the right with the EditPolicy and wander around
the circle counter clockwise. EditParts (playing the role of
controllers) have to fulfill many tasks: from managing the
selection of items, to creating elements, to more application
specific tasks. To avoid monster classes (with spaghetti code), the
policy pattern (also known as strategy pattern) is used to extract
functionality into separate classes, called policy classes. A
policy is “installed” and called to manage a certain task if
needed. Besides reducing the size of the EditPart, its behavior can
be changed dynamically. This can be done by simply installing new
policies, or by replacing existing policies during runtime. We will
do the latter in order to add 3D functionality to already created
EditParts. Apropos creation: As you can see in the figure,
EditParts are created using the factory pattern, the
factory is called EditPartFactory here. The EditPartViewer
is a container bringing all parts together: it holds a reference to
the factory, it contains the already explained LightweightSystem,
and it also contains the root of the edit part tree (not visualized
in the figure). The viewer itself is part of the GraphicalEditor,
which serves as the interface to the Eclipse platform, it is
registered as editor via Eclipse plugin mechanism.

To summarize, the MVC implements a separation of concerns,
especially the visualization is separated from the content. The
behavior (of the controller) can be dynamically modified by using
policies, the controllers themselves are created using a factory.
As we will see later, these design patterns are used later in order
to 3D-fy existing editors.

GEF3D Overview

Last but not the least, we have a look at the outer circle
(red), showing classes provided by GEF3D. This time we start at the
bottom of Figure 2 and move clockwise. Most essentially, we have to
add a new dimension to the two-dimensional view. This means we have
to replace the view element of the MVC triple. Since the controller
should be able to use the new three-dimensional view, we simply
extend the original Figure, our 3D enabled subclass is called
Figure3D. Instead of painting onto an SWT-Canvas, we have to use a
3D canvas now, called GLCanvas as we use OpenGL for rendering. As a
matter of fact GEF3D does not depend on any particular 3D render
library. Instead, a generic interface has to be implemented to
adapt a concrete render library. Currently, an adapter for LWJGL
[10] exists, and an adapter for JOGL [11] is planned. Accordingly a
3D version of the lightweight system, LightweightSystem3D, and a
corresponding GraphicalViewer3D are provided. The viewer is created
and configured by the editor, a basic version of a 3D editor is
provided as well, although in most cases existing 2D editor classes
are subclassed, as we will see later on.

Basically these are the most important classes of GEF3D and it
would be possible to construct a 3D editor with these classes. Most
3D specific problems are handled by GEF3D in the background,
programming a 3D editor is quite similar to programming a 2D
editor. E.g., GEF3D handles the selection of elements in a 3D scene
(called “picking”) or provides a camera for navigation. Coordinates
are converts from 2D to 3D or vice versa transparently for the
client code. This is especially useful when existing 2D code is to
be reused, as we will see later.

Tweaking with Patterns

Lot of effort was spent in order to make use of most of the
concepts and techniques of GEF for 3D editors. As a result,
existing 2D editors can be 3D-fied with very little changes, most
parts of an editor can be reused unchanged. Especially for adapting
existing editors, GEF3D provides new patterns and makes use of
existing patterns. The policy pattern plays a key role in all these
approaches, because it enables the modification of behavior during
runtime, without the need to alter the actual code. The idea is
pretty simple: Existing policies for two-dimensional applications
are to be replaced by appropriate 3D versions. Fortunately, only a
few policies have to be exchanged, since most of the functionality
is independent from the graphical representation.

In general, existing 2D code should not be altered during
3D-fication. Instead, the complete 3D related code required to
enable the usage of an original 2D editor in a 3D scene is to be
placed into an independent plugin, which depends on the original 2D
plugin. The original classes are reused as much as possible, and,
since the code is not changed, their behavior is altered during
runtime. The central pattern used to alter the behavior of existing
EditParts is called Borg Factory – if this reminds you of Start
Trek, you’re not completely wrong. The classes involved in the Borg
Factory pattern is shown in the right-upper area of Figure 2. First
of all, a so called BorgFactory replaces an original
EditPartFactory, the original factory is nested into the
BorgFactory – this is very similar to the proxy pattern. So called
Assimilators can be registered at the BorgFactory, in order to
perform certain modifications. When a new element is to be created,
the sequence is as follows: First, the nested original factory
creates the EditPart, based on a given model element. After the
EditPart has been created, it is passed to the registered
Assimilators. They can now modify the created EditPart, e.g.,
policies can be added or removed. If it is too hard to modify the
EditPart, it is even possible to replace it completely –
“resistance is futile”.

The other patterns shown in Figure 2, the Multi Factory pattern
and the Connected Element pattern, are needed when a modified
editor is combined with other editors. Both patterns will be
explained in a follow up article.

Graph Editor Example

We will now have a look at a concrete example, in order to
illustrate how GEF3D and the new patterns are to be used. In the
following, we are going to implement a very simple editor for
graphs with nodes (called vertices) and connections (edges). First,
we will implement an 2D editor with GEF, and then 3D-fy that
editor. The final result is shown in Figure 3. The screenshot shows
how two nodes are moved, you can see that GEF3D displayes 3D
handles and a 3D feedback figure.

Whether or not we create a 2D or 3D editor, we initially have to
create a model. Most simply this is done with EMF. The EMF model
used for our example editor is shown in Figure 4, the model has
been created with the ecore diagram editor [6].

From that model a Java implementation can be automatically
generated by EMF. Since we want to use a wizard later for creating
a model, the edit and editor code are to be generated as well.

Now we have to implement the 2D editor, which is created as a
plugin. Broadly speaking, we have to implement an editor class, the
edit part factory, and the view and controller classes for our
model elements. Elements are modified by GEF using the command
pattern. That is, elements are not directly changed by the edit
part of policy classes, instead the policies create appropriate
commands which then execute the modifications. Accordingly we have
to create some commands for creating or modifying elements (we omit
commands for deleting elements here), and implement corresponding
policies which create these commands. The following table lists all
the classes we need for the example editor. More information about
GEF can be found at the GEF website [3], about EMF at EMFs website
[8], the sources of the example editor are part of the GEF3D
examples (the GEF3D graph example contains a non-EMF model for
simplicity, the 3D-fied graph editor can be found in


Class(es) / Files Description


Editor class plugged into Eclipse, the editor with its classes
(e.g., EditPartFactory and palette) are configured here
and the model is loaded


Factory for creating EditParts according to given model

GraphEditPart, VertexEditPart,

Controllers of displayed elements. The controllers serve their
model elements and refresh the view accordingly. Besides, they are
responsible for mapping the model to the displayed figure

GraphFigure, VertexFigure, EdgeFigure

Figures displaying the model elements.

VertexCreateCommand, VertexResizeCommand,

Commands for creating or changing (model) elements. These
commands are created themselves by the policies listed below.

GraphLayoutPolicy, VertexEditPolicy

Policies for creating the commands above. The vertex commands
are created by the GraphLayoutPolicy, and the edge
command by the VertexEditPolicy. The policies are
installed at the edit parts.


The editor must be registered at the Eclipse platform, the
extension point used for that is

Table 1: A 2D graph editor with only 14 files.


In order to use the previously created 2D editor in a 3D scene,
only a few modifications are necessary: no more then three classes
are needed. In GEF3D, 2D content is projected onto planes in the 3D
scene. Thereby it is possible to reuse almost all parts of the 2D
editor without any modifications. Only the figure displaying the
diagram, in the example the GraphFigure, has to be replaced, since
we want to use a plane instead of a 2D area. The GraphEditPart has
to be changed as well, because we have to create the 3D graph
figure now instead of the 2D one. We call the 3D classes
GraphFigure3D and GraphEditPart3D respectively.
GraphEditPart3D is subclassed from GraphEditPart, the modification
is minimal: Instead of creating a 2D figure, GraphFigure3D is
created. Table 2 lists all three classes (and the plugin file)
required to 3D-fy the editor.

Classes / Files Description


The 3D editor subclasses the 2D editor. The edit part factory is
modified, and a new camera tool is created in order to enable the
user to navigate in the 3D scene.


The diagram edit part for the 3D plane is subclasses from the
original 2D version (here GraphEditPart), the only
modification is to create a 3D figure instead of a 2D one.


Instead of a 2D figure, a 3D plane (i.e., a cuboid) is to be
created. The elements of the diagram are projected onto that


The 3D editor has to be registered at the Eclipse platform as
well, again the extension point org.eclipse.ui.editors is

Table 2: The 3D-fication requires only 4 files!

The figure displaying the diagram itself, that is
GraphFigure3D, has to be created from scratch, the
original 2D figure cannot be reused. However, GEF3D provides some
base figures which makes it very simple, in most cases no 3D
programming knowledge is required. In order to give an impression
of how 3D elements are to be implemented with GEF3D, the whole code
of GraphFigure3D is listed below.:

public class GraphFigure3D extends ShapeFigure3D {
  private ISurface m_surface = new FigureSurface(this);
  public GraphFigure3D() {
          SurfaceLayout.setDelegate(this, new FreeformLayout());
               getPosition3D().setSize3D(new Vector3fImpl(400,300,20));
         setAlpha((byte) 0x44);
 public ISurface getSurface() {
            return m_surface;

 protected Shape createShape() {
           return new CuboidFigureShape(this);


Due to the usage of helper elements, so called Shapes,
the implementation of a 3D figure looks quite similar to the one of
2D figures. As shapes are often used to actually render a figure,
GEF3D provides a special figure class ShapeFigure3D, which
uses a shape internally. As seen in the example, a subclass of
ShapeFigure3D must only implement the abstract method
createShape(). GEF3D comes with a bunch of shapes, such as
cuboid, sphere, or cylinder.

In order to be able to project the 2D content onto the figure of
the graph (GraphFigure), the 3D figure needs a surface (see method
getSurface()). The actual rendering is now hidden in the
base class. In contrast to GEF, figures are not simply rendered by
(recursively) calling a render-method. Instead, in a first step so
called RenderFragments are collected. In a second step,
these fragments are rendered, producing the actual output. This is
done due to restrictions of OpenGL when rendering transparent
objects. As a matter of fact, OpenGL does not support transparent
objects directly, thus GEF3D has to take care that these objects
are rendered correctly. This is achieved by using depth-ordered
RenderFragments – in most cases, this is not visible at
the client code level as shown in the example.

The most work left to the client is to initialize the 3D editor
correctly. If no 2D editor class has to be reused, one can simply
rely on 3D editor classes provided by GEF3D, such as
GraphicalEditor3D. However, in many cases, an existing 2D
editor already exists, containing code for loading or saving the
model and other application specific things. For that reason, the
2D editor has to be used as a base class, and the code for setting
up the 3D editor has to be implemented in the client code. Hence we
reuse the 2D editor here as well, that is we derive
GraphEditor3D from GraphEditor2D. Now all 3D
specific initialization code has to be implemented her, roughly
spoken the following things have to be done:

  1. Instead of a GraphicalViewer, a
    GraphicalViewer3D has to be created.
  2. In order to navigate in the 3D scene, a camera has to be
    installed. This is done by adding a special tool
  3. Instead of the 2D diagram element, the previously created 3D
    graph figure (and its editor part) has to be created. Moreover, all
    EditParts are to be adapted to be editable in the 3D view.
    E.g., instead of two-dimensional handles and feedback figure, 3D
    versions of these items are to be used as shown in Figure 4.

In the following we will address all these issues. That is,
first of all we have to create a 3D viewer. For that, we have to
override createGraphicalViewer() as follows:

protected void createGraphicalViewer(Composite i_parent) {
  GraphicalViewer3DImpl viewer = new GraphicalViewer3DImpl();
       Control control = viewer.createControl3D(i_parent);


The camera is simply installed as a tool. In order to reuse the
original tools (which can still be used in the 3D version), the
original palette initialization is called in the first line:

protected PaletteRoot getPaletteRoot() {
   PaletteRoot root = super.getPaletteRoot();

  PaletteDrawer drawer = new PaletteDrawer("GEF3D");
        drawer.setDescription("GEF3D tools");
     drawer.add(new ToolEntry("Camera", "Camera Tool", null, null,
             CameraTool.class) {});
    root.add(0, drawer);
      return root;


These two first steps are pretty simple. Modifying the edit
parts is more tricky, and we will need Borg technology to solve
that problem. In other words, we have to use the borg factory
pattern here:

protected BorgEditPartFactory createBorgFactory(
           EditPartFactory originalFactory) {
        BorgEditPartFactory borgFactory = new BorgEditPartFactory(originalFactory);
  // replace diagram edit part
      borgFactory.addAssimilator(new EditPartReplacer(GraphEditPart.class,

    // modify diagram edit part's policies 
   borgFactory.addAssimilator(new AbstractPolicyModifier() {

           public boolean match(EditPart part) {
                     return part instanceof GraphEditPart3D;

           public void modifyPolicies(EditPart io_editpart) {
                        // feedback when creating a node:
                              new ShowLayoutFeedbackEditPolicy3D());
                    // handles and feedback when moving or resizing a node
                              new Handles3DEditPolicy());

 // modify node edit part's policies
       borgFactory.addAssimilator(new IAssimilator.InstanceOf(
           NodeEditPart.class) {

               public EditPart assimilate(EditPart io_editpart) {
                        // feedback when drawing a connection
                              new ShowSourceFeedback3DEditPolicy());
                    return io_editpart;

       return borgFactory;

The code is almost self-explanatory. First, the original edit
part factory is nested inside the BorgEditPartFactory. Then
appropriate assimilators are registered at the borg factory. The
first assimilator is the EditPartReplacer, which replaces the 2D
edit part by a 3D edit part. In the example, edit parts of type
GraphEditPart are to be replaced by their 3D counterparts,
GraphEditPart3D. The second assimilator, an
AbstractPolicyModifier, does not change the edit part
itself, but it adds two new policies to the 2D edit part:
ShowLayoutFeedbackEditPolicy3D creates a 3D feedback
figure when a node is to be created, and
Handles3DEditPolicy takes care of adding 3D handles when
nodes are to be resized or moved. The third assimilator also adds a
new policy: ShowSourceFeedback3DEditPolicy creates a 3D
feedback figure when a new connection is to be created.

Last but not least, the BorgEditPartFactory must be set
as factory, and a RootEditPart3D is to be installed which
is required in the 3D editor:

protected void configureGraphicalViewer() {
 EditPartFactory originalFactory = 
        BorgEditPartFactory borgFactory = createBorgFactory(originalFactory);

       ScalableFreeformRootEditPart root =     new ScalableFreeformRootEditPart3D();

That’s it! These are the changes required to 3D-fy an existing
editor. We have to register the new 3D editor using the well-known
extension point org.eclipse.ui.editors, then we are able
to open, view and edit the very same diagrams in 3D as we can edit
with the 2D editor.


As demonstrated with the small example, creating 3D editors with
GEF3D is surprisingly simple. At the moment, no official release of
GEF3D is available, more about that and current restrictions can be
found in the box “Incubator”. By 3D-fying exiting 2D editors, it is
a good way for taking first steps into the world of 3D programming.
Although, GEF3D supports full 3D editors, especially when
predefined elements (such as diagram elements) and connections
between them are to be edited. If you need to create your own CAD
system, GEF3D is not recommended. However, the design and future
development of GEF3D is focused on 3D-fying existing 2D editors
since it is an interesting technique for visualizing models (and
model chains) in the area of model driven approaches.

In the planned second article, we will explain more features of
GEF3D, e.g., how to combine multiple editors in a single 3D scene,
and how to 3D-fy GMF-based editors.


At the moment, GEF3D is in the Eclipse incubator. There is no
official release of GEF3D available yet (on how to install GEF3D at
the moment, see box “Installation”). Known problems are documented
in bugzilla. Currently, the most important restriction is the
absence of 3D handlers for moving a 3D figure in 3D space (e.g.,
for rotating a 3D figure). Rotation and positioning of figures in
3D space is fully supported, it is simply not possible to do that
interactively at the moment.

Besides, the incubator does not only mean that the software is
not stable yet, but also that the project and the team has to
become more mature. At the moment, there are only two committers,
and help is highly appreciated! GEF3D provides a website with a
wiki, questions are answered at the newsgroup or developer mailing
list [2].

Installation of GEF3D

The official release of GEF3D is not yet available. In order to
use GEF3D, Eclipse (and GEF) 3.5 are required. GEF3D has to be
imported into the workspace from its subversion repository (

The following projects are to be imported:

  • org.eclipse.draw3d
  • org.eclipse.draw3d.geometry
  • org.eclipse.draw3d.graphics3d
  • org.eclipse.draw3d.lwjgl
  • org.eclipse.draw3d.ui
  • org.eclipse.gef3d
  • org.eclipse.gef3d.ext

All examples are found under
org.eclipse.gef3d.examples.*, for 3D-fying GMF based
editors, some helper classes are provided in

Besides the GEF3D (and Draw3D) code, a rendering library is
required in order to actually draw the 3D scene. For creating 3D
output on the screen, OpenGL is used. Since OpenGL only provides a
C API, a Java wrapper library such as LWJGL [10] is required. At
the LWJGL update site (, an Eclipse plugin can be
downloaded, which was created in the context of GEF3D.

An up-to-date installation instruction can be found in the
GEF3D-wiki (

Links & Literature

[1] Voormann, H.: Quo vadis Eclipse? Eclipse Magazin 4 (2008),
April, S. 20–27

[2] Eclipse GEF3D:

[3] Jacobson, I.: Object-Oriented Software Engineering: A Use
Case Driven Approach. Addison-Wesley Professional, 1992 (acm

[4] Eclipse GEF:

[5] Eclipse GMF:

[6] Eclipse Modeling Framework Technology (EMFT):

[7] Eclipse Model Development Tools (MDT):

[8] Eclipse EMF:

[9] Bokowski, B. ; Gerhardt, F.: GEF: Maßgeschneiderte grafische
Editoren selbst erstellen. In: Eclipse Magazin 2 (2005), Februar,
S. 85–90

[10] Lighweight Java Game Library (LWJGL):

[11] Java Bindings for OpenGL API (JOGL):

Jens von Pilgrim
Jens von Pilgrim is a research assistant at the Software Engineering Group at FernUniversit
comments powered by Disqus