tag:blogger.com,1999:blog-67524201755168848612024-03-14T01:49:16.544-07:00GEF3D Development BlogLiterally just another Eclipse Committer and Project Blogs weblog.Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-6752420175516884861.post-49858130260363475752011-05-23T09:14:00.000-07:002011-05-23T09:14:49.195-07:00Tracking Shots with GEF3DOne of the most important things for 3D user interfaces are good navigation tools. So far, GEF3D comes with a nice first person like camera tool. You can fly around in the 3D scene and orbit around figures. If you have watched previous GEF3D videos, you may have noticed how we fiddled to nicely position figures in front of the camera. This is more or less ok for editing smaller diagrams, but in the long run it's annoying. In order to improve navigation, we needed a basic technique for tracking shots (see <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=300319">bug 30019</a> ). I have now added a basic API for tracking shots, together with some predefined shots for moving the camera in front of figures, as demonstrated in the following <a href="http://youtu.be/vHqenn4Ya1g">video</a>.<br />
<br />
<iframe width="560" height="349" src="http://www.youtube.com/embed/vHqenn4Ya1g" frameborder="0" allowfullscreen></iframe><br />
<br />
These tracking shots are now (as of GEF3D revision 578) available, and the default camera tool provides the following (old and new) navigation features:<br />
<ul><li>move camera around with keys (up, down, etc.), mouse (grab scene and drag it around) or mouse wheel or touch pad with two fingers (zoom in / out)</li>
<li>orbit around figures by holding down a modifier key and clicking on a figure to be the center of the orbit</li>
<li><b>new</b>: double click on a figure to start a tracking shot, ending in front of the figure. The double clicked figure will then be shown in the center of the 3D scene, much as if opened in a 2D editor.</li>
<li><b>new</b>: double click on background, to start a tracking shot to a predefined position. The default camera tool defines three positions, in order to look at the 3D scene from the front, from the side (hold modifier), or from the top (hold shift and modifier).</li>
</ul><br />
Actually, the idea of tracking shots in GEF3D is not that new. It had been prototypically implemented in a master thesis 2008 (see <a href="http://www.fernuni-hagen.de/se/abschlussarbeiten/abgeschlossen.html#Bauer08a">A. Bauer: Visualisierung von Suchtreffern und Clustern in 3D-Diagrammeditoren.</a>) -- however the new moves are much nicer ;-) I'm looking forward to re-implementing the basic feature of this thesis again using the new tracking shot API: We combined EMF search with GEF3D, in order to automatically move the camera to search hits visualized in the 3D scene. And there are much more applications for tracking shots, such as following connections, visualizing timelines, switch between "sub-scenarios" in the 3D scene, etc. Stay tuned!<br />
<br />
<i>Jens</i>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com2tag:blogger.com,1999:blog-6752420175516884861.post-88455646809150585562011-05-13T12:30:00.000-07:002011-05-13T12:30:43.600-07:00Interactively rotate and move figures in 3D space<p>Although GEF3D provides full 3D capabilities for placing and <a href="http://gef3d.blogspot.com/2009/08/pick-me-rotate-me.html">rotating</a> figures, it was not possible to <b>interactively</b> place figures everywhere in 3D space. GEF3D adapts moving and resizing of figures as provided by GEF, by enabling moving and resizing of figures on so called virtual planes (which are unbounded surfaces). Since surfaces are always 2D planes, this is similar to moving figures in a 2D editor (in which the surface is always the screen surface). As of revision 576 (we are still working on a nightly build system, until then you have to get GEF3D from the code repository), it is possible to interactively move figures in 3D space. In the movie below, you will see how some planes are interactively moved and placed in 3D space. The editor is part of the GEF3D examples. It consists of simple (2D GEF) editors for graphs, that is labeled nodes connected with edges. Several graphs, each one drawn on its own diagram surface, are combined into a GEF3D multi editor. You will find this example called "Multiple Graphs in Dia2D Mode Sample" in the example package (org.eclipse.gef3d.examples.graph).<br><iframe width="560" height="349" src="http://www.youtube.com/embed/l3T-3LD3GnQ" frameborder="0" allowfullscreen></iframe><br>This closes bug <a href="http://bugs.eclipse.org/300321">300321</a> and it also demonstrates a lot of nice features of GEF3D which are not that obvious. In the following, I will highlight some interesting aspects, using some snapshots taken from the movie.<br><br><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFSAjMObx1XlFH7qG1mFZuufMvXqDPqjSfYceAgyWo0d2aq5pNCrappzL_iP_e99jSUt22QML_ZO1ISEgMvAKCYPNHuLqwjaA22Ap04uvG897qXZ4H9Zg1tDzloWPPyI9_PhuvARoVWTyI/s1600/GEF3D-virtualPlane.png" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFSAjMObx1XlFH7qG1mFZuufMvXqDPqjSfYceAgyWo0d2aq5pNCrappzL_iP_e99jSUt22QML_ZO1ISEgMvAKCYPNHuLqwjaA22Ap04uvG897qXZ4H9Zg1tDzloWPPyI9_PhuvARoVWTyI/s200/GEF3D-virtualPlane.png" width="200"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Fig. 1: Virtual Plane</td></tr></tbody></table>Figure 1 shows how 2D figures can be moved around just like moving figures with GEF. GEF3D provides a concept called "virtual planes", that is, a figure is moved parallel to a (virtually extended) surface of a 3D figure, which usually is the surface of the diagram. This always worked for 2D figures. (For people not that much involved in GEF3D: a 2D figure actually is an original GEF or Draw2D figure! It's code is not modified at all!)<br><br><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghauAStydYv5AKbxytKRMjsJYEjOZDubguD8TlamvWj1ssvJbXD4QlIA2JEIq-MPCOrzl9PCHngkBAH84jCICbAvFhTynUbuXY05ixpI9RHXBuzXKL4TNQRIx05TwhGut5pLluBUSw3eVw/s1600/GEF3D-2Dis3D.png" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghauAStydYv5AKbxytKRMjsJYEjOZDubguD8TlamvWj1ssvJbXD4QlIA2JEIq-MPCOrzl9PCHngkBAH84jCICbAvFhTynUbuXY05ixpI9RHXBuzXKL4TNQRIx05TwhGut5pLluBUSw3eVw/s200/GEF3D-2Dis3D.png" width="200"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Fig. 2: 2D breaks free!</td></tr></tbody></table>As shown in Figure 2, 2D figures are not necessarily bound to the actual surface of a 3D figure. Instead, 2D figures are rendered as real 3D content, which does improve quality and performance (Kristian is a real 3D wizard <a href="http://gef3d.blogspot.com/2010/02/improving-visual-rendering-quality.html">making this possible</a>), but also <a href="http://gef3d.blogspot.com/2010/01/25d-breaks-free-and-future-plans.html">removes restrictions</a> on how 2D content is drawn in 3D.<br><br><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1jezeKq8m2c6dXn5iAmXFI0AcAyBlU2vPHHrklKhUEbN6eQaQBtAazzvPPAxagCaR-Q6lGNxSgZ4Ho6veAKoborVL3CA8BZqVY5HjVYtW9aLSQwX2Q5-ztTksx-4qUmHjXMg3X5jQxGh5/s1600/GEF3D-virtualPlane3D.png" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1jezeKq8m2c6dXn5iAmXFI0AcAyBlU2vPHHrklKhUEbN6eQaQBtAazzvPPAxagCaR-Q6lGNxSgZ4Ho6veAKoborVL3CA8BZqVY5HjVYtW9aLSQwX2Q5-ztTksx-4qUmHjXMg3X5jQxGh5/s200/GEF3D-virtualPlane3D.png" width="200"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Fig. 3: Move 3D figure on virtual plane</td></tr></tbody></table>Now, 3D figures can be moved like that as well. A 3D figure, which is not placed onto a figure with a surface, such as the digram figure itself, can then simply be moved parallel to its own surface. This is illustrated in Figure 3.<br><br><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghrSoZ7SEYPhbyKpCC6IhVNFe8pmCIF-LWLaKAV4m-xHyIsCbQEBi5W_DeoqmIfO1Rp0PmOYOisy-4dwoigdk2U0N65y7AhyphenhyphenmTnBHvoh_0vbRsQ9kVGhAd0GerXWS2qgeHqhM06CM08k_v/s1600/GEF3D-rotate.png" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghrSoZ7SEYPhbyKpCC6IhVNFe8pmCIF-LWLaKAV4m-xHyIsCbQEBi5W_DeoqmIfO1Rp0PmOYOisy-4dwoigdk2U0N65y7AhyphenhyphenmTnBHvoh_0vbRsQ9kVGhAd0GerXWS2qgeHqhM06CM08k_v/s200/GEF3D-rotate.png" width="200"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Fig. 4: Interactively rotate 3D figure</td></tr></tbody></table>One of the most interesting features of GEF3D is the full support of rotation. In the current version, 3D figures can be interactively rotated by holding down a modifier key (command key for on OS X, alt key for Windows and Linux). Instead of moving the figure, it is then rotated around its own x- and y axis. Figure 4 shows the feedback figure, which exactly shows the rotation. <br><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxGbt_H1k2d5js08tTILToRNlqA9gckaRyEvfx31ujK0v4aPYwbpXX-dxiKueF_F8C2MyaM_GtXcNR58O7kYj3e-mLoMFDZyhcma4qAfZ4BuCCnfG4C-PD5JnWsSAjpyA1KDcAK6zdFyAJ/s1600/GEF3D-connectionAnchorsWithRotatedPlanes.png" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="151" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxGbt_H1k2d5js08tTILToRNlqA9gckaRyEvfx31ujK0v4aPYwbpXX-dxiKueF_F8C2MyaM_GtXcNR58O7kYj3e-mLoMFDZyhcma4qAfZ4BuCCnfG4C-PD5JnWsSAjpyA1KDcAK6zdFyAJ/s200/GEF3D-connectionAnchorsWithRotatedPlanes.png" width="200"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Fig. 5: Connection anchors are placed correctly</td></tr></tbody></table>One of the trickiest things with rotations is the correct handling of connection and connection anchors. Figure 5 shows that the connection between an element of the one diagram is still correctly connected with an element of another diagram, although the first diagram is rotated. This works with all arbitrarily rotated figures. Since 2D content is rendered using OpenGL as well, we also have no problems with image quality or whatever. So, if you need fully supported rotation capabilities for a 2D editor (in which the figures are to be rotated around the z-axis), GEF3D may be interesting for you as well (all you need to do is to restrict the camera in order to emulate a 2D editor).<br><br><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiy0Z2SsRNE20NbhngkqRALuVkPTsxzFs3Ww0DeG1XNk-KB8r03osMq3w2h-et-IxfuMT6-3dhJ_O0RrqGKiFBHgiGUNYIdyiPs8wPvlD9lAxDVPgA2PDBIzubGq0WvgJLT1MfknhFYKJwb/s1600/GEF3D-moveZAxis.png" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiy0Z2SsRNE20NbhngkqRALuVkPTsxzFs3Ww0DeG1XNk-KB8r03osMq3w2h-et-IxfuMT6-3dhJ_O0RrqGKiFBHgiGUNYIdyiPs8wPvlD9lAxDVPgA2PDBIzubGq0WvgJLT1MfknhFYKJwb/s200/GEF3D-moveZAxis.png" width="200"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Fig. 6: Move along normal vector</td></tr></tbody></table>Holding down the modifier and shift will cause the figure to be moved orthogonally to the virtual plane, that is along its own z-axis (or normal vector). This is shown in Figure 6.<br><br><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGyCcJY0mgfD6lP1oX6KdG5BeMuEDmIHHehoBRKiFYiE1hXs35ycpt4arRzenx3SZhz5HGygfmYhLSJCvcfQ2d5OMprY6SrQYG4Sn3YAvnqXYSpElHzmyBu-fkpC4KqD_n0Qo3HQ-mnpAm/s1600/GEF3D-resize3D.png" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGyCcJY0mgfD6lP1oX6KdG5BeMuEDmIHHehoBRKiFYiE1hXs35ycpt4arRzenx3SZhz5HGygfmYhLSJCvcfQ2d5OMprY6SrQYG4Sn3YAvnqXYSpElHzmyBu-fkpC4KqD_n0Qo3HQ-mnpAm/s200/GEF3D-resize3D.png" width="200"></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Fig. 7: Resize 3D figure</td></tr></tbody></table>This enables one to arbitrarily place 3D figures in the 3D space. It is also possible to resize 3D figures, however at the moment I only have implemented the resizing itself. Thus, only resizing along the x- and y-axis are supported (as shown in Figure 7), because only handles for x- and y-resizing are provided yet.<br><br>While modifier keys may work in some cases, it is only a temporary hack. In the long run, we have planned to <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=300320">add 3D handles</a>. We are thinking about adding handles for x-, y-, and z-axis rotation, z-axis movement, and resizing the depth of a figure. This will also remove conflicts with applications using the modifier keys for different kind of actions.<br><br><i>Jens</i></p>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-61239526010994784292011-02-27T07:19:00.000-08:002011-02-27T07:20:42.268-08:00Welcome Miles!I'm happy to welcome <a href="http://milesparker.blogspot.com/">Miles Parker</a> as a new GEF3D committer. <a href="http://en.wikipedia.org/wiki/M_(James_Bond)">M</a>iles is the master of agents, that is he is project lead for the <a href="http://eclipse.org/amp/">Eclipse AMP, the Agent Modeling Platform</a>. In this context, he is using GEF3D for quite some time to create impressive <a href="http://eclipse.org/amp/images/AMPNewScreenshot.png">3D visualizations</a> of agent models. He also has some experiences with fighting continuous integration build systems---and <a href="http://milesparker.blogspot.com/2009/09/victory-at-athena.html">winning these fights</a>. He will help the GEF3D team to set up a build system with <a href="http://eclipse.org/buckminster/">Buckminster</a> and <a href="http://wiki.eclipse.org/Hudson">Hudson</a>. So we will be able to create nightly builds and, in the long run, a first release of GEF3D.Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-72822751612118147742010-09-13T04:04:00.000-07:002011-01-25T07:33:01.605-08:00Do you want 3D in Eclipse?Unfortunately, we were informed that the <a href="http://jogamp.org/">JOGL</a> library has failed to get IP approved just like <a href="www.lwjgl.org">LWJGL</a> due to severe licensing problems (see <a href="https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2817">CQ2817</a> and <a href="https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2840">GQ2840</a> for further details; IPZilla account needed). To summarize, LWJGL cannot be approved as it contains non BSD code or code with unknown license or provenance and JOGL cannot be approved as “we have been unable to locate an individual within Sun/Oracle to help us with JOGL”, as Janet Campbell wrote when closing the CQ. In this context we'd like to thank Janet and Barb for all their hard work!<br/><br/>What this means for Eclipse is that, even though it is technically possible to use 3D / OpenGL within Eclipse, there is no way to create self-contained Eclipse plugins that require OpenGL. Such plugins would always have to rely on external update sites, which complicates the installation process. Such update sites also depend on third party support and <a href="http://lwjgl.org/forum/index.php?topic=2785.15">may or may not be</a> available in future releases. For <a href="http://www.eclipse.org/gef3d">GEF3D</a>, this is really bad news, but it also is a problem for all other 3D related projects.<br/><br/>The only option appears to be to create a new Eclipse project for OpenGL bindings. Some <a href="http://www.eclipse.org/swt/opengl/">work</a> has been done in the SWT project itself, but the code has since been abandoned. Unfortunately, writing OpenGL bindings for Java is not a simple job due to inconsistencies and driver incompatibilities. Jens wrote GEF3D in the context of his Ph.D. thesis, and we both were paid by the <a href="www.fernuni-hagen.de">FernUniversität in Hagen</a>. Additionally, we spent a lot of our spare time on GEF3D. We both are still interested in GEF3D, but unfortunately our current work is not really 3D related. That is, we both are no longer paid for maintaining GEF3D. This would be OK to a certain degree, but frankly none of us is keen on writing a new OpenGL wrapper library on our own without any salary.<br/><br/>So, we'd like to know whether we are alone in our effort to bring 3D to Eclipse: Do <strong>you</strong> want 3D (i.e. OpenGL) in Eclipse? And if you do, what are your thoughts on this situation? As this is not a simple yes/no question, <strong>please leave us a comment</strong>.<br/><br/><em>Jens and Kristian</em><br/><br/><strong>Technical Note</strong>: OpenGL is required for almost all 3D applications, and high-level libraries such as the <a href="http://jmonkeyengine.org/">JMonkeyEngine</a> or <a href="http://aviatrix3d.j3d.org">Aviatrix3D</a> use OpenGL (i.e. LWJGL or JOGL) under the hood. Technically, OpenGL can be easily used in SWT applications thanks to the GLCanvas class. However, a Java wrapper library is needed for calling OpenGL functions. As far as we know, only two such libraries are available: <a href="www.lwjgl.org">LWJGL</a> and <a href="http://jogamp.org/">JOGL</a>. At <a href="http://www.eclipse.org/swt/opengl/">http://www.eclipse.org/swt/opengl/</a>, <a href="http://gljava.sourceforge.net/">gljava</a> is listed as well, however, this project is no longer maintained. The same is true for the org.eclipse.opengl bindings. There exists a <a href="http://marketplace.eclipse.org/content/jogl-plugin-eclipse">plugin for JOGL</a>, and another for LWJGL. The <a href="http://marketplace.eclipse.org/content/lwjgl-plugin">plugin for LWJGL</a> has been written in the context of <a href="http://www.eclipse.org/gef3d">GEF3D</a> and has been maintained by the LWJGL team for quite a while (they have changed their build system, so the LWJGL plugin is <a href="http://lwjgl.org/forum/index.php?topic=2785.15">no longer maintained</a> at the moment, however the update site is still available).Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com11tag:blogger.com,1999:blog-6752420175516884861.post-42743601790949646272010-05-05T04:43:00.000-07:002011-01-25T07:33:01.634-08:00Multi editor 3D and property sheet pagesBesides enabling 3D editors, IMHO one of the most interesting features of GEF3D is to combine existing editors. I already <a href="http://jevopisdeveloperblog.blogspot.com/2009/04/first-steps-towards-multi-editor-3d.html">blogged</a> about that feature one year ago, and since then GEF3D has been improved very much.<br />
<br />
The rendering quality is now as good as in 2D, so it really makes sense to think about supporting 3D when creating new editors. However, the nice thing about GEF3D is, that you do not have to write new editors from scratch, instead, you can reuse existing editors. And, these reused editors can not only adapted in order to support 3D -- we call this "3D-fied" -- but they can also be adapted in order to be combined. For that, all you have to do is to let them implement a small interface <code>INestableEditor</code>. It is very simple, the GEF3D examples include 3D-fied and nestable versions of the UML2 Tools editors and the Ecore Tools editors.<br />
<br />
When combining editors, a lot of new problems arise. One of these problems is how to create new edit parts. Every nested editor comes with its own factory -- but which one to use in case of newly created elements? This problem is solved in GEF3D for quite some time now (by the multi factory pattern). I only recently became aware of another "combination" problem: the property sheet page. Every editor provides its own page, created almost hidden via <code>getAdapter()</code>. Now -- what page do you want to use in case of a multi editor? The answer is simple: The right page, depending on the selected element. And this is what I've added to GEF3D: Depending on the currently selected element, the page provided by the nested editor responsible for that element should be used. The latest (SVN) revision of GEF3D provides a new page, called <code>MultiEditorPropertySheetPage</code>, which nests all the pages provided by the nested editors. Depending on the currently selected element, the appropriate page is shown, as you can see in the screenshots. As many things in GEF3D, this feature is almost transparent to the programmer.<br />
<table border="0"><tbody>
<tr> <td><br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwv9imsx02SZEoa81dHmLTa-tBdPbSXS15S3tAYnN_gFghCSUVaZG2Q44fdU1_JvMmSPS3_5M5Mv4B7rt2lZj7PWqtu0As2C3DpRuGyHnNuPXKiUIJ-YpGcfAZoj-nSNd6JXNDtVJOpeuf/s1600/multieditor3dproperties-1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwv9imsx02SZEoa81dHmLTa-tBdPbSXS15S3tAYnN_gFghCSUVaZG2Q44fdU1_JvMmSPS3_5M5Mv4B7rt2lZj7PWqtu0As2C3DpRuGyHnNuPXKiUIJ-YpGcfAZoj-nSNd6JXNDtVJOpeuf/s320/multieditor3dproperties-1.png" width="294" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; font-size: small;">use case selected, property page provided by nested UML editor</span></td></tr>
</tbody></table><br />
<br />
</td> <td><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ8gSBe0dmRAoAbu480BAJZremHTBr5_gYavbOdTRMvarvLJTTkHLwl5TILT7MzGb3mQ1_Cgk-W4wyv3i71B-SlFYsdhpU7IgusrQ6g-LfaSoex2l1MYNwbWBT6qTVIN6JGWLQ90kE6VrK/s1600/multieditor3dproperties-2.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ8gSBe0dmRAoAbu480BAJZremHTBr5_gYavbOdTRMvarvLJTTkHLwl5TILT7MzGb3mQ1_Cgk-W4wyv3i71B-SlFYsdhpU7IgusrQ6g-LfaSoex2l1MYNwbWBT6qTVIN6JGWLQ90kE6VrK/s320/multieditor3dproperties-2.png" width="294" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; font-size: small;">ecore class selected, property page provided by nested Ecore editor</span></td></tr>
</tbody></table><br />
<br />
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px;"><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;"><br />
</span></span></td></tr>
</tbody></table>The screenshots show an UML use case diagram (visualized with 3D-fied UML tools) and an ecore diagram (visualized with 3D-fied Ecore tools). The 3D-fied editors and the multi editor combining them are examples of GEF3D (that is, you will find everything in the SVN).<br />
<br />
In many cases models are visualized as diagrams, and with GEF3D and its multi editor feature you will be able to easily display all your diagrams in a single 3D scene -- with things you aren't able to visualize in 2D editors, such as inter-model connections (traces, markers, mappings, or other kind of weaving models). Some products use the term "modeling IDE" -- think about the "I" in IDE and what GEF3D does with your models ;-)<br />
<br />
BTW: The very same concept used for implementing property sheet pages may be implemented for the Outlook View as well -- volunteers wanted :-D<br />
<br />
<em>Jens</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-16587148980181443082010-02-02T22:34:00.000-08:002011-01-25T07:33:01.640-08:00Improving Visual Rendering Quality<a href="http://dev.eclipse.org/blogs/gef3d/files/2010/01/5_vertices_intersect.png"></a>As Jens mentioned in his recent <a href="http://dev.eclipse.org/blogs/gef3d/2010/01/22/25d-breaks-free-and-future-plans/" title="2.5d Breaks Free and Future Plans">blog post</a>, parts of the Draw3D renderer have been rewritten in the past weeks. The initial motivation was to improve the visual rendering quality of 2D content (embedded GEF editors) and text, but during development it turned out that a lot of optimization would be necessary to keep the performance at acceptable levels. Eventually, I rewrote the renderer to take advantage of some advanced OpenGL features and now the performance is a lot better than it ever was.<br />
<br />
In this blog post I will briefly explain how the 2D rendering system was redesigned over the course of GEF3D's existence and how it was possible to achieve both a gain in the visual quality and the rendering performance at the same time.<br />
<br />
First, let me introduce the initial 2D rendering system that Jens designed before I came on board. GEF uses an instance of the abstract class <a href="http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.draw2d.doc.isv/reference/api/org/eclipse/draw2d/Graphics.html" target="_blank" title="org.eclipse.draw2d.Graphics">Graphics</a> to draw all figures. Actually, figures draw themselves using their paint method whose only parameter is an instance of Graphics (this is defined in the <a href="http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.draw2d.doc.isv/reference/api/org/eclipse/draw2d/IFigure.html" title="org.eclipse.draw2d.IFigure">IFigure</a> interface). The Graphics class provides a lot of methods to draw graphical primitives like lines, rectangles, polygons and so forth, as well as methods to manage the state of a graphics object. Usually, GEF passes an instance of <a href="http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.draw2d.doc.isv/reference/api/org/eclipse/draw2d/SWTGraphics.html" title="org.eclipse.draw2d.SWTGraphics">SWTGraphics</a> to the root of the figure subtree that needs redrawing. SWTGraphics uses a <a href="http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/graphics/GC.html" title="org.eclipse.swt.graphics.GC">graphics context</a> to draw graphical primitives, and the graphics context usually draws directly onto some graphics resource like an image or a canvas.<br />
<br />
So what Jens did when he wanted to allow 2D content in GEF3D was that he simply passed an instance of SWTGraphics to the 2D figures that rendered into an image in memory. This image was then transferred to the graphics card and used as a texture. This system was very simple and required hardly any additional coding at all. The problem with this approach however is that whenever the 2D content needed redrawing (after some model change for example), the entire image had to be redrawn and uploaded to the graphics card again, which is a very costly process. First, the image has to be converted into a <a href="http://java.sun.com/javase/6/docs/api/java/nio/ByteBuffer.html" target="_blank" title="java.nio.ByteBuffer">ByteBuffer</a> and that buffer must then be uploaded from system to video memory through the bus. For normal-sized image, this can take up to 500ms.<br />
<br />
To alleviate this problem, I wrote another Graphics subclass that uses OpenGL to render the 2D primitives directly into a texture image in video memory. This eliminates the uploading step and thus improved performance considerably, especially the delay after any model change when the texture image had to be uploaded into video memory. But it did not help with the second major problem: It still used textures. The problem with using textures to display 2D content in 3D is that while the texture image may look sharp and very good by itself, it gets blurry and distorted when it is projected into 3D space due to all the filtering that has to take place. Especially images that contain text become very hard to read in this approach, as you can see in this screenshot:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQknJltR0nm79p5uWs6eflHTwi9hwJfiX0yjWNBDoJtmoo_VzDpYqHziT6YqiUag1HcdOJdcNx3W8_gB0BXAbv0UG7lhiEfvrOjtREpyBCS2vo6c12mUDN1NlfeF48yOWYnQQthRZ8nyGa/s1600/topcased3d02.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="270" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQknJltR0nm79p5uWs6eflHTwi9hwJfiX0yjWNBDoJtmoo_VzDpYqHziT6YqiUag1HcdOJdcNx3W8_gB0BXAbv0UG7lhiEfvrOjtREpyBCS2vo6c12mUDN1NlfeF48yOWYnQQthRZ8nyGa/s320/topcased3d02.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">TopCased editor, 3D version with 2D texture</td></tr>
</tbody></table>Another approach to rendering 2D content in 3D is not to use textures at all, but to render all 2D primitives directly into 3D space in every frame (so far, only the texture had to be redrawn only after a model change occurred). This eliminates all problems related to texture filtering and blurring once and for all. Combined with vector fonts (to be described in another blog post), direct rendering results in the best possible visual quality. The problem is that everything needs to be rendered in every frame all the time. I quickly discovered that simply sending all geometry data to OpenGL in every frame (this is also called OpenGL immediate mode) would kill performance - even in small diagrams, navigation became sluggish.<br />
<br />
Essentially, the FPS in GEF3D are limited not by the triangle throughput of the video card (how many triangles can be rendered per second?), but by the bus speed (how much data can we send to the video card in a second?). If you send all your geometry, color and texture data to the video card on every frame, your performance will be very bad because sending large amounts of data to the video card is very expensive. The more data you can store permanently in video memory, the better your performance will be (until you get limited by triangle throughput). So we had to find a way to store as much data as possible in video memory and just execute simple drawing instructions on every frame.<br />
<br />
Of course, OpenGL provides several ways to do this. The first and oldest approach is to use display lists, which is basically a way to tell OpenGL to compile a number of instructions and data into a function that resides in video memory. It's like a stored procedure that we can call every time we need some stuff rendered. The problem with display lists is that they are fine for small stuff like rendering a cube or something. 2D diagrams however consist of large amounts of arbitrary geometry, which cannot be compiled into display lists at all. So this approach was not useful for us.<br />
<br />
The best way to store geometry data in video memory is called a vertex buffer object (VBO) in OpenGL. Essentially, a VBO is one (or more) buffer that contains vertices (and other data like colors and texture coordinates). These buffers only need to be uploaded into video memory once (or when some geometry changes) and can then be drawn by issuing as little as five commands in every frame. We decided to adopt this approach and try it for our 2D diagrams by storing the 2D primitives in vertex buffers in video memory. Rendering a 2D diagram would then be very fast and simple, because hardly any data must be sent to the video card per frame. This is how the pros do it, so it should work for us too!<br />
<br />
In theory, that is correct. But in practice, it is very hard to actually create a vertex buffer out of the 2D content of a 2D diagram. Since a vertex buffer can only contain a series of graphical primitives (triangles, quadrilaterals, lines) of the same type and the primitives that make up the 2D diagram are drawn in random order, the primitives need to be sorted properly so that we can create large vertex buffers from them. Unfortunately, the primitives cannot simply be sorted by their type and then converted into vertex buffers because there are dependencies between such primitives that intersect. To cut a long story short, I had to think of a way to sort primitives into disjunct sets. Each set contains only primitives of the same type and each set should be maximal so that you end up with a small number of large buffers because that's how you achieve maximum performance.<br />
<br />
The end result is impressive: We used to have performance problems with diagrams that contain more than 2000 2D nodes, and now we can display 4000 2D nodes at 120 FPS, and all that with much better visual quality. To get an idea of how much better the quality of the 2D diagrams is in this version, check out the following screenshot:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTM4JGnHXwh857hMNjL0YFifuY9T5T1TemfdgLMIC4h9lR3DBN95EdWhBKBphWn4aEovFlYenqVjCCJb1WkT-pe-3RqcnGnSdKZPGGH6p3v22XwsdlLH0uxF9cr0BDlakK_lXQ-x2otyrx/s1600/bildschirmfoto-2010-01-24-um-1828.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="174" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTM4JGnHXwh857hMNjL0YFifuY9T5T1TemfdgLMIC4h9lR3DBN95EdWhBKBphWn4aEovFlYenqVjCCJb1WkT-pe-3RqcnGnSdKZPGGH6p3v22XwsdlLH0uxF9cr0BDlakK_lXQ-x2otyrx/s320/bildschirmfoto-2010-01-24-um-1828.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Ecore editor 3D with high quality 2D content</td></tr>
</tbody></table><em>Kristian</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-20263969461461012372010-01-22T05:27:00.000-08:002011-01-25T07:33:01.644-08:002.5D breaks free.. and future plansI assume Kristian will tell you more in a future post, but I simply couldn't wait to show you this picture:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJn5ZbBcj1kG_XgoOSo5Kqi5C8aBXML4CfuebtSC2gVyApQU2cXOS2UIMO0q0907lzlV4Ne0209GVZI44RH4BcE1jgedLSfLZIUhQKDIqsYwDg86nxm4M-CgfGeq03pZeAmp7HnQ8XiZxr/s1600/gef3d-ecore-rev436.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJn5ZbBcj1kG_XgoOSo5Kqi5C8aBXML4CfuebtSC2gVyApQU2cXOS2UIMO0q0907lzlV4Ne0209GVZI44RH4BcE1jgedLSfLZIUhQKDIqsYwDg86nxm4M-CgfGeq03pZeAmp7HnQ8XiZxr/s400/gef3d-ecore-rev436.png" width="378" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">GEF3D ecore editor (rev. 436)</span></td></tr>
</tbody></table><br />
It shows a screenshot of the 3D-fied version of the ecore tools editor, which is part of the GEF3D examples. Compare this image (GEF3D rev. 436) with the following one, taken using an elder version (rev. 413 ) of GEF3D showing the very same diagram:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmjuZW0h2rPuNDcIXhkhLwNrE828zScKa0judilwReiwfTKl3PriHtaLQtfSS03Ol9_7rHMD-imMcQBU7qgRgY2yuCE-Paw-OcovqeXJ7p7K3EQtlu-LUSZDWh062BBNJM7As56CCKtbJA/s1600/gef3d-ecore-rev413.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="292" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmjuZW0h2rPuNDcIXhkhLwNrE828zScKa0judilwReiwfTKl3PriHtaLQtfSS03Ol9_7rHMD-imMcQBU7qgRgY2yuCE-Paw-OcovqeXJ7p7K3EQtlu-LUSZDWh062BBNJM7As56CCKtbJA/s400/gef3d-ecore-rev413.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">GEF3D ecore editor, rev. 413</span></td></tr>
</tbody></table><br />
Do you see the difference? Yeah! 2D figures are no longer bound to their diagram plane! In other words: <strong>2.5D breaks free!</strong> (If you don't know the term 2.5D, read our <a href="http://jaxenter.com/GEF-goes-3D.html">tutorial article about GEF3D available at Jaxenter.com</a>!) Besides, the display quality of 2D content has improved since it is now rendered as vector graphics and no longer as a smudgy texture projected onto a plane. Usually, increased display quality leads to decreased speed, but not in this case! Actually, GEF3D is no longer a limiting factor when displaying large diagrams -- it's GEF (or GMF). The texture based version of GEF3D had a problem with diagrams containing about 5.000 (2D) nodes. The new version runs smoothly even with this much nodes! However, you may get a memory problem when opening such large diagrams (due to GEF/GMF), but if you can open it, the camera can be moved smoothly! Great work, Kristian! He has become a real 3D programming pro, and I'm absolutely impressed about how he improved GEF3D in the last weeks. Stay tuned to his post about this new technique!<br />
<br />
At the moment, Kristian is working on also replacing the texture based font rendering with vector fonts, which will dramatically improve the overall quality of the rendered images. Besides, the GEF3D team has set up a todo list, summarizing bugs with new features (to be implemented in the near, not so near and far future):<br />
<div style="text-align: center;"><a href="http://wiki.eclipse.org/GEF3D_Todos">http://wiki.eclipse.org/GEF3D_Todos</a></div><br />
<br />
The most important tasks are to add support for full 3D editing, e.g. moving and resizing figures in z-direction and rotation, implement advanced animation support and, depending on that, camera tracks. If you have ideas, please post an article on the <a href="http://www.eclipse.org/newsportal/thread.php?group=eclipse.gef3d">GEF3D newsgroup</a>!<br />
<br />
I certainly have some bias, but with vector based 2D content (and fonts) and camera tracks (e.g., for positioning a diagram in a kind of 2D view), the quality and comfort of editing a 2.5D diagram will become the same as editing it with pure GEF in 2D. But with GEF3D, you can work with multiple diagrams much more comfortable: If you have to edit multiple diagrams with inter-model connections, you will be able to simply navigate to another diagram (and back again). And you can actually see the inter-model connections (for an example read Kristian's post about his <a href="http://dev.eclipse.org/blogs/gef3d/2010/01/20/a-graphical-editor-for-the-gmf-mapping-model/">3D GMF mapping editor</a>). 2D is dead, long live 3D!<br />
<br />
Well, ok, I have probably watched too much Avatar 3D ;-). But maybe you like the idea of cool 3D diagrams, too? Then join the GEF3D team, grab yourself a bug and see how much fun 3D programming with GEF3D could be! Yes, I know... there is no release of GEF3D available yet... I will do that as soon as possible, and I hope with the help of Miles Parker we will be able to set up a build system shortly. So long, use the <a href="http://eclipse.org/gef3d/resources/GEF3D.psf">project team set</a> and check out GEF3D from the SVN repository, an <a href="http://wiki.eclipse.org/GEF3D_Installation">installation tutorial</a> can be found in the Wiki.<br />
<br />
Last but not least, I'm happy to announce the third and (so far) last part of our GEF3D article series in the german <a href="http://it-republik.de/jaxenter/eclipse-magazin">Eclipse Magazin</a>, 2.10. In this part, Kristian and I explain how to 3D-fy existing GMF editors.<br />
<br />
<em>Jens</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com2tag:blogger.com,1999:blog-6752420175516884861.post-23289217424303503362010-01-19T20:50:00.000-08:002011-01-25T07:33:01.657-08:00A Graphical Editor for the GMF Mapping ModelEveryone who has ever worked with GMF knows that it can be painful due to the steep learning curve and the tools it provides for editing the GMF models. The complexity of the models in combination with the very basic tooling makes learning and using GMF harder than it should be. Recently, efforts have been made to improve this situation. There is for example <a href="http://www.eclipse.org/gmt/epsilon/doc/eugenia/" target="_blank" title="EuGenia">EuGenia</a>, which was presented at the ESE 2009. EuGenia uses annotations to add information to the domain model so that the GMF GraphModel and MapModel can be generated automatically. For my diploma thesis however, I followed a different approach to improve the GMF tooling. Jens gave me the task to create a 3D graphical editor for the GMF mapping model. I would like to present the result of my efforts in this blog entry.<br />
<br />
The basic concept for such an editor can be summed up by the following bullet points:<br />
<ul><li>The editor should display the domain model, the GraphModel, the ToolModel and the MapModel together in a 3D view.</li>
<li>The models should be visualized graphically, thus a graphical notation must be developed for each of them.</li>
<li>References from the MapModel to the other models should be visualized using 3D connections.</li>
<li>It should be possible to edit the MapModel entirely by dragging elements from the other models (or rather, their diagrams) to the MapModel. The user should not need to use any other methods to edit the MapModel.</li>
<li>The editor should create as many elements of the MapModel automatically to assist the user.</li>
</ul><br />
<h3>Graphical Notations</h3><br />
Thus, the first step was to develop graphical notations for the domain model, the GraphModel and the MapModel. The ToolModel was excluded to limit the amount of work, and it can be added at a later stage. I began by creating 2D GEF editors that simply display the aforementioned models. Obviously, with the <a href="http://www.eclipse.org/modeling/emft/?project=ecoretools" target="_blank" title="Ecore Tools">Ecore Tools</a> there already is a graphical notation and a very capable editor for EMF based domain models, so no work had to be done there.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqxvvdIxz8qNdUbDBRHCh5pEgi-KT8yfpbUagvj6ICnSDdEegmoz16_otROKZT47xf9d1EmZ1KZ5SZLa_SpjM2xxO5mX8W5q-gBaNV5umlE5pkyboKwMrCTDhadpUskRvM_D1w1PbeSAqL/s1600/ecoretools-2d.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="244" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqxvvdIxz8qNdUbDBRHCh5pEgi-KT8yfpbUagvj6ICnSDdEegmoz16_otROKZT47xf9d1EmZ1KZ5SZLa_SpjM2xxO5mX8W5q-gBaNV5umlE5pkyboKwMrCTDhadpUskRvM_D1w1PbeSAqL/s320/ecoretools-2d.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Ecore Tools Editor</span></td></tr>
</tbody></table><br />
The main focus in creating a graphical notation for the GraphModel was to render the figures in the figure gallery just like they would look like in the generated editor. The diagram elements defined in the model should be grouped by their type (node, connection, diagram label and compartment) and the layout should be automatic, without the need for user interaction. The following screenshot demonstrates this.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5-WozTayGNmzzbXIepuv1Wd02k80rpAwoM5T0ssXyzdWl0gcjLTzUFG7fWYAnx0IQ1AAf-aow-XlUsLXdO-SWajubRP-giAjUpD_bJGF1DIky3X2RhNJmfcVYG0ZBH9urbVJXTU1fFbdI/s1600/graphmodel-viewer-2d.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="244" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5-WozTayGNmzzbXIepuv1Wd02k80rpAwoM5T0ssXyzdWl0gcjLTzUFG7fWYAnx0IQ1AAf-aow-XlUsLXdO-SWajubRP-giAjUpD_bJGF1DIky3X2RhNJmfcVYG0ZBH9urbVJXTU1fFbdI/s320/graphmodel-viewer-2d.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Graphical Notation for the GraphModel</span></td></tr>
</tbody></table><br />
<br />
Developing a graphical notation for the MapModel was a little more complex because it needs to convey more information than the notation for the GraphModel does:<br />
<ul><li>The MapModel mirrors the containment relationships of the domain model (using NodeReferences, NodeMappings and Compartments) which results in a hierarchical structure. This structure should be represented visually by nesting the figures which represent the model elements.</li>
<li>The MapModel needs to display additional information like which domain element is mapped etc.</li>
<li>The mappings should be represented by the figures which they map to in the GraphModel. That is, if a NodeMappping maps to a blue rectangle figure (in the GraphModel), then that NodeMapping should render itself as a blue rectangle also.</li>
</ul><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRiimbDo_Fk1Zbr4J8ZP2lRRLvayJNyoLRbm-wxE7SXxcZxW7ULrNS9T2PsZACuYkUAy7ErMB3jlg85rO6vT0ISIwC4tzd-ymPmf8g8UFOBUoW1zg_k6dtnzpQTLSekEJfXh0miktQBZS2/s1600/gmf_mapmodel_viewer_screenshot.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="206" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRiimbDo_Fk1Zbr4J8ZP2lRRLvayJNyoLRbm-wxE7SXxcZxW7ULrNS9T2PsZACuYkUAy7ErMB3jlg85rO6vT0ISIwC4tzd-ymPmf8g8UFOBUoW1zg_k6dtnzpQTLSekEJfXh0miktQBZS2/s320/gmf_mapmodel_viewer_screenshot.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Graphical Notation for the MapModel</span></td></tr>
</tbody></table><br />
As you can see in the above screenshot, every model element is represented using a figure that has a gray border and title bar. These figures are nested, and those figures that represent a mapping (like NodeMapping) display the referenced figure as their child. Additional information is displayed at the bottom of some of the figures in the form of a list of named properties. CompartmentMappings are nested into the figures to which they belong and contain the child references that link to the contained domain model elements.<br />
<br />
With all the graphical notations in place, the next step was to combine those into a 3D multi editor. In order to do that, the 2D GEF editors had to be 3D-fied first. A 3D version of the Ecore Tools already exists as a GEF3D example, so that was just reused here. The other editors could be easily 3D-fied by adapting four classes each.<br />
<h3>Multi Editor</h3><br />
Combining the three viewers into a multi editor also is a pretty easy task with the tools that GEF3D already contains. There is an abstract base class (<em>AbstractMultiEditor3D</em>) for multi editors that allow any editor implementing the interface <em>INestableEditor</em> to be embedded. There are only very few things that need to be taken care of manually here, like for example making sure that all embedded editors use the same EMF ResourceSet to load their models. Once everything is in place, a multi editor is used by opening one of the models using the newly created editor and dragging the other models onto the editor window - easy! The result of this step is displayed in the following screenshot.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtDk2UYpuTKnRja-aGxW3YDRvPEDlkIKbLu8pRvsoIEZXQHH1k8HXcQX86GTVaKB-1SlvNQoudYg0ylvpo8H9yd0wFsIH50-4OX_lCVU8eSBnwqAtp8TFAiHRyEfDHJX7NWJWgc3FMMmoL/s1600/gmf-3d-editor.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="194" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtDk2UYpuTKnRja-aGxW3YDRvPEDlkIKbLu8pRvsoIEZXQHH1k8HXcQX86GTVaKB-1SlvNQoudYg0ylvpo8H9yd0wFsIH50-4OX_lCVU8eSBnwqAtp8TFAiHRyEfDHJX7NWJWgc3FMMmoL/s320/gmf-3d-editor.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Multi Editor for the Mapping Model</span></td></tr>
</tbody></table><br />
As you can see, this version of the editor already displays references from the MapModel to the other models using 3D connections. This has been implemented by using the <em>UnidirectEditPart3D</em> base class that comes with GEF3D. This class allows creating connections that are created by either the source or target edit part, which is exactly what was needed in this situation, since neither the domain model nor the GraphModel are aware of any references that a MapModel might have to their elements.<br />
<h3>Dropformations</h3><br />
At this point, all that is missing from the editor is the actual editing functionality. It was decided to use a model transformation language to implement the editing functions (which always modify the MapModel in some way). This transformation language is called Mitra was created by Jens von Pilgrim for his Ph.D. thesis. Mitra is an acronym that stands for "Micro Transformations". The language is optimized for fine-grained, semi-automatic model transformations, as the name indicates. Since the Mitra rules that implement the editing functionality are triggered by drag and drop operations, a GEF tool is needed that can do this. Generally speaking, a drag and drop operation can also be interpreted as selecting a number of parameters for a rule. The model elements that are dragged are called source parameters while the model element which the elements are dropped on is a target parameter.<br />
<br />
Consider the following example: Say you want to create a LinkMapping. For this you need a connection from the GraphModel and a domain element that represents the association in the domain model (this could be either an association class or a simple reference). For the sake of simplicity, let the association be modeled by a reference in the domain model. Now to create a LinkMapping, you can drag the connection from the GraphModel and drop it on the MapModel. This creates a new LinkMapping. To set the link feature, you would now drag the association from the domain model and drop it on the LinkMapping, etc.<br />
<br />
There is one remaining problem however: How are the transformation rules selected? Currently, whenever an element is dropped, a popup menu is displayed that contains all rules defined for the editor. This is demonstrated in the following screenshot.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrj65xhiXHK3quiEsVH2aJsvzoZFdOpDKFo0anaOKeDgQHNvEeGS6NYUVXrhyphenhyphenWAqsLRyrbVjEzTfWPaojauUKVHafW6dW3tyxgi9OvWOrejqvU0ikN8S7jmgDGIY2uMWZA_6twIRDurr-S/s1600/gmf_multieditor_dropformation_menu.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="218" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrj65xhiXHK3quiEsVH2aJsvzoZFdOpDKFo0anaOKeDgQHNvEeGS6NYUVXrhyphenhyphenWAqsLRyrbVjEzTfWPaojauUKVHafW6dW3tyxgi9OvWOrejqvU0ikN8S7jmgDGIY2uMWZA_6twIRDurr-S/s320/gmf_multieditor_dropformation_menu.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Rule Selection Menu</span></td></tr>
</tbody></table><br />
Obviously, this is not optimal, and there are plans to implement automatic rule selection by matching the parameter types against the rule signatures, but this is still on the todo list. But even if this is implemented, there will be cases in which there are multiple rules that match the parameter types, and in those cases, the rule name should be replaced by some more meaningful names in the menu.<br />
<h3>Demonstrations</h3><div class="separator" style="clear: both; text-align: center;"></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; text-align: left;">This first video shows how a TopNodeReference (including a NodeMapping, LabelMappings and CompartmentMappings) is created simply by dragging a Node from the GraphModel onto the MapModel. </div><div><br />
</div><br />
<div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/8HCHLlPWXIw?feature=player_embedded' frameborder='0'></iframe></div><br />
<br />
Note that no references to the domain model are set - to see how this is done you can watch the next video:<br />
<div class="separator" style="clear: both; text-align: center;"><object class="BLOGGER-youtube-video" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" data-thumbnail-src="http://2.gvt0.com/vi/IvB8cP7_x34/0.jpg" height="266" width="320"><param name="movie" value="http://www.youtube.com/v/IvB8cP7_x34&fs=1&source=uds" /><param name="bgcolor" value="#FFFFFF" /><embed width="320" height="266" src="http://www.youtube.com/v/IvB8cP7_x34&fs=1&source=uds" type="application/x-shockwave-flash"></embed></object></div><br />
<br />
Finally, the last video demonstrates how to create a ChildNodeReference inside an existing CompartmentMapping and a LinkMapping:<br />
<div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/gQs5aPXVrrY?feature=player_embedded' frameborder='0'></iframe></div><br />
<br />
<i>Kristian</i>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com3tag:blogger.com,1999:blog-6752420175516884861.post-54691804880695898662010-01-15T01:40:00.000-08:002011-01-25T07:33:01.664-08:00GEF3D tutorial article in English language availableI'm happy to announce the <a href="http://jaxenter.com/GEF-goes-3D.html">English version of the GEF3D tutorial article "GEF goes 3D"</a> (source code see <a href="http://it-republik.de/zonen/magazine/ausgaben/psfile/source_file/53/pilgrim4ac0bd6bf1318.zip">here</a>), available online now at <a href="http://jaxenter.com/">JAXenter.com</a>. The German version has been printed in the Eclipse Magazin 6.09 and is <a href="http://it-republik.de/jaxenter/artikel/GEF-goes-3D-2648.html">online available</a>, too. This article is the first part explaining the basic concepts of GEF3D and how to "3d-fy" a very simple GEF-based editor. The second part about creating multi-editors is already available in German language (I will translate it as soon as possible), a third part about how to 3D-fy GMF-based editors will probably be published in the next issue of the Eclipse Magazin. A list of all <a href="http://www.eclipse.org/gef3d/website/docs/index.php">GEF3D related articles and papers</a> can be found at the <a href="http://eclipse.org/gef3d">GEF3D website</a>. Thanks to Hartmut Schlosser for publishing the article online and Madhu Samuel for proof reading the english version.<br />
<br />
BTW: Stay informed about latest GEF3D news by following <a href="http://twitter.com/gef3d">GEF3D at twitter</a><br />
<br />
<em>Jens</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com1tag:blogger.com,1999:blog-6752420175516884861.post-84322352605532141872009-11-25T03:32:00.000-08:002011-01-25T07:33:01.670-08:00GEF3D in print, part 2The GEF3D series in the German <a href="http://www.eclipse-magazin.de/">Eclipse Magazin</a> continues. In the <a href="http://it-republik.de/jaxenter/eclipse-magazin-ausgaben/Eclipse-4.0-000332.html">current issue</a> you will find the second part explaining how to create multi-editors. The editor described in the first part is enhanced in order to display multiple graphs in a single 3D scene, additionally colored markers can be added to demonstrate inter-model-connections.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjr7LsWSCDS6pAfvpsx2BqvmLuuoIqs3LxmeJhvLkf_9Hi8RaUcwz_gBwMD32kM5JtuIrnxaYPp85QzaKdnhHKfBtaf6vZUlFxklmCpKSpcc1VBB_4bmFqpyo4mI7tTT00N-GNC5zT0z221/s1600/em_markers.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjr7LsWSCDS6pAfvpsx2BqvmLuuoIqs3LxmeJhvLkf_9Hi8RaUcwz_gBwMD32kM5JtuIrnxaYPp85QzaKdnhHKfBtaf6vZUlFxklmCpKSpcc1VBB_4bmFqpyo4mI7tTT00N-GNC5zT0z221/s1600/em_markers.png" /></a></div><br />
<br />
If you have missed the first part, don't worry. You can read it online at <a href="http://it-republik.de/jaxenter/artikel/GEF-goes-3D-2648.html">JAXENTER</a>. A third part of this series is planned for the next issue, we will then describe how to 3D-fy GMF-based editors.Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com1tag:blogger.com,1999:blog-6752420175516884861.post-12771956386786517112009-10-22T03:30:00.000-07:002011-01-25T07:33:01.673-08:00See GEF3D in Action at ESE and Around the WorldThe GEF3D team will present GEF3D at Eclipse Summit Europe and at several DemoCamps around the world in the next weeks. If you visit ESE 2009 and if you stay till the very end, you can attend Kristian's and Jens' talk about "<a href="http://www.eclipsecon.org/summiteurope2009/sessions?id=848">GEF3D: Overview and Applications</a>" (Thursday, 4 pm). If you miss that, don't worry! We will present GEF3D at several DemoCamps in November (and December).<br />
<br />
Madhu Samuel will present GEF3D at the <a href="http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Bangalore/">DemoCamp in Bangalore, India</a>. Madhu has done a great job writing an GEF3D-JOGL adapter (currently, GEF3D uses LWJGL, but in the future, JOGL will be the standard OpenGL-wrapper library used by GEF3D), which is not yet publicly available (but we will add his code and JOGL to GEF3D soon).<br />
<br />
On 23th November, Kristian will present the results of his master thesis at the <a href="http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Berlin/">DemoCamp in Berlin, Germany</a>. His application is really cool: It enables the definition of an GMF mapping model using GEF3D, that is you don't have to fiddle with these tree-based editors anymore, instead you can use a 3D graphical editor and simply drag and drop your figures and domain elements into the mapping model. If you have ever wondered why to use GEF3D -- his application is the answer!<br />
<br />
I will present some GEF3D applications at the <a href="http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Hamburg">DemoCamp in Hamburg, Germany</a>, on 4th of December (this <em>November</em> DemoCamp is in fact a December DemoCamp).<br />
<br />
Looking forward to meeting you!<br />
<br />
Huh, Hamburg seems to be an attractive place for people from Berlin. I've noticed Stephan Herrmann's presentation about "Adapting EclipseLink for Object Teams" in Hamburg, too. Object Teams (OT) is a very interesting framework for aspect oriented programming (<a href="http://eclipse.org/proposals/object-teams/index.php">Eclipse project proposal</a>), and sooner or later I will have to try out to 3D-fy editors using OT :-)<br />
<br />
<em>Jens</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-37497687529719020122009-10-01T20:41:00.000-07:002011-01-25T07:33:01.676-08:00GEF3D in print<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg30R28AYpC8cWzFMCGNBIp7LGv8bbQMzIer6mf7DpeSkr8EUerGpubU1Gu8piNaVt9NBu66daj26_OMAoZ7IRWLakOElDYyeA6gOYSJf3OstnHvMozguWDaXKA_hM_1RbDgaQJqLV-zvO0/s1600/gef3dinem.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg30R28AYpC8cWzFMCGNBIp7LGv8bbQMzIer6mf7DpeSkr8EUerGpubU1Gu8piNaVt9NBu66daj26_OMAoZ7IRWLakOElDYyeA6gOYSJf3OstnHvMozguWDaXKA_hM_1RbDgaQJqLV-zvO0/s1600/gef3dinem.png" /></a></div>In the current issue of the German <a href="http://www.eclipse-magazin.de/">Eclipse Magazin</a>, you will find an article introducing the basic concepts of GEF3D with a short tutorial demonstrating the "3d-fication" of an GEF editor. This article is in German, an English version is planned. A second part of this article explaining how to create multi-editors and how to 3D-fy GMF-based editors will probably be published in the next issue.<br />
<br />
<em>Jens</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-49757130395880591592009-08-29T00:48:00.000-07:002011-01-25T07:33:01.680-08:00GEF3D and Mac OS X 10.6I have installed Mac OS 10.6 Snow Leopard on my development machine yesterday and I'm happy to report that Snow Leopard comes with a 32bit Java 6 VM and GEF3D works flawlessly in 10.6 in both the 32bit and 64bit VMs. Generally, I have the feeling that Eclipse is more snappy on 10.6, but that may also be because I have made a fresh install. Performance may degrade a bit due to harddisk fragmentation and other factors.<br />
<br />
<em>Kristian</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-59427137441274186932009-08-17T00:57:00.000-07:002011-01-25T07:33:01.683-08:00Pick Me, Rotate Me!There were two nasty issues in GEF3D. Actually there was no bug report on the first one, as it was no real bug but a conceptional problem we had with picking (that is selecting a 3D object in a scene with the mouse). The other one caused many strange behaviours, documented in several bug reports (<a href="https://bugs.eclipse.org/280977">280977</a>, <a href="https://bugs.eclipse.org/262529">262529</a>,<br />
<a href="https://bugs.eclipse.org/280977">263441</a>, <a href="https://bugs.eclipse.org/278634">278634</a>). I'm proud to say that we (Kristian, who did the main work -- great work, Kristian! --, and I, who helped out when Kristian couldn't see the forest for the trees ;-) ) solved both issues. This is a big step toward a final release, as GEF3D now supports almost everything necessary to 3D-fy existing editors and use them in a 3D environment with extra features such as inter-diagram connections! Unfortunately, both solutions made some API changes necessary, but in the end it makes it even easier to 3D-fy existing 2D editors.<br />
<br />
<br />
<span class="Apple-style-span" style="font-size: 19px; font-weight: bold;">Picking</span><br />
<br />
<br />
The first issue was about picking. We used <a href="http://www.lighthouse3d.com/opengl/picking/index.php3?color1">color picking</a> because I initially thought that this would be much easier and faster. In layman's terms, color picking simply means to render a scene twice: one time as it is shown on the screen, and a second time with a single unique color for each pickable object. Picking an object is as simple as getting the color at the mouse position and looking up the object with that color in a map. The advantage of this technique is that you do not need to implement any geometric calculations and that it is pretty fast and accurate.<br />
<br />
<br />
<br />
Unfortunately it was really hard to use GEF's <code>findFigureAt</code> methods with this technique, because GEF allows to add a filter to that method in order to ignore certain figures. The problem with color picking is that it is impossible to find a figure that is located "behind" an ignored figure, unless the color buffer is rendered again without the ignored figure. We used some cumbersome tricks to work around that problem, but in the end we had to find a new solution.<br />
<br />
<br />
<br />
So we decided to remove color picking and implement geometric picking. That is, we have added methods to all objects shown in a 3D scene which can calculate the intersection with a ray. In order to improve performance, every figure can now calculate its paraxial bounding box. A paraxial bounding box is simply a cuboid whose edges are parallel to the world coordinate system axes and that the figure itself and all its children (see Fig. 1). If a ray hits the paraxial bounding box, the boxes of the children are searched and so on. Finally, we determine whether the shape of a figure intersects with the ray. This way, we can fully support GEF's <code>findFigureAt</code> with filters (in GEF, a <code>TreeSearch</code> is used for filtering). As a side effect, rendering shapes is much easier, since they have to be rendered only once -- no color buffer has to be rendered any more. The trade off is that every shape now has to implement a new interface <code>Pickable</code>, which means it must be able to calculate the intersection of a ray with its shape. But don't worry: We provide a bunch of 3D shapes which implement this interface, and you can use these shapes to compose your own shapes. Also, we plan to provide more shapes in the future, so that in most cases you do not have to deal with these 3D issues at all.<br />
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhI-O-5iyMSncLSX1GR0svgWiGaG02rrrwwpHz2ePfdiq3kD5L79hXG_VzEnEuPLYkBmMNEbM073hsV3-c1sDA1xnuIRU55jgS59QELnmdWxULuTVTE-daUk6ROULgK5UT8dYoWhugVSuse/s1600/paraxialbounds.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="246" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhI-O-5iyMSncLSX1GR0svgWiGaG02rrrwwpHz2ePfdiq3kD5L79hXG_VzEnEuPLYkBmMNEbM073hsV3-c1sDA1xnuIRU55jgS59QELnmdWxULuTVTE-daUk6ROULgK5UT8dYoWhugVSuse/s320/paraxialbounds.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Figure 1: Paraxial bounding boxes, rendered in Draw3D debug mode (use preferences to toggle debug mode)</span></td></tr>
</tbody></table><span class="Apple-style-span" style="font-size: 19px; font-weight: bold;">Coordinate Systems and Rotation</span><br />
<br />
<br />
The second issue was about coordinate systems. The problem with coordinate systems in 3D (and sometimes also in 2D) is that there are several coordinate systems, and frankly, in the end we lost control of where which coordinate system was used within GEF3D. Due to these coordinate problems rotated figures caused a lot of problems. Thus we studied and refactored the code dealing with coordinate systems. Kristian has written a <a href="http://wiki.eclipse.org/GEF3D_Coordinate_Systems">wiki article</a> about that, explaining our solution in detail. In summary, GEF3D works with three coordinate systems: <br />
<br />
<ol><li>a <em>world coordinate</em> system with absolute 3D coordinates</li>
<li><em>mouse coordinates</em>, that are 2D coordinates relative to the canvas</li>
<li><em>surface coordinates</em>, that are 3D coordinates relative to the surface of a 3D figure. You will however notice that GEF3D often uses 2D surface coordinates, which are the projection of the X and Y component onto the plane Z=0.</li>
</ol><br />
2D content is projected on surfaces, and since 2D code is handling the 2D content, GEF3D needs to hide all 3D related issues from figures (and their controllers) on surfaces.<br />
To cut a long story short, we were able to implement surfaces completely like sandboxes for 2D content. This is not an entirely new concept, as it was already possible to 3D-fy 2D content, but surfaces make that even simpler. As a result, all tools of an embedded 2D editor are now working out of the box, that is new elements can be created, moved or resized without the need to change these tools. In earlier versions, we had some problems with rotation, but even that problem is solved now. As you can see in Figure 2, you can simply move a 2D figure from one surface (1, 2) to another, the feedback figure adjust to the current surface (3,4). Of course, in order to actually move the model (of the figure), the editor has to support that kind of operation. As you can also see, the connection between two 2D nodes on different rotated surfaces is correctly located! <br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKcIqxFr2x4wuAftZFN9GnxnCPY-IEFhEiP2D397PJqqctxf0FuRG6CJe9cU6DkEf7raqpbNs7OylLZwgZSo-eKpYx2OCN78a744-i4zANA2ZpLBHlUdBZLRu4ptZFZLMBW-ZGDvdexQN8/s1600/rotatedfeedback.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKcIqxFr2x4wuAftZFN9GnxnCPY-IEFhEiP2D397PJqqctxf0FuRG6CJe9cU6DkEf7raqpbNs7OylLZwgZSo-eKpYx2OCN78a744-i4zANA2ZpLBHlUdBZLRu4ptZFZLMBW-ZGDvdexQN8/s320/rotatedfeedback.png" width="221" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;"><span class="Apple-style-span" style="font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-size: small;">Figure 2: Moving a 2D figure from one surface to another.</span></span></span></span></td></tr>
</tbody></table><span class="Apple-style-span" style="font-size: 19px; font-weight: bold;">Changed Rendering Strategy and Shape Library</span><br />
<br />
Another issue not mentioned above is transparency. The problem is that OpenGL supports translucent colors, but no real transparency. That is, an object may have a translucent color, but the object is handeled by OpenGL just like an opaque object. That is, an object "behind" an transparent object is not painted if the transparent object is rendered <em>before</em> the object behind it. If the transparent object is rendered <em>after</em> the object behind it, then the colors are blended and the object is rendered transparently.<br />
<br />
In order to implement "real" transparency with OpenGL, the programmer has to ensure that (transparent) objects are rendered after opaque objects in correct order, that is from back to front. In GEF3D, 3D figures were rendered by (recursively) calling their render method. If a figure had to be rendered tranparently, it created a temporary <code><strike>TransparentObject</strike></code>, causing the render engine of GEF3D to render the transparent objects after all opaque figures had been rendered (i.e. in a second render pass).<br />
<br />
Unfortunately a figure may be composed of other figures, which causes a big problem. If a child figure is transparent as well, its transparency property was only be recognized when it was rendered, that is, when its (transparent) parent figure has been rendered in the second render pass. Then it was impossible to add the (transparent) child into the sorted list of transparent objects correctly, as figures of this transparent object list may have been rendered already. In order to solve that problem, we changed the overal rendering strategy in GEF3D:<br />
<br />
Instead of (recursively) calling the <code>render</code> method of each 3D figure, a newly introduced method <code>Renderable.collectRenderFragments(RenderContext renderContext)</code> is called (recursively). Instead of rendering the figure, the figure adds so called <code>RenderFragment</code>s to the render context via <code>RenderContext.addRenderFragment(RenderFragment i_fragment)</code>. When all render fragments are collected, the render context firstly renders all opaque fragments, then sorts and renders all transparent fragments, and finally renders all superimposed fragments (that are objects to be rendered after anything else, e.g., in case of feedback figures). If you acutally have implemented some render code in your figure, you will have to implement the interface <code>RenderFragment</code> and add implement <code>collectRenderFragments</code>:<br />
<br />
<pre><code>
public void collectRenderFragments(RenderContext renderContext) {
return this;
}
</code></pre><br />
In order to avoid the initial problem, <code>RenderFragment</code>s are defined as leafs, that is they are not allowed to be composed of figures. The old interface <code>TransparentObject</code> has been removed.<br />
<br />
<br />
Fortunately, in most cases you do not have to bother about these things, as you could use shapes as explained in the next section!<br />
<br />
<br />
<br />
<h3>Shapes</h3><br />
Due to these changes, and especially because of the need to calculate the intersection of a figre with a (pick) ray, it becomes more interesting to use predefined shapes. Currently, Draw3D includes cuboids, spheres, cylinders, cones, truncated cones and polylines as primitives. If you look at the shapes package (<code>org.eclipse.draw3d.shapes</code>), you will notice that some of the shapes come in two flavours, for example there is a <code>CuboidShape</code> and a <code>CuboidFigureShape</code>. A <code>CuboidFigureShape</code> actually wraps a <code>CuboidShape</code> and adds some convenient functionality in that it automatically sets some graphical properties of the <code>CuboidShape</code>. For example, it sets the <code>CuboidShape</code>'s fill and outline colors to the foreground and background color of the figure to which the <code>CuboidFigureShape</code> is linked. This makes it very easy to create a cuboid shape that represents a figure. Just create a <code>CuboidFigureShape</code> and pass the figure to the constructor and everything else is handled for your.<br />
<br />
<br />
We plan on adding such convenience wrappers for other shapes as well as soon as they become neccessary. If you need such a wrapper, let us now (by writing a post to the GEF3D newsgroup).<br />
<br />
<br />
<br />
In order to use a shape, the figure has to create it somewhere and then add the shape (which implements both, the <code>RenderFragment</code> and <code>Pickable</code> interfaces) in <code>collectRenderFragments</code> to the render context. Since this technique is used rather often, a new figure called <code>ShapeFigure3D</code> has been introduced. All you need to do is to simply implement its abstract method <code>createShape()</code> and create the shape there, e.g., <br />
<br />
<pre><code>
@Override
protected Shape createShape() {
return new CuboidFigureShape(this);
}
</code></pre><br />
Note that <code>ShapeFigure3D</code> does not only use the shape for rendering, but for calculating the distance <code>(Figure3D#getDistance(Query)</code>) and the paraxial bounding box (<code>getParaxialBoundingBox(ParaxialBoundingBox)</code>) as well! You may have a look at this figure if you want to implement you own figure from scratch!<br />
<br />
<br />
<br />
<br />
<h3>General API Changes</h3><br />
<br />
The following list shows the changes which were necessary in order to adjust an editor created with an elder version of GEF3D to the latest revision (rev. 295):<br />
<br />
<ol><li>Changes usually found in your graphical editor:<br />
<ol><li><code>GraphicalViewer3DImpl</code> no longer implements <code>IScene</code>. Instead, <code>LightweightSystem3D</code> now implements <code>IScene</code>, so if you need the <code>IScene</code>, simple replace the viewer with <code>viewer.getLightweightSystem3D()</code></li>
<li><code>LightweightSystem3D.addRendererListener(RenderListener i_listener)</code> was renamed to move to <code>IScene.addSceneListener(ISceneListener i_listener)</code></li>
<li>In order to show correct 3D handles and feedback figures, 2D edit parts are to be modified. This was already the case in earlier versions, it has become easier now and most cases of feedback creation are implemented. Some new policies have to be installed as follows:<br />
<ul><li>Create a node: <code>ShowLayoutFeedbackEditPolicy3D</code> (see Fig. 3, (1) and (2))</li>
<li>Create a connection: <code>ShowSourceFeedback3DEditPolicy</code> (see Fig. 3, (3) and (4))</li>
<li>Move or resize a node: <code>Handles3DEditPolicy</code>, to be installed at parent edit part (e.g., diagram) (see Fig. 3, (5) and (6))</li>
</ul><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibKHPrQB-uPBfg0w2v8F1Vdiio-lUPxJLGYMDvGuKguNJBBGnbst64t1ZK5kk3uazPoqnF0KSOD2UET2f5zHQdF2KTK2fElL6Zjhm0PEXPn7CYw3p_Ai8fMw0xqmWuY1hVZQf9dVAxq5Gz/s1600/feedback.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="412" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibKHPrQB-uPBfg0w2v8F1Vdiio-lUPxJLGYMDvGuKguNJBBGnbst64t1ZK5kk3uazPoqnF0KSOD2UET2f5zHQdF2KTK2fElL6Zjhm0PEXPn7CYw3p_Ai8fMw0xqmWuY1hVZQf9dVAxq5Gz/s640/feedback.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span class="Apple-style-span" style="font-size: small;">Figure 3: Feedback in 2.5D and 3D, simply by adding some policies.</span></td></tr>
</tbody></table><br />
<br />
Only selecting a connection is not implemented yet, we will fix that as soon as possible.<br />
<br />
<br />
The best way to install these policies is by using the borg factory pattern, e.g., <br />
<pre><code>
EditPartFactory originalFactory = getGraphicalViewer().getEditPartFactory();
BorgEditPartFactory borgFactory = new BorgEditPartFactory(originalFactory);
// replace diagram edit part
borgFactory.addAssimilator(new EditPartReplacer(GraphEditPart.class,
GraphEditPart3D.class));
// modify diagram edit part's policies
borgFactory.addAssimilator(new AbstractPolicyModifier() {
public boolean match(EditPart part) {
return part instanceof DiagramEditPart3D;
}
public void modifyPolicies(EditPart io_editpart) {
// feedback when creating a node:
io_editpart.installEditPolicy(
ShowLayoutFeedbackEditPolicy3D.ROLE,
new ShowLayoutFeedbackEditPolicy3D());
// handles and feedback when moving or resizing a node
io_editpart.installEditPolicy(
Handles3DEditPolicy.CHILD_DECORATOR,
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
io_editpart.installEditPolicy(
ShowSourceFeedback3DEditPolicy.ROLE,
new ShowSourceFeedback3DEditPolicy());
return io_editpart;
}
});
getGraphicalViewer().setEditPartFactory(borgFactory);
</code></pre><br />
</li>
</ol><br />
</li>
<li>Changes in figures / edit parts: Often, diagram figures in 3D are simply figures displaying a cube. We provide a cube shape which can be used by the figure. Since using shapes in a figure is a very common case, a new ShapeFigure3D has been introduced. Here is an example of how to use that in combination of a diagram figure which provides a surface as well. In earlier versions, surfaces were implicitly provided by each 3D figure, now you have to explicitly provide a surface. A surface is only needed if 2D content is to be projects onto the 3D figure.<br />
<pre><code>
public class GraphFigure3D extends ShapeFigure3D {
private ISurface m_surface = new FigureSurface(this);
public GraphFigure3D() {
SurfaceLayout.setDelegate(this, new FreeformLayout());
getPosition3D().setLocation3D(IVector3f.NULLVEC3f);
getPosition3D().setSize3D(new Vector3fImpl(400,300,20));
setBackgroundColor(ColorConstants.white);
setAlpha((byte) 0x44);
}
@Override
public ISurface getSurface() {
return m_surface;
}
/**
* {@inheritDoc}
* @see org.eclipse.draw3d.ShapeFigure3D#createShape()
*/
@Override
protected Shape createShape() {
return new CuboidFigureShape(this);
}
}
</code></pre><br />
</li>
</ol><br />
We have adjusted all examples (the 3D ecore editor, 3D UML editor, and 3D graph editor), so you may have a look at these editors.<br />
<br />
<br />
I have written a tutorial article explaining the basic concepts of GEF3D, it will be published in the next issue of the german journal <a href="http://www.eclipse-magazin.de/">Eclipse Magazin</a>. An english version of this article will be made available as soon as possible. In this first article, a sample GEF editor is 3D-fied. We have planned to write a follow-up article explaining how to 3D-fy GMF based editors as well.<br />
<br />
<br />
<em>Jens</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-41546592040632319082009-06-24T00:51:00.000-07:002011-01-25T07:33:01.687-08:00GEF3D and GalileoEclipse 3.5 is going to go public today, and part of the train is a new release of GEF which introduces a couple of new graphics features. Graphics is GEF's main interface to the graphical subsystem and is used in all 2D drawing operations. Since GEF3D replaces GEF's SWTGraphics implementation with a GL-enabled version that directly renders to the video card memory, we had to extend our Graphics implementation so that it works in Galileo. These enhancements have been committed today (see <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=268643" title="Implement new GEF 3.5 features in Graphics subclasses">bug 268643</a>).<br />
<br />
<strong>Be aware that GEF3D now depends on GEF 3.5 and is not backwards compatible</strong>. From now on, you need Eclipse 3.5 to run the latest version of GEF3D.<br />
<br />
GEF3D has been tested with both the Cocoa and Cocoa 64 releases on Mac OS X and it works fine in both versions.<br />
<br />
<em>Kristian</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com0tag:blogger.com,1999:blog-6752420175516884861.post-7441744530553338042009-06-21T04:23:00.000-07:002011-01-25T07:33:01.691-08:00First post!Hi everyone and welcome to the GEF3D development blog. In this blog, Jens von Pilgrim (GEF3D project lead) and myself, Kristian Duske, will be posting about, well, GEF3D development! This will include articles about problems we have to solve, progress reports, issues that arise when extending GEF, and other topics we deem interesting.<br />
<br />
What is GEF3D, you ask? In a nutshell, GEF3D is an Eclipse GEF extension bringing 3D to diagram editing. Of course, there's a lot more to it. Find out more about GEF3D at the <a href="http://www.eclipse.org/gef3d" target="_self" title="GEF3D project page">GEF3D project page</a> and watch the following video to see GEF3D in action.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/fD5QLuPo-uE?feature=player_embedded' frameborder='0'></iframe></div><br />
<br />
<em>Kristian</em>Jenshttp://www.blogger.com/profile/02917307604100174698noreply@blogger.com1