Playing with JavaScript - Three.js & Physijs

Web technologies are hot. Everyone is speaking about HTML5 even without a clear definition what HTML5 is. This especially after the latest announcement from WHATWG  and W3C and them driving to different directions.
So lately I have been also playing around with couple of JavaScript libraries, especially with the ones touching the areas of Graphics and Physics.

Getting started dead easy. This especially if selecting Three.js as your 3D library and Physijs as your physics lib. Three.js is an 3D library for dummies, abstracting things like camera, scene, materials, etc. and also includes features like shadow mapping through an simple definition. It also allows you to select which technology you want to use for rendering your scene. But most importantly it includes some really nice examples and its example folder is really a treasury.
Physijs is an plugin to this library to provide some basic physics - built on top of ammo.js which is a direct port of Bullet physics engine.


As starers, I was using these two libraries to build an simple application where you have cubes dropping to an heightmap and bouncing from there. Problem with this was the physics which didn't react correctly to my heightmap. Nicely enough Physijs it self just fixed this problem by introducing HeightfieldMesh which allowed physics to be interpreted correctly with  my simple heightmap (vs. PlaneMesh that I was originally using).

Anyway nothing special, just testing what you can do with these libraries. At this time attaching only an image of this demo appl as the performance with my example is _really_ bad (when calculating the physics for cubes hitting the heightmap, its only ~2fps).  Live demo, including sources from here.

Standards, agreenments and fragmentation

The graphics area can be seen through your OpenSource "standards" and industry _standards_. Even when discussion only about Linux and not even going to the Microsoft land the field is starting to be a quite messy.

The fragmentation in open source side is in many areas caused by the fact that the communities are competing with each other. They want to ensure that they can bring out as good as possible SW as soon as possibly - naturally. What this causes is that instead of making an effort and developing something together we fragment. Good examples of this is your TTM vs. GEM, classic Mesa vs. Mesa Gallium state tracker or EXA/XAA/UXA.

Then we have our industry standards by Khronos. What Khronos defines is an open standard mainly for Graphics and Media. We have the defacto OpenGL/ES and the counterparts GLX and EGL and then we have something else. We have things like OpenWF (display and Composition) which in OSS world is know as KMS (with limited composition support), OpenKODE with the OSS counterpart being SDL and OpenMAX which in OSS world is tackled with VAAPI or XvMC or VDPAU. Well you get the point.

So why should we care about this? What this all means is that the set of selection when developing an Linux based system - following the industry standards or selection one of the Open Source paths. Often the proprietary drivers do follow the industry standards but they have not adopted any of the OSS ways of providing the functionality and why would they as the OSS "standards" are often vendor specific. This will mean that reasonable way to build our platform would be the industry standards but then you would loose the possibility to try out the new nice things which are not executable in these platforms. Difficult choice and ideally a choice that we wouldn't need to do.