Why. Recently I got a Nexus 7 (see last blog post) and want to use I not only to consume & communicate, but also to create. Also, 3d content creation (e.g. for game projects) can be a time-consuming task. Currently I am bound to the desktop that time. It would be nice to do this work on a mobile device, e.g. while on travel or outdoors. Thus this projects aims to be a 3d editor for mobile and desktop.
►Youtube demo
►Start
Current features. The interface is accessible for touch and mouse input. This is done via the handling shown in following table and with an menu approach which is described below.
| Mobile | Desktop | |
| Mesh edit (point drag) | 1 touch drag | left mouse drag |
| Rotate | 2 touch drag | right (or ctrl left) mouse drag |
| Zoom | 2 touch distance | mouse wheel (or shift left mouse drag) |
| Position | 3 touch drag | middle (or alt left) mouse drag |
- Static meshes can be edited by adding and removing points and polygons.
- There is an Undo function, unlimited, except RAM. :)
- Meshes can be loaded/saved via localStorage and imported/exported via textarea.
- A grid can be set to construct geometric shapes.
Roadmap. Following will or may be introduced later.
- Skeleton based meshes and animations.
- Maybe augment these with (bullet.js) physics to construct ragdoll behavior. A proof of concept is shown in an older blogpost.
- The editor should use WebGL, if it is available.
- Texture editing. For this, web based texture painting has to be integrated.
Approach for touch menus. Because mobile devices may have a small screen and to have a maximum room and focus for the edit object, a menu should not take lots place. On the order side to be touchable a menu should not be too small. Because on mobile device there probably are no hotkey menu shortcuts, it should be quickly accessible, there should be a short way to invoke actions. To have all of this self-conflicting properties implemented, the menu here works as follows:
- Single menu start button. The menu can be accessed via a single start button, which unfolds tree structured sub menus. Thus only minimal space is used. In comparison, standard desktop applications often have a menu bar, where a number of menus is displayed all the time, even if they are seldom needed. Interestingly modern browsers also dismissed menu bar in favour of a single menu button.
- In place unfold. While browsing a standard desktop menu sub menus stay displayed. Here only the current sub menus are displayed. Thus fewer space is used, but traceability may decrease somewhat.
- Recent menus. Because there is a single menu start button instead of a menu bar, menu items are one step farther away, thus less accessible. Therefore menu items, that are potentially often invoked, like "Point add", are displayed after a first use besides the start menu button. Thus for a next invocation now only one click/touch is needed, it is fastest accessibility possible, like a hotkey. Now effectively again a menu bar is used, but with use-dependent menu items. The number of recent menu item is confined, thus menu takes still few place. If the menu is browsed/unfolded, recent menu items are not displayed.
- Undo menu. Like recent menus the undo menu is displayed besides the menu start to quickly revoke flawed actions.
- Secondary menu information. Because in general less menus are displayed, but each menu item is drawn bigger to be touchable, inside the menu item further informations can be displayed. In standard desktop menus with lots and small items there is no natural way for such information, sometimes tool tips are applied. In W3dit secondary informations is used to mark recent menus, the Undo menu shows the number of possible undo steps.
- Modal dialogs. The menu is also used as control buttons of modal dialogs. On desktop, if a modal dialog is shown, the application and its menu is still shown, but interaction is disabled. Thus, since the normal menu is not needed during modal dialogs, the menu can be utilized to render dialog options.
Posts
