Besides HTML5 and CSS3, WebGL is one of the most promising evolving technologies for Internet webpages. From simple model viewers to complex scenes, OpenGL ES driven webpages together with CSS3 and video textures may become the next generation. For widespread usage, creating rich WebGL applications must be easy to setup, rendering with small response times and a good scalability. These are some crucial requirements for those APIs that wish to evolve.
At the time of writing, while some frameworks are more promising than others, none of them are perfect, yet. Working hard on improving these APIs is a keystone for WebGL’s popularity.
This post compares some WebGL APIs concerning software engineering quality, naming convention, features and drawbacks. It does not evaluate performance and efficiency implementations, being done in another upcoming post.
All authors of each API covered in this post series put a lot of efforts and work into their software, some of which are already quite good with great examples. I believe that showing drawbacks and problems of software engineering design hopefully results in improved APIs and thus in increased future popularity of such APIs. Thus this post is more critical.
- Part 1: C3DL, Curve3D and CubicVR 3D
- Part 2: Copperlicht and GLGE
- Part 3: KUDA, O3D and OSG.JS
- Part 4: PhiloGL, Scene.JS and SpiderGL
- Part 5: TDL, Three.JS and X3DOM
Although the number of WebGL frameworks is incredibly growing, some of them are already at the end of their life circle. While none of the compared WebGL frameworks are perfect, some libraries offer features others don’t.
All APIs have some problems with naming conventions and software engineering principles, some more and others less. TDL uses an old fashioned naming convention, but has a very efficient implementation. X3DOM strongly follows the X3D specification for web 3D content and is already a promising library, but most of its classes and modules are merely basic implementations of the specification. CubicVR 3D allows setup with only few lines of source code and is one of the best frameworks currently available – it also has a C++ counterpart. OSG.JS hierarchically organizes scene models and their transformations. PhiloGL has interesting performance ideas (but also questionable) with still only basic/standard WebGL support. O3D has some examples too, but they are included in the source browser only and cannot be viewed in the browser directly (it has dated naming conventions). KUDA tends to be more like a model/scene viewer and editor than a low-level WebGL framework. SceneJS lists a lot of examples, but unfortunately only beta versions can be downloaded from its homepage (scenejs.org).
While most APIs support meshes, models, camera, lighting and one renderer, only a few implement more advanced features like animation, physics, quadtrees, subdivision surfaces, audio, video textures, spline curves, networking and shaders – and none of them does it very well, yet.
So there still remains a lot of work to be done. Virtually merging some projects together would certainly result in the best framework of all: high performance, rich features, good usability, tutorials, documentations.