Hi everyone!
First of all thank you Jens for this comprehensive and detailed list. It's good to get all this down on "paper". Now for my remarks:
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.
I will be working on this until the end of January.
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.
This is also related to the general problem of animation, since a camera track is nothing but an animation. We may need to investigate this because for animation the usual drawing mechanisms in GEF (update manager etc) are not optimal. So I'm adding
4b) animation Design and implement an animation system that allows certain aspects of a scene (figures, layers, camera) to be animated in a controlled manner. That means that an animation must have a defined timeframe and not be dependent on FPS. Sometimes, animation involves model changes, in such cases, the update manager must not trigger an immediate redraw, since the animation should take care of that. The user must be able to cancel an animation (for example a camera track) and regain control at any point in time. Changes performed by an animation must in such cases be rolled back.
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.
I think we need to clear up the terminology here. On the one hand, there are handles - these are figures that are part of the scene and that allow manipulation of scene objects by using the mouse. On the other hand there are widgets, or controls, that allow manipulating a diagram as a whole or controlling aspects of the scene that are not content-relatet at all, like for example the camera position.
Some, if not all of these, can be implemented as GEF figures that are part of special layers, which would also make it easier to render them correctly. This is also related to 10), 12) and 15) because those features require the use of handles and widgets.
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)
There are situations where the spring-loaded folders behaviour falls short, for example if you want to drag an element to a plane that is not in view at all. We could either have "hot edges" so that the camera starts to pan if you reach the edge of the view while dragging an object. Another alternative would be some sort of basket that can hold elements. It would work like this: Drag objects into the basket, move the camera, drag objects out of basket and onto target.
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).
This tool should not only magnify what's under the cursor, but the magnified view should always be rendered from a view point that is perpendicular to the surface that is currently under the cursor. This would make it a lot easier to make out what is under the camera.
10) scrollable planes Implement scrollable planes in order to enable large 2D diagrams. Related to 12)
3D planes which have scrollable content should also have a widget button that allows to them to be "maximized" so that the entire content is visible. We need to think about what happens to 3D connections of 2D nodes which are currently not visible (because they are scrolled out of view).
13) lights and materials Implement lights and materials in order to improve 3D awareness.
We should also explore depth of field effects for this purpose.
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.
Maybe it's more useful to use "popups" when directly editing an element. If the user double clicks a text label to edit it, show a pop up that is shaped like a speech bubble above the label and display the SWT widgets in there. This might save us some headaches. It is also possible that direct edit simply does not work in 3D from a usability standpoint.
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.
This is called extrusion and is very easy to implement for 2D content.
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).
Personally I think this has very low priority. I just don't see anyone using this (yet).
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.
Unloading the models is not necessarily related to EMF, since GEF does not require the model to be EMF. Not sure how this could work, but I agree we must investigate.
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.
Definitely. I recently found a huge leak by observing Draw3DCache. I am pretty sure that there are plenty such problems, and I believe we can speed up a lot of things.
Best regards Kristian |
