Wednesday, April 8, 2009

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. 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...


vano said...

Looks like we can think of integrating 3D diagramming into GMF. As a simple use 3D diagram visualization can be supported (just as you mentioned in this posting), but I think this is not enough.

I suppose some additional elements should be added to the notation model to describe 3-rd dimension on diagrams… Do you have any ideas about it?

Jens v.P. said...

Hi Vano (Alex?),

well, adding elements to the notation model would certainly be great, since it would allow real 3D editors. What is missing is simple to list:
- z and depth
- rotation (around x, y, and z axis)
We have created a class called Position3D (in the gef3d.geometry plugin) which takes all the 3D related information.

I'd like to integrate 3D diagramming to GMF, that would be great! But I'd like to have GEF3D a little bit more stable before; I've listed some problems in the posting. I assume requirements will slightly change by fixing these problems.
We also think about (optionally) replacing the redering of 2D figures onto textures by drawing 2D figures natively with OpenGL (or the renderer available)---Kristian has already written a special Graphics implementation doing that job. This would allow us to separate 2D figures from their planes, and then 3D information in the notation model would much more 3D without any changes in the original 2D-oriented code. But we need some time for that, unfortunately our resources are quite limited.

Adapting the UML Tools was my first step towards GMF. I only had adapted an old version of the Topcased UML editor, which only used some parts of the GMF runtime library. So I hope that Kristian and I gain more experience with GEF3D and GMF in the following weeks.

BTW: Kristian is currently working on using GEF3D for creating the GMF mapping model (we can visualize the relations between the mapping model and the domain model since we can display both models together in a 3D scene), that is replacing the EMF-style tree editor with a GEF3D one.



vano said...

Ok. Let's wait till the moment then GEF 3D will be more stable.

Concerning activity with mapping editor - it's very interesting to see your results. Please, post corresponding annonce into GMF newsgroup once it will be available.