SpiderGL
Marco Di Benedetto
February 2010

WebGL is a binding between JavaScript and OpenGL, what is the role of SpiderGL?

The WebGL API reflects closely the philosophy of its underlying layer, OpenGL|ES 2.0, that is, it should be a minimal, low level, yet powerful and perfomant graphics library. In this context, SpiderGL offers a higher level of abstraction upon WebGL to ease its use in general scenarios, without imposing any specific programming paradigm nor retaining, under any circumstance, direct access to the WebGL API.
Moreover, SpiderGL is not only an interface towards WebGL, but it also offers a wide range of typical computer graphics tools.

WebGL is a standard promoted by the Khronos Group, the same people who, some years ago, promoted the OpenGL|ES API, which is now basically supported by every smart embedded device. Concurrently, in recent years we have seen how people expect web content to be in touch with standard desktop applications. The introduction of a platform independent, plug-in free, ready-to-go 3D API is surely something that finally had to come. With WebGL, developers don't even have the burden of recompiling their code for different platforms, it's just ready for millions and millions of desktop and mobile users through their web browsers.
SpiderGL is intended to fill the gap between web developers which are more and more interested in learning 3D graphics and experienced Computer Graphics developers.

Every developer wants to implement their ideas in a fast way, and those who are pretty familiar with the subject also wants full control over the nitty-gritty details. Whenever we approach an existing software component, we would like to reuse as much as possible of our former knowledge on the subject, namely our already implemented data structures and algorithms. On the contrary, we often see how external libraries expect us to comply with some specific paradigm or data representation. That's exactly the main reason that force us, in many cases, to work on tedious translation layers, which also impact on performances.
This is a key point: SpiderGL must comply with your habits, not the contrary, you should be able to integrate it into your existing code with little or no effort. As an example, I don't want to change my shader source code or mesh definition to match the predefined names or structure a certain library would expect. Rather, I want a easy mechanism to have them automatically matched. For these and for a number of other reasons we did not take a scene graph-like approach but rather preferred a procedural one. The naming and coding conventions used throughout SpiderGL reflect what a JavaScript developerwould expect. At the same time, OpenGL users would find that the library does not introduce unnecessary abstractions but rather gives them a compact and easy-to-handle representation of well-known concepts. In addition, I'd like to remark that SpiderGL does not only offer WebGL facilities, but also provides several 3D graphics and more general programming features, ranging from linear algebra to visibility culling, to asynchronous content loading.

Content formatting (geometry, images, shader effects code and such) has been carefully kept away from OpenGL-class graphics libraries, due to their application-specific nature.
SpiderGL already supports the Alias|Wavefront OBJ format, and we are thinking about a Collada importer.
As SpiderGL handles meshes as raw containers of vertex attributes and array or indexed topology, we are also developing facilities to directly work with a JSON-based object description.
It is likely that the library will, in the future, support a higher level scene description format like X3D.

In the last years there was a turning point in realtime 3D Graphics applications, that is, more and more processing has been redirected from the CPU to the GPU.
By consequence, during the graphics rendering phase, the principal role of the CPU side of the application became that of an "orchestrator", issuing commands to the GPU and asking it to combine them in the final image. Of course, I am far from saying that you can reach the quality and performances of current C++ software (being a game composed of a lot of modules, not only graphics), but I am expecting that the overhead introduced by the JavsScript language would be mostly mitigated by moving the processing to the GPU, resulting in an overall enjoyable experience. As a side note, we used SpiderGL to implement a rather complex multiresolution viewerbased on ray-casting and implementing the BlockMap concept.