Handheld based interaction using AR

it is time for the next demo of my project, as I reached the beta status. (feature complete) I think you can see quite clearly now where this is going and which kind of interactions will be possible using this technique. The concrete features are described in the annotations.

If you use more advanced tracking methods and add some physics to this, you could easily port numpty physics to this kind of interaction or create an easy to use level editor. In case you missed my last video, here is the link.

It will still take some weeks until this hits maemo-extras as there are still some bugs left and I still want to get rid of keyboard use for interaction.

Thoughts about MeeGo

In a country with freedom of speech, one has to say something to every happening, right? So here is my try:

Basically the merge of Maemo and Moblin is logical and consequent as Nokia and Intel already collaborated with ofono and merging helps joining the efforts. This is quite necessary as neither Maemo nor Moblin could survive on their own in a world where everybody else uses Android and soon will start using Chrome OS. There was also a need to make Moblin more like Meamo to be able to compete with the iPad.

That sounds greet so far, right? Joint efforts, bigger community, open to everybody… But the problem is the way the merge is going to happen. Moblin is more or less a huge techdemo so far – everybody who I know uses Ubuntu Netbook Remix on their Netbook, as it is more production ready and end user oriented. The same also applies to Maemo.

It is a bit sad that the next Maemo/ MeeGo Harmattan will be Qt based though, at it means that all the currently working applications have to be rewritten without gaining an immediate benefit. But considering that Qt is technically more advanced than GTK and that it allows deploying your application on the different OS Nokia uses this is understandable.

What is less understandable is that MeeGo will be based on RPM/ Moblin/ Fedora. And at least for Fedora the official motto is merging new features as fast possible, which is nice for developers but less nice for end users, as the distribution is less stable. So while it is logical to base a tech-demo like Moblin on Fedora, I would not base anything that is supposed to be stable on it.

But this is exactly what shall happen with MeeGo. This means Maemo has to abandon its Debian roots and rebase everything to RPM. By everything I mean the huge amount of packaging experience gained during the last 5 years, the build infrastructure and of course the core package management applications. This has also an impact on the community infrastructure, downloads, karma are coupled to the DEB format too.

So what do we gain by rebasing to RPM? Maybe the Moblin interface which is indeed nice? Actually no, as it is Clutter/GTK based while MeeGo will use Qt – besides the Moblin interface was packaged by Ubuntu as deb too. Ok the Moblin community will not need to change its infrastructure, but is the Moblin community actually that big?

As I really wonder why we switch to RPM I started a wiki to collect the arguments, and as it does not look too good for RPM also a brainstorm vote.

AR shadowmapping demo

while my last video already contained augmented reality and shadow mapping, it did not really show the potential of shadowmapping, therefore I created another video

other news are the tracking of multiple individual markers(quite obvious) and the camera relative light source. The latter is necessary to cast the shadow of all objects in the same direction.

As some of you wondered where the sense behind all of this is; I write the program as a project work at the university. The aim is to create an easy way to create and modify 3D scenes.

Tablet PCs – a chance for Maemo?

I just have watched the Apple iPad announcement and I have to say that I am quite impressed by the Apple marketing team. Before the film I could not think of a good use case for a oversized iPod, but after the film I have to say that Apple greatly refined the use case of the netbooks as a second PC.

Instead of putting an ordinary OS into a differently shaped device, like Microsoft is seemingly doing with the Slate, Apple adjusted the OS to the new use case.

If you have a much smaller screen and a much smaller keyboard, like you have on netbooks, you don’t want to write long articles or aim for the tiny buttons of ordinary user interfaces. Instead one should of a netbook like a playback device, which only requires rudimentary interaction.

As apple is great at streamlining stuff, they simply left out the keyboard and used a modified version of the iPhone OS, which is optimized for easy usage and – voilla here comes the computer you actually want to use in your living room, to quickly peek on facebook or your mail inbox.

But there are two big disadvantages that come with using the iPhone OS. First it is stripped down to much; there is no multitasking and no system clipboard which takes a lot of the convenience you have when using a real OS.

And second you are again locked-in by apple. If you use the iPad, you are also more or less forced to use iTunes for your music, iBook Store for your eBook and the AppStore if you want new Software.

Of course you might be able to Jailbreak the device and use third-party software but this will be nowhere as convenient as using the defaults. This is Apples Achilles heel and where Maemo can triumph.

With Maemo you basically have a full-fledged Linux with a easy to use UI. You have multitasking, you have a system clipboard and most importantly you have an open software repository – and all of this very well integrated in the UI.

You can freely choose your email provide, your music player and even the format you save your music in. And even though Nokia does not support OGG by default, the open nature of the OS allows it to be just as integrated as everything else.

Actually Nokia only has to build a Internet Tablet with the size of the iPad…

ArtoolkitPlus for Maemo

I just uploaded the latest version of ArtoolkitPlus to Frementle devel, so you can start playing around with it soon. Artoolkit is a marker tracking library which allows Augmented Reality applications similar to ARhrrr possible. I am currently working on a AR application for the N900 as part of a project work for the university. Of course it is not quite as advanced as ARhrrr, but it certainly runs better than this demo on the iPhone 🙂

PowerVR SGX 530 does NOT support Depth Textures

If you download the PowerVR SDK for the TI OMAP3430 which is used in the N900, you will find a nice shadow mapping examle which uses the OES_depth_texture extension. You can even run this example using the included emulator using the SGX 530 profile.

However if you try to run your code on the actual device you will soon find out that it does NOT support OES_depth_texture. This is quite surprinsing as the device supports OES_texture_float and OES_depth24, so depth_texture should be not too hard to implement.

But the situation is the same on the iPhone 3GS, which uses the same hardware. This leads me to believe that this is not just a driver limitation.

However here is a workaround using a ordinary RGBA texture and byte packing:

const highp vec4 packFactors = vec4(256.0 * 256.0 * 256.0, 256.0 * 256.0, 256.0, 1.0);
const highp vec4 cutoffMask  = vec4(0.0, 1.0/256.0, 1.0/256.0, 1.0/256.0);

void main() {
    highp vec4 packedVal = vec4(fract(packFactors*gl_FragCoord.z));
    gl_FragColor = packedVal - packedVal.xxyz*cutoffMask;

the packFactors vector basically contains the 3 necessary byte wise shifts to the left. The call to fract() cuts off anythig which is to the left of the byte we want to save and subtracting packedVal.xxyz*cutoffMask cuts off anything to the right of the byte.

The cutting is necessary as we are dealing with floating-point here and we dont know how the hardware selects the value that should go in.

TI OMAP3430 (inc. Nokia N900

GLUT for C++ and OpenGL ES

did you ever try to use GLUT with C++? Do you remember the pain of having to make you member function static, so they can be used as a callback? Maybe you also want to create a OpenGL ES2 context if you develop for mobile devices. But although the latest freeglut supports OpenGL3 contexts, you are still out of luck using GLUT here. But there is rescue:

#include <QGLWidget>

class View : public QGLWidget {
 View();  // glutInit
 void initializeGL();
 void paintGL(); // glutDisplayFunc
 void resizeGL(int width, int height); // glutReshapeFunc
 void keyPressEvent(QKeyEvent *event); // glutKeyboardFunc

and thats it. Works with OpenGL2 and OpenGL ES2 and integrates nicely with the Object Oriented approach. As Qt is LGPL today you can also use it in closed source projects and as you see, you can easily migrate from GLUT without changing all your code 🙂

YouAmp 0.6 has grown

After several betas the final release of YouAmp 0.6 is almost there. You can find the current versions in the launchpad PPA for Ubuntu and in maemo-extras for N8x0.

YouAmp DesktopYouAmp Maemo

the new features are:

  • Playlists
  • Automatic Cover Download
  • Adding Files from anywhere, not just the music library (just drag and drop in Desktop version)
  • you can pay for YouAmp now

I would like to emphasise the last feature: make me a millionaire! No seriously – if you like YouAmp consider a small donation > 0,30€ (otherwise everything goes to paypal) which will help developing the program in my free-time. 😉

As I did not get into the Developers programme for the N900, I also accept unused discount codes – in case you would like to see YouAmp on the N900.

OpenGL on the N900

some people already got enthusiastic because they heard that the N900 – nokias latest Linux phone supports OpenGL. Playing games like Frets On Fire on your phone as soon as you got one was a common expectation. But this will not be possible – at least not as easy as you might think.

OpenGL does not always mean OpenGL. There is OpenGL1, OpenGL2, OpenGL3, OpenGL ES1 and last but not least OpenGL ES2. While all contain OpenGL in the name and are somewhat similiar they are not compatible with each other. Basically only GL2 is compatible with GL1 programs. As soon as the deprecated stuff will be removed from GL3, GL2 programs wont run any more. Generally GLES is also not compatible with GL – but programs written in GL2 are very similar to GLES1 and programs written in GL3 are likewise similar to GLES2. So porting between this two pairs is easily possible. The problem is that Quake3 was written with GL1 and the N900 only supports GLES2. This means that basically the whole renderer of the game has to be rewritten.

Another problem is that FretsOnFire uses SDL1.2 for input/ output handling and context creation(through pygame). But SDL1.2 uses GL1 for context creation so you cant use that. Luckily there is SDL1.3 which also supports GLES2 but it is not available on the N900 yet.

So in order to get an existing game running on the N900 one would have to rewrite the engine using the GLES2/GL3 model and replace any libraries  (SDL1.2, GLUT) with direct calls to EGL for context creation and Xlib to get the window . The port of Quake3 to Maemo shows that this is possible – but it will usually take more time than a simple recompile.