Abakia Project

Lately I spend some hours for a research on WebGL. It’s quite amazing in which ways internet technologies have evolved. I still remember times, when it was nearly impossible to render any graphics using JavaScript only. Nowadays it’s one of the minor difficulties since we have technologies like SVG or Canvas. Even after animated realtime graphics are nothing special anymore, there’s a new player in town: WebGL.

3d computer graphics in web applications seem to be still a topic thats is heavily associated with technologies like flash, shockwave or other plugin based platforms. This may become history soon. At least if the development of WebGL browsers will proceed as it currently does. If you already use a WebGL enabled browser and had a look at one of the several examples as they appear constantly on http://learningwebgl.com/, then you will figure out quickly what I’m talking about.

Beside the usual operations we are familiar with from nearly any 3D engine, the most Important part on WebGL seems to me that we are able to use vertex and fragment shaders in the usual native way. While the whole application code is written with JavaScript, the shader programs will be implemented in a C style shader code. In the end nothing special for OpenGL veterans. But hey! Exactly that’s the point! If you’ve ever developed your personal, most awesome shader ever, there’s the possibility to reuse or partly use them for WebGL. There’s an amazing experiment written by Inigo Quilez about this shader topic. It’s called Shadertoy (don’t forget to use a WebGL enabled browser). The Shadertoy website, currently offers you about 28 sample shaders of different kinds. All are looking very pretty and all are native shader programs, which are executed on the graphics accelerator. Hardware acceleration for Webapps: Just great!

The basic possibilities offered by this technology may end into enourmous impacts for webstandards. You already may have recognized the Flash Gordon Project of Tobias Schneider. His approach is to implement an open source flash runtime, written in JavaScript. Imagine this implementation, using the powers of GL rendering. Or ways better: a new runtime plattform using WebGL as rendering layer.

Enough of nerdy enthusiastic day dreaming. There are still some difficulties with WebGL. At first of course, the minor density of WebGL enabled browsers out there in userland. But there’s a silverline on the horizon: last September Mozilla announced to implement WebGL in future versions of Firefox. The current nightly builds yet implement it, but it’s disabled by default. So it’s just a matter of time, when WebGL will be available easily by default.

Second flaw: It is quite uncomfortable to keep track of all matrix transformations by yourself. Bare WebGL won’t do that job for you. Many examples on the internet (including the Learning WebGL lessons) implement their own helper functions for identity loading, by encapsuling Sylvester (vector and matrix math for JavaScript) routines. That’s a common but never the less hacky way to fix the problem. And even creating simple basic shapes still produces a lot of code. Many shaders are embedded directly into HTML code, like it is well know from CSS or JavaScript embedding. That feels pretty ugly, when you’ve a complex WebGL application in mind.

In my opinion, the best solution for this case is WebGLU by Benjamin DeLillo. This library is a set of frequently high usefull routines for developing your very own WebGL application. You can load externalized Shader code, enjoy the ease of a camera and many more fine features.

So if you are interested into WebGL now, you should have a look at Learning WebGL. It’s in my opinion one of the best and most up to date resources on the net. If you are interested in the papers and basics of the new standard, it’s the best to search The Khronos Group website for further information.

If you’ve any other interesting news or resources for WebGL, please leave a comment or message me on any of the known ways.

Okay, everybody stay calm now, there’s no reason to panic: I got a new showcase! Yes, it’s a brand new one. Please… ladies and gentlemen, please! Let’s behave like well civilized people. There’s enough for every single one of you.

After my last showcase went broken some months ago, I promised to myself to create new one next (actually THIS) year. You may see the results at http://www.abakia.de/showcase/. I made heavy use of native flash features, as well as of my interactive framework called Monosodium.

So actually this is also a double release party. When I started developing ActionScript Flash in 2008, I also began to collect often used chunks of code and glued them to build a giant tar ball of death. No, that’s not what the framework is actually made of. In late 2009 I throw away the prototype and started to create a better version of the old framework library collection… frankenstein monster.

The rewrite resulted in a lightweight and easy to use flash framework, for creating view based interactive flash apps. There’s probably nothing ground shaking with this framework but it’s my very personal 2 cent and “thank you” to the flash community itself. The project is still lacking some documentation. But I’m working on that as I continue integrating features and refactoring the code. Yes, the framework is still under heavy development. You know the game’s name: commit early, commit often and listen to the audience.
So if you’re interested in the framework, please give me some feedback on that.

Special thanks goes out to Sebastian Deutsch (9elements), for supporting me while developing Monosodium in the early stages.

I just wanted to share a tasty piece of cake code with you. I’m currently doing some JavaScript research concerning HTML5 canvas. When developing JavaScript using the Firebug extension, there’s the possibility to use window.console.log(string) to output some information. Okay, there’s the alert(string) command, too. But to be serious: it’s totally useless, when it comes to the debugging of some complex loops.

So I spend some minutes to build a Quake style drop down console. It works fine with jQuery 1.3.2. Just add a div Element named with id=”debug” to your HTML code and make use of the attached CSS and JavaScript. Enjoy!

1
2
3
4
5
6
7
8
9
10
11
12
13

#debug {
    position: absolute;
    top: 0px;
    left: 0px;
    width:98%;
    overflow:auto;
    color: #000;
    background:#888;
    outline:1px solid #000;
    font-size:12px;
    padding: 10px;
    height:180px;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

    // You probably want to outsource this to "debug.js" or whatever.
    Debug = {};
 
    Debug.log = function (text) {
        var div = $('#debug');
        div.html(div.html() + text + "<br />");
        $('#debug').scrollTop($('#debug')[0].scrollHeight);
    }
 
    Debug.toggle = function () {
        $('#debug').slideToggle('normal', function() {
            Debug.log('toggled console...');
        });
    }
 
    // That's similiar to what's usually "main()"
    $(document).ready(function() {
        $(window).keyup(function(pEvent) {
            switch(pEvent.keyCode) {
                case 32: //spacebar
                    Debug.toggle();
                default:
                    Debug.log('Key #'+ pEvent.keyCode +' was pressed.');
              }
        });
    });

One important advantage of the Flash Technology (besides it’s platform independency) is the ability to embed media resources into your SWF. If you’ve decided to develop your Flash project using third party IDEs like FDT or Flash Develop, there might be some difficulties to embed resources like images, Flash IDE vector graphics or fonts.

In case of images like JPEG or PNG, fortunately there are some very good loading libraries. These loaders allow you to access external resources during runtime. In most cases this is the recommended technique. But sometimes you absolutely have to deliver a SWF with all or some assets embedded.

For image files there is a very easy way to solve the problem. Here is a sample code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package {
    import flash.display.Sprite;	
 
    public class AssetTest extends Sprite {
        [ Embed(source="embed_this.png") ]
        public static var EmbedThis:Class;
 
        public function AssetTest() {
            var img:Sprite = new Sprite();
            img.addChild(new EmbedThis);
            addChild(img);
        }
    }
}

The magic happens in line 5 and 6. We start by using the Embed metatag to tell the compiler where to pick the image from. In this case we want to embed a file called embed_this.png from the same directory where AssetTest is located at. But caution: If AssetTest is not your main or starter class, you will have to define the path of the source relatively to the main class directory or as absolute path.

This is because the compiler starts with one entry file (the main class) and then climbs up and down the package tree to every class referenced by the imports.

If the main class is located at /Main.as and references to /my_classes/AssetTest.as and you want to load an image from /assets/embed_this.png, the Embed metatag in /my_classes/AssetTest.as has to look like [ Embed(source="../assets/embed_this.png") ]. This ../assets/ means one directory level up and then enter assets.

Line 6 defines a new attribute of type Class. This definition has to be placed right below the Embed metatag. By doing so, the compiler will assign the newly embedded data with the attribute of type Class. So this is why we can create a new instance of EmbedThis at line 10 which results in creating a copy of the embedded image.

The compiler is forced by design to accept, that the embedded data capsuled within EmbedThis is a sprout of DisplayObject. This is why we can add it onto a Sprite to display the image we wanted to load.