Wloom 0.10: Desktop and Nexus 7

This time focus was, to have the same WebGL game demo being fluently playable on both Desktop and Nexus 7. To achieve this, on Nexus 7 the resolution is lowered. Also different renderers for different platforms are used. On Nexus 7 its a simple one, on Desktop its a more advanced renderer using GLGE for better effects (shadows, particles, lights). Finally, to have the demo being playable on Nexus 7, touch controls are added. They are visible on Desktop too and then display, which keys are pressed.

►Youtube
►Start demo (WebGL enabled browser, on Nexus 7: Firefox Beta, Opera mobile, Chrome beta with flag set)

This is probably the last blogpost before the end of the world on 21.12.2012 of this year, thus happy holidays and a good new year everybody! :)

Update 8.1.2013: Added improved menu and gamepad support. Gamepad works here with Chrome on Desktop. So now the demo runs on desktop and mobile with either keyboard and mouse, touch or gamepad controls. Its a nice level of 'write once, run everywhere'.

Update 26.1.2013: Chrome beta for android with easy WebGl access is now released. There, lowered resolution is no longer necessary since fps stays high on high resolution. Graphics shows performance of different browsers on Nexus 7 at different resolutions. Added a fullscreen menu item. On Nexus7 it works only with Chrome beta.

W3dit - Web 3d editor

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

Following can be done currently in the editor:

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

So currently the 3d editor is quite limited because only static meshes are handled. A usecase may be the construction of game level architectures, here the grid is useful.

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.

Javascript demos: Description logics and 2D Physics + Nexus 7/Android impressions

Description logics Rules can be defined, which then can be queried. The implementation is a simple description logics tableau resoner. Basic queries are of subsumption type, they ask if a concept subsumes another concept. Subsumption can be seen as is-a relation. Of multiple concepts a subsumption hierarchy, aka taxonomy, can be calculated and displayed.

2D Physics The demo is based on connected particles. Particles can be dragged and thus things go into motion and rotation. On top of this particles a vector graphics is drawn, which moves and deforms with underlying particles.

Nexus 7/Android impressions I got me this device and do quite like it. Programming-wise it made me explore some javascript apis, that I not much worked with before: touch-events, tilt-events, fullscreen, localStore. I tested with Chrome and Firefox Beta. Browsers still not support everything, but I hope that changes. Also I finally played some Minecraft PE. :)

Wloom 0.8: Demon forest

Finally a new version of WebGL game project Wloom. This time focus and new features are as follows:

• Spooky environment and gameplay: Fight demons and survive.
• Better sound via freesound.org.
• A shotgun.
• Update: Uses html5 fullscreen and pointerlock abilities.

►Youtube
►Start demo (WebGL enabled browser, no IE)

Danger on the floor

In programming languages (tested in javascript and perl) you will get:

6*1.9*5 == 6*5*1.9 -> false

Because of calculations errors during floating point operations, the expression values differ by a very small amount. Here we get 57 and 56.9999... Floating point operations are not associative. One can work around this imprecission by never directly comparing floating point numbers, but always calculating with a small tolerance. Like this:

Math.abs(6*1.9*5-6*5*1.9)<0.00001 -> true

Now, when you use the floor function, you will get this:

Math.floor(6*5*1.9)-Math.floor(6*1.9*5) -> 1

The small floating point value difference has grown to 1. The difference is now substantial and might make a program do unexpected things. So, how to handle the floor-function here ? One could add a small value before applying floor. But then the value could grow too big and the floor-result is flawed again. The problem is, that the floor function cannot known if a value like 56.9999.. is a calculation error or deliberately constructed. In my opinion there is a systematic danger with using floor-function, because floating point numbers are imprecise, while the floor function has a big result-difference, dependent on a precise number. So in dealing with floor-functions there are this conclusions:

• One should try to avoid imprecise floating point operations. Maybe calculations can be done with fixed point or fractional numbers.
• If you have imprecise floating point numbers, dont use the floor function.

3 Canvas demos

Long time no update for this blog. Here are 3 smaller canvas demos, that were created during that months.

Army of the Immortals. A simulation of mortal and immortal entities, which might illustrate, why natural evolution hasnt created immortality yet.

Perspective texturing. Using baryonic technique textures are drawn on canvas. This can result in artsy pictures.

Image viewer. Scrollable, zoomable with mouse(-wheel) and keyboard. With minipicture.