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.
Content
- 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
Conclusion
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.
Pingback: WebGL around the net, 17 May 2012 | Learning WebGL
What do you think of Inka3D? It’s not really a framework like the others because it’s a Maya export plugin. But its strengths are animation, shaders and performance.
1. What do you mean with “compiler based approach” in http://www.inka3d.com/llvm2011/#pipeline ? Strictly speaking, compilation means (automatic) translation of human-readable source code into machine executable instructions. Note the difference to interpreter which parse a human-readable source code on the fly (but they don’t compile). In this sense, I don’t see why you compile C++ code into JS or GLSL code, both of which are source code (see assemblers). For example, OpenGL uses your GPU drivers to translate GLSL source code into hardware instructions specifically designed for the targeted GPU. I admit it’s just a subtle point, but it would make things more clearer for others.
2. Is it really necessary to generate C++ code, while targeting JS and GLSL?
3. The presentation slides should be more responsive. I suggest you either generate a PDF file with embedded pictures and videos, and/or provide HTML versions.
4. Some tutorials and documentations would be helpful, i.e. more explanations.
1. Wikipedia: A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, often having a binary form known as object code). So with compiler based approach I mean the translation from C++ (source language) to GLSL and Javascript (target languages). To answer the question of why I do it is that generating C++ from the Maya scene is easier as a first step than generating different other languages. Also the target independent optimizations of LLVM can be used before generating GLSL and Javascript. There are other technical reasons like the Maya shading networks which have to be split up into multiple parts (Javascript, vertex and pixel shader) which is done when the code is in LLVM intermediate code form.
2. Other approaches will certainly do but C++ fullfills my requirements (I only use a subset of C++) and a C++ to LLVM compiler is already around (clang).
3. What do you mean by more responsive? Is the frame rate too low because of the embedded WebGL?
4. A tutorial is already there (http://www.inka3d.com/tutorial/index.html), an api description will be online soon. But the api is very small as you can create scenes as black boxes and then access the attributes using strings containing the Maya attribute names. For example you can change the color of a scene which has the attribute name “phong1.color” and is a Float32Array of length 3.
What about statistics, like the count of framework usages around the web?
That’s not an easy task. How do you want to count framework usages?
Great article for our webgl newbies. What do you think about Oak3D (another framework)?