Writing WebCL demos can be difficult as while we are waiting for the Khronos specifications, getting code to run the same way on every implementations (meaning : Nokia, Samsung, Mozilla-Central, Motorola …) can be truly difficult.

However, while the standard is not finished yet, the working draft is publicly available and even if it means that it will certainly change from time to time, this is a good point to start while searching for a common API.

Introducing CommonWebCL

CommonWebCL is a javascript library that aims at providing a common API for every WebCL implementations. It also include some tests, providing an easy way to know if a special feature is available with the implementation you are currently using.

This is a work in progress, and the current release acts more like a prototype than a truly usable library. But it should become a useful library soon, allowing you to develop your demonstration without taking care of the implementation you are using and its evolution (of course you would still have to upgrade CommonWebCL).

As always, if you would like to contribute to this project, you’re welcome ! It is certainly not entertaining to do, but is might be useful while WebCL is still being specified by Khronos !

You can find more information on the Github repository.

TypeCheck.js is a small library that allows doing simple types checking in Javascript at runtime.

Objective

The main objective of this library is to ease the debug process of JavaScript, especially when working with complex projects where you can have a lot of different type signatures working for a single function.

It is meant to be as easy to use as possible, and to not have a performance hit when running in Release.

Example

This example throws exceptions if the first argument is not a number OR if the second is not a string, or if the third argument does not have the same constructor than T or U :

var test = TypeCheck._(
    [TypeCheck.Number, TypeCheck.String, [T, U]],
    function(myNumber, myString, myObject){
        console.log(myNumber, myString, myObject);
    }
);

Here are execution examples :

test(5, 8, new T()); // Exception thrown : Bad type received for argument 2.
var V = function(){};
V.prototype = new U();
test(5, 8, new V()); // No exception thrown

The library also manages the number of arguments (fixed or variable) and in function type-checking.

Sources

You can find sources, documentation and examples on the Github repository.

This week, Adrien Plagnol and I made a lecture about WebCL at LyonJS, a monthly event where people talk about Javascript bleeding-edge stuffs.

On this occasion, I wrote a new demonstration for WebCL implementation in Firefox. It is based on the first one, but with a lot of improvements. And a less stupid name.

What’s new

• Use Fullscreen API
• Better rendering of spheres (improved basic light management)
• Better rendering of particles (getting white as the velocity increase)
• Attractors = Sphere with attraction force
• Repulsors = Sphere with repulsion force
• New UI (not difficult as the previous version had no buttons)
• Ability to disable Earth-like gravity
• Open and save scenes using local storage
• Share scenes (based on JSON serialization)

Videos

This other video shows more complicated scenes than the first one :

Sources

Sources are available on Github.

I worked on this project when I was in my fourth grade. During that year, we had to work on a tutored project which had to be innovative in some way.

The project I chose was the development of a Google Earth-like (but lighter) using web bleeding-edge technologies. It had to take in account at least one protocol used in the GIS world and to run on mobile devices.

Principle

Webnav3D is a Javascript web application. It uses WebGL for rendering and WMS as protocol to get the bitmap tiles to render.

As we wanted it to run on mobile devices, we chose to avoid Javascript processing when it was not necessary. To do that, we based our works on two principles :

• If the processing is on the content of a tile, it had to be done on the GIS server and pre-cached. That way we got rid of resolution and tile size problem, as they were computed and stored on the server. Moreover, we chose to render heights using heightmaps and based on elevation data that were stored on the server; that way this one was able to automatically compute heightmaps corresponding to given tiles.
• If the processing was about the rendering of the scene, it had to be done in GLSL shaders. That’s why Javascript did not even read files containing tiles or heightmaps. His role there was just to transfer those textures to the graphic card, and to produce vertice VBO containing a regular grid of a certain size, with Z equals to 0. Shaders then processed the heightmap textures to find out the elevation of each vertex.

This project is now part of OpenScalesGL.

Videos

Desktop version

Mobile version

This demonstration was written thanks to a friend of mine who worked on the WebCL implementation in Firefox.

It is a fancy physic playground where you can put balls on which particles will bounce.

You can find the sources and more informations on the blog my friend and I maint ened during this project : Parapluie::GFX.