| [gef3d-dev] GEF3D todo list 2010-01 |
| Hi all, Madhu asked me about a todo list for GEF3D. In general, we should use bugzilla more than we do today. I'm starting this todo list in order to discuss and involve ideas about what todo next, and how to split up certain tasks into smaller junks, which we can then file as bug reports. Latest development news Kristian is currently refactoring the draw3d system. He already replaced the old technique for rendering 2D content onto planes: Instead of creating textures of whole 2D diagrams, the 2D content is now rendered natively by OpenGL. For that purpose, all the 2D shapes are sorted and organized into so called vertex buffer objects (VBOs). I just saw the result of this yesterday and I'm still in shock! It's amazing to see how it is possible to smoothly move the camera around 5000 nodes. I would say: We have no performance problems with GEF3D anymore. It may still become a problem loading such large models, but these problems are more related to GEF/GMF then to GEF3D. Great work, Kristian! Madhu has implemented a JOGL renderer for GEF3D. Since LWJGL was not IP approved, and hopefully JOGL will be, we are going to replace the current LWJGLGraphics implementation with Madhu's new JOGL renderer. Because I'm currently writing my Ph.D. thesis (which hopefully will be submitted in March) I'm not able to do much coding for GEF3D at the moment. The most important task would be to implement a build system for GEF3D (in order to create a release and nightly builds etc.), but I'm afraid I won't be able to do that before April. JOGL is still under IP review, and I'm not sure when it will be IP approved. Alex Boyko, a GEF committer, has declared his (and the GEF team's) interest in OpenGL/JOGL as well. He is especially interested in an OpenGL based implementation of the Graphics interface, which we have already implemented in GEF3D (and which was extremely optimized by Kristian in the last weeks). So, this maybe will help to bring JOGL to Eclipse. Todo list 1) replace 2D font textures with 3D vector fonts (Kristian) Based on the new 2D rendering, we will be able to also use vector fonts instead of texture based fonts. Kristian is already working on that issue. 2) create JOGL plugin after JOGL has been IP approved, and put it to the Eclipse orbit (Jens); import JOGL renderer, i.e. Madhu's contribution Unfortunately we have to wait until JOGL is IP approved in order to switch to JOGL. I will import the JOGL renderer as soon as possible. 3) create build system, prepare releases (Jens) Setup build system based on Athena, Buckminster, and/or Hudson to enable releases and nightly builds. 4) camera tracks Design and implement camera tracks. A prototype has already been created (by Andreas Bauer in a master thesis I tutored). We will need a concept how to activate a camera track (handles, double click, actions, tools) and how to describe a camera track (start/end position and view direction, track described by splines?), undo for camera tracks (i.e. look at a special object and then return to old location), special targets (move plane to front, i.e. view plane in 2D manner; overview, i.e. look at whole scene; etc.), extensible track description, extensible targets. 5) add more (3D related) handles For a lot of functions more handles would be necessary or at least helpful. E.g., handles for 3D rotating or positioning of elements (see 12)), for activating camera tracks (see 4)), etc.. Some of these handles may be element related and could be implemented just as GEF handles, others might be element independent (e.g. for camera tracks). Maybe we also could some scene wide handles, that is a kind of navigation menu, similar to Google World or Map menus. 6) camera move in drag operations When dragging an element, currently the camera cannot be moved. We need a concept (and implementation) on how to enable camera movement with the mouse button pressed. Maybe we can do something like these spring-loaded folders on Mac OS X (i.e. a camera track is activated if the mouse pointer is moved and hold onto an element), related to 4) 7) magnifier Add a special view, possibly visualized on top of the 3D scene, in order to magnify elements. This could be combined with 6), 5) and 4). 8) level of detail techniques Elements far away from the camera could be replaced by special shapes. E.g., a plane with a diagram could be replaced by a simple label. This will not only lead to higher performance but to better readable large diagrams as well. Since this feature is closely related to rendering in general, Kristian will probably design and implement that feature. (Also see 24) ) 9) export bitmap Enable screenshot like export of a scene, maybe with special background and rendered in a higher resolution. 10) scrollable planes Implement scrollable planes in order to enable large 2D diagrams. Related to 12) 11) 3D model importer Implement (or find a possible contribution) for importing 3D models (3ds, obj etc.) in order to be able to use existing 3D models as figures. 12) interactive rotation and 3D positioning (movement, resizing) Currently, only 2D content or 3D elements located on a plane can be moved in 2D manner. Besides that, elements (and especially planes) should be movable in all 3 directions (x, y, and z!) and be rotatable (around x, y, and z axis). This is related to handles 5) and probably special 3D layouts 17). 13) lights and materials Implement lights and materials in order to improve 3D awareness. 14) (SWT) overlays Enable SWT overlays in order to enable GEF's direct edit mechanism and combined graphical and textual models. This is related to 6) as the camera may be moved in order to see a 2D-like perspective of an element which is then edited with an SWT widget. Actually, SWT overlays are already working, but not correctly positioned at the moment (and dure to missing camera tracks, the overlay is not very nice embedded into the scene). 15) 3D direct edit Instead of using SWT widgets (see 14)), we may be able to directly support editing of text in 3D. 16) svg export Exporting 3D diagrams to a vector format would be a very nice feature. Note: X3D export is already implemented, but it is no longer working and will be moved to an archive branch. (IMHO X3D export has been a nice proof-of-concept, but in my experience X3D viewers are that bad that it doesn't make sense to support that format in the future). 17) 3D layouts We already implemented a very simple stack layout of planes in a 3D scene. Kristian implemented a cube-like layout in his master thesis, and I could think of other standard layouts similar to coverflow or time machine. As these layouts are dynamical, they may require additional tools/actions or navigation handles (see 5)). 18) WebGL/RAP support Currently, a student is investigating on bringing GEF3D to the web using RAP and WebGL. I think we should investigate further in this direction, since web applications become more and more important. A first step would be to at least enable GEF3D viewers embedded into a web application using WebGL. 19) bump map effects 2D content is now rendered with real 3D vertices. Maybe it would be nice to add 3D effects to 2D content, i.e. render 2D boxes as 3D cubes with a default high. 20) tests tests tests We need more tests. For some classes we could simply write JUnit tests, for others we might need more sophisticated concepts. E.g., testing the renderers, testing platform related issues and so on. 21) docs, docs, docs We need more and better documentation. I think we aren't that bad, we have some basic Java docs. The article series published in the german Eclipse Magazin is partially translated, I have to ask the publisher when to publish these versions on his web page (or maybe create an Eclipse corner article). 22) support stereoscopy Hardware for real 3D, using red/green, polarized or shutter glasses, is becoming more and more available. Implementing support for red/green glasses may easily be implemented. Although this technique is not the best one, it is relatively simple to be implemented, in order to prepare GEF3D for better solutions. (Actually I tried to implement a prototype for that technique some time ago, but without success -- there are some problems hidden under the hood, this is why I think we should implement a very simple solution soon, in order to be prepared). 23) remove restrictions related to 2D textures One tricky task would be to remove restrictions related to the old technique of projecting 2D content onto planes using textures. This technique is still available, Kristian implemented a kind of switch in the renderer functions in order to still support the old strategy. However, there were some "restrictions" only related to the texture based projecting. E.g., at the moment, 2D connections can only connect two figures on the same plane. The DispatchingConnectionLayer is a result of this restriction -- and I'm not sure if it is still required in with the new implementation. As 2D figures are now rendered just like 3D figures, they are not restricted to be placed onto a surface anymore. OK, the surface is still necessary in order to calculate the 3D coordinate for a 2D figure, but it isn't required for rendering anymore! While i'm not sure whether the DispatchingConnectionLayer is still necessary for rendering, it may become important for todo 24). 24) support diagram proxies One of my "visions" is to use GEF3D as an integrated modeling environment. Instead of fiddling around with configurations files or megamodels using tree based editors, transformation chains (or model chains) could be simply set up by dragging models (or their diagrams) onto a single GEF3D scene. The multi editor feature of GEF3D is already supporting this, actually in this context GEF3D provides more functionality then only 3D (multi editors and inter-model-connections are not only related to 3D! ). One problem in this context would be the enormous amount of model elements and figures when all models of a larger project are to be visualized in a single 3D scene. For that reason, we have to support some kind of diagram proxies. That is, similar to level of detail (see 8) ), a diagram is rendered only as a simple (labeled) box, and its content is only visualized on (user) demand. The user should be able to load and unload (!) diagrams. Loading/unloading diagrams actually means (un)loading two things: the models and the GEF stuff (edit parts and figures). The first issue is EMF related, the second one may could be solved or at least supported by GEF3D. Maybe we have to talk to the GEF and GMF guys about that issue, as it may occurs on larger 2D diagrams, too. 25) profile GEF3D When I started GEF3D with Java3D, I was only able to visualize 100 nodes. In the second version, which then became the Eclipse GEF3D project, based on LWJGL, it was possible to smoothly work approx. 2000 nodes. The latest version with the optimized 2D rendering is able to visualize 5000 nodes and to move the camera with more than 100 FPS. The memory and performance restrictions are now not longer due to GEF3D, but GEF. Still, there might be some leaks in GEF3D, and we have to investigate in finding them by carefully profiling GEF3D. 26) update GEF3D project plan (Jens) The current GEF3D project plan states 10/1/2009 for release 0.9. Obviously we weren't able to make that. I will have to update the plan accordingly. Nest steps I would suggest we all collect more todos here and discuss the todos above (and describe the todos in more detail). If possible, we should split up the todos into smaller tasks. We have to identify dependencies, prioritize the tasks, estimate the effort and finally file a bug report for each task. Since Kristian and I are both looking for new jobs in the next months, we cannot really define a plan since we do not know how much time we will be able to spend in GEF3D programming. Some tasks may be suitable for students, and maybe we will be able to provide support for master theses or other similar projects (e.g., Goolge Summer of Code). Some tasks may require changes in the core system, we will have to identify these things as soon as possible, because IMHO we should prepare these changes before we create a release. Same is true for very important things, such as 4), 5) and 12). When we have discussed this todo list internally (that is on the developer mailing list), I could also write a GEF3D blog entry with this list -- maybe other developers may have new ideas or will become interested in GEF3D. But I think we should discuss that list internally, first. Some closing remarks The latest optimizations by Kristian did not only dramatically improved the overall performance, but also the quality of the visualization. Kristian is currently working on implementing vector based fonts. If we (or better to say, Kristian ;-) ) is able to implement this and if the performance is not too bad, GEF3D's visualization quality will be as good as GEF's 2D one. As the performance is already as good as the 2D one (and hopefully it will not be effected too much by replacing the font rendering strategy), and since almost all 3D related issues are hidden from the programmer, there will be no reason to only provide 2D editors anymore. Think about that.... Cheers Jens |