First Steps Towards a Multi Editor 3D

Some days ago I 3d-fied the UML 2 Tools Diagram Editors. Well, a single 2D editor in 3D is funny but not really thrilling. You may ask: "Why should I use a 2D editor in 3D?" And I agree with you. The idea behind GEF3D is to enable multi model or multi diagram editing (this is why I started the GEF3D project). I strongly believe that "raising the level of abstraction" as promoted by all these model-driven approaches requires good tools. What does "good" mean in that context? Many models are edited graphically^*, and using different levels of abstraction means using different models, that is diagrams. Also, using different (architectural) view points means using different models or diagrams. And all these models are somehow related! But these relationships usually aren't visualized. Too often, the best thing you get is a (EMF generated) tree editor. The GMF mapping editor is a typical example. IMHO a good tool would be a tool enabling graphical notations throughout the development process. And this is what GEF3D is all about. By 3d-fying existing GEF or GMF based editors, it is possible to reuse existing code and, from the user's perspective, existing and well-known graphical notations. This is also a principle of GEF3D: Enable exiting editors to be reused in 3D. Nobody wants to write new 3D-enabled editors when there are 2D editors already available, and no user wants to learn a new 3D-like notion of the UML. The next step is to open several 2D diagrams in a single 3D scene. Actually this is working for quite some time, an example application is published in [1]. This application was more a design study or proof of concept, I 3d-fied an elder version of the TOPCASED UML editor (which is GEF based). With the 3d-fied UML2 Tools editors, I was optimistic to create a UML Tools multi editor as well. Frankly, I was very much surprised how easy that was! The example code is part of the UML2 tools example found in the GEF3D SVN. I created a video demonstrating the multi editor. Have fun! (Sorry for the bad quality, it's my first video I uploaded to YouTube) Watch the video at YouTube A multi editor certainly is only the foundation for real-world (MDD) applications. Opening multiple editors in a single 3D scene enables the visualization of inter-model (or inter-diagram) relations such as transformation traces [1], inter-package dependencies, model-differences, manual mappings and so on. While the demo sounds promising, there are a lot of problems and known bugs I don't want to keep secret. There are some problems with feedback figures, text editing is not working as expected, there are problems with rotated planes (yes, actually the planes can be positioned every where in the 3D scene), currently it isn't possible to simply move an element from one diagram to another and so on. The example is only the first step, and we are working for solving the known issues.

[1]

J. v. Pilgrim and B. Vanhooff and I. Schulz-Gerlach and Y. Berbers: Constructing and Visualizing Transformation Chains. In: ECMDA-FA 2008, Berlin, Germany, June 9-13, Proceedings, LNCS 5095, pp 17--32, Springer-Verlag, 2008. URL: http://dx.doi.org/10.1007/978-3-540-69100-6_2

---

*For non-graphical models, XText is a wonderful tool. Combining text and graphical models certainly is a challenge for future research ;-)

You will be 3d-fied. Resistance is futile.

I admit it: I like Startrek. This is why I called a special pattern used to adopt editors for using them in a 3D scene with GEF3D "Borg-Factory-Pattern" (a borg factory modifies an object after it has been created by a "normal" factory using assimilators). Kristian Duske recently "3d-fied" the Ecore Diagram Editor---but he did not use the borg factory. So, why didn't we need the borg technology to assimilate this editor to be used in a 3D scene? The Ecore Diagram Editor is based on GMF. Frankly, I have lots of respect for GMF. I know GEF pretty well, but GMF with its thousands of new extension points, policies and stuff... it's like... like.. yeah, it's like a Borg cube. The good thing about that is that borg technology is already on board. We beamed Kristian on board of that cube, and he returned with a some nice providers enabling us to add 3D-behaviour to existing GMF editors. GEF3D needed some more examples anyway, so we 3d-fied the Ecore editor, and some of the UML editors of the UML Tools (which are also GMF-based), viz. the class, activity, and use case editors. The best thing: We only had to write a bunch of classes. For example, the 3D UML class editor plugin consists of 8 classes with only 212 statements (measured by c_count). The 3D versions of these editors are available from GEF3D's SVN repository (plugins org.eclipse.gefd.examples.uml and org.eclipse.gefd.examples.ecore). To give you an impression about what you need to 3d-fy an existing 3D GMF-based editor, here is a brief description on how we adopted the UML class editor (a tutorial about GEF3D is planned for June, since then don't hesitate to post your questions in the GEF3D newsgroup!):

1. First, a new plugin is created, with a UMLDiagram3DPlugin activator, which is not really needed.
2. A new editor class UMLDiagramEditor3D subclasses the original UMLDiagramEditor. Instead of a 2D viewer we have to instantiate a 3D viewer, actually, this need the most code since we have to copy and paste some code from the base classes.
3. Only one editpart and figure have to be exchanged, that is the pair for the diagram, here the package. We have to provide new 3D versions for these two classes (PackageEditPart3D, DiagramFigure3D).
4. The new edit part has to be created by a new factory UMLEditPartFactory3D, which subclasses the original UMLEditPartFactory
5. This factory has to be injected into the editor somehow. This is done using a GMF provider UMLEditPartProvider3D. Since we only need this provider for our 3D editor, we have added a very dirty hack to identify which editor calls the provider. This is hack is really dirty (better not look at the provider ;-) ), and I hope to find a better solution.
6. Finally we have to exchange the policy which creates the 2D feedback handles and replace it with a 3D version. Again, this is done by a provider called UMLEditPolicyProvider3D, the 3D policy is called Handles3DEditPolicy

That's it. And what do you get for that? The result is an UML editor with the diagram projected on a plane in a 3D scene. You can use the camera to orbit and move around. Since it's derived from the original 2D UML editor, it is (more ore less) fully editable. Try to select classes and move them around, create new classes and so on. You can even open the very same UML model in the 3D editor and 2D editor simultaneously, changes are reflected in both editors automatically!

The 3D version of the UML Tool's activity diagram editor (on the right hand side, 2D version on the left). Note the 3D handles and the transparent feedback figure!

Unfortunately there are some open issues which restrict the 3D editor: no edges can be drawn (sometimes, you can draw edges but don't see any feedback, sometimes the Eclipse IDE crashes when you try to do that). You cannot open more then one 3D editor at a time, we have a problem with the texture manager. And there are some other bugs... So many bugs? Yes, but only a very few lines of code to 3d-fy an editor. So, 3D-fy your editor and help us fixing the bugs! You may ask, huh, that's great, but why should I want to 3d-fy my editor? Well, I can think of many use cases: display multiple diagrams within one 3D scene and draw inter-diagram connections, annotate your diagrams with 3D elements (e.g. metrics drawn as 3D bars on top of classes), exchange some of your 2D figures and provide real 3D editors...

Waiting for "Accelerated 3D on the Web"

Yesterday, the Khronos group published a press release entitled "Khronos Launches Initiative to Create Open Royalty Free Standard for Accelerated 3D on the Web". That sounds like a candidate for enabling GEF3D editors within Eclipse RAP applications :-D The project sounds a little bit like Canvas 3D. With the X3D exporter, we learned that it is possible to use renderes other than OpenGL/LWJGL. But I'm not an Ajax expert, so I'm not sure how interactive 3D could be possible in that context. But it's nice to have visions ;-)

GEF3D goes X3D

Due to problems of getting LWJGL IP approved, we were wondering how to address this problem. We didn't want to fall into the same trap again, so we thought about how to reduce GEF3D's dependencies from a specific rendering library. The problem was not trivial at all, so I decided to give it to a student, Matthias Thiele. He should analyze GEF3D and its dependencies to the currently used rendering library LWJGL in the context of a bachelor thesis. The idea was to refactor GEF3D (i.e. Draw3D) in order to minimize dependencies and to create a generic renderer interface. Making renderers plugable leads to the idea of using renderers not only for drawing on the screen, but for exporting or printing, too. So besides the refactoring, a new renderer should be implemented... GEF provides several export formats, for example SVG for exchanging diagrams in a vector based file format. What SVG is for 2D diagrams, X3D is for 3D ones. So, besides the existing LWJGL-based renderer, Matthias implemented an X3D renderer. And Matthias did a great job! Based on his analysis of the GEF3D and Draw3D code, using cool tools like InferType (see intoJ project), we (that is Kristian, Matthias and myself) created a new design for Draw3D's rendering parts and we introduced an extension point to make renderers plugable! Matthias did most of the refactoring, actually before GEF3D was submitted to Eclipse. On the way we had to fix some bugs related to this (e.g. a 3D position problem or a dispose problem), but eventually it seems to work fine. Matthias wrote the X3D renderer, and he has contributed the code today. It is not available in the SVN yet, since we have to get it IP approved, first. Here you can see the result of the X3D export: The original GEF3D diagram is shown at the bottom left. The large diagram is the very same image, exported as X3D and viewed with the instantplayer. The small image on the top left shows the very same X3D file, this time rendered with the Octaga Player. The current version of the X3D exporter is only a beginning. We certainly have to improve the quality of the diagrams, but it shows what is possible. Maybe other programmers write other cool renderers for GEF3D in the future ;-)

Unbelievable: Cooler than GEF3D ;-)

With GEF3D you can produce nice 3D diagrams. Of course, GEF3D is not the only framework which can produce 3D diagrams. An australien colleague, Paul McIntosh, uses X3D (the VRML successor) to create nice 3D UML diagrams, quite similar to the diagrams created with GEF3D. If you have thought, GEF3D's 3D diagrams are cool, well, then have a look at Paul's latest project. He combines his diagram with augmented reality: Watch the video at YouTube Just to get it right: This is not GEF3D, but Paul's X3D-UML! This is amazing, isn't it. Jin, Paul -- great work! (Uh... don't you want to port this to GEF3D? ;-) ) If you want to see more of Paul's work, visit his website: http://www.x3d-uml.org/

GEF3D committed into SVN

After getting the preliminary approval I've just committed the initial GEF3D contribution into the SVN (GEF3D is participating in the parallel IP process). You can now check out GEF3D from svn://dev.eclipse.org/svnroot/technology/org.eclipse.gef3d In order to test GEF3D, you'll need the following projects (please add org.eclipse to the name): draw3d, draw3d.geometry, gef3d, gef3d.ext, gef3d.gmf, and gef3d.examples.graph Optionally you can check out the test and documentation projects, however there are currently not much tests and documentation available (but you can use the ant script in doc in order to generate the JavaDoc). Draw3D, the 3D version of Draw2D, needs a renderer module in order to produce any output. Currently, only LWJGL is supported (or.eclipse.draw3d.lwjgl). The module only contains the Draw3D specific code, additionally you will need the LWJGL libraries. These are available via the LWJGL update site at http://lwjgl.org/update. An description can be found at http://www.fernuni-hagen.de/se/personen/pilgrim/gef3d/lwjgl.html. The GEF3D example is running, but there is a known bug. We are working on that already... Actually there are more bugs known, we will add them to Bugzilla as soon as possible ;-) After checking out all these projects, the example editor can be activated by simply creating a file with appropriate extension: ".graphSample" for the 3D editor, ".graphSampleDia" for a 2.5D editor (i.e. 2D figures projected on 3D planes), and ".multiGraphSample" for a multi plane editor. Update: The current installation instruction can be found at http://wiki.eclipse.org/GEF3D.

LWJGL Plugin at lwjgl.org

As you may now, GEF3D is moving to Eclipse. GEF3D uses OpenGL for rendering GEF diagrams in 3D, and since OpenGL is a C library, a Java wrapper library has to be used. LWJGL is such a library and GEF3D uses LWJGL. It works with SWT out of the box, that is there is no need for using the SWT-AWT-bridge, which isn't working on Mac OS X (maybe this will change with the new Cocoa version of SWT?). The latest version supports OpenGL 3.0 and runs on Mac, Windows, Linux and Solaris. Unfortunately, the LWJGL library didn't got IP approved. So it cannot be added to the Eclipse orbit project. The good news is, that lwjgl.org now provides an LWJGL Eclipse plugin! Brian Matzon has installed the update site today. Thank you so much, Brian! It is the plugin I wrote for GEF3D, and it is now available at http://lwjgl.org/update/. This plugin is interesting for people developing Eclipse plugins (or using GEF3D), since it simply wraps the LWJGL library (including the native code) into an Eclipse plugin. Not only the libraries are made available, but source code and documentation as well. Another plugin will be made available shortly at the same update site, providing LWJGL support for standalone Java applications developed with Eclipse. This plugin will define a new library "LWJGL Library", that is it resolves the jars, native libs, sources and JavaDoc using the LWJGL plugins above. Since the native libs will be defined as well, a standalone Java application can easily be started using Eclipse's "Run As - Java Application" without the need to set a library path. So, this plugin saves some mouse clicks and configuration problems. With these plugins, it is very easy for Eclipse developers to use OpenGL, either by an Eclipse plugin or by a standalone Java application developed with Eclipse.