OpenGL is a state system which has a state variable called the matrix stack. This is a stack data structure in which each element is a 4×4 matrix. The stack is very useful when rendering a scene in which objects have transformations relative to other objects. For example, when drawing a car:
the car body:
- car matrix transform is pushed onto the stack
- car is drawn
- car body transform popped off
for each tire:
- tire transform pushed on
- tire is drawn
- tire transform popped off
Every time an object is drawn, OpenGL uses the topmost matrix for that object’s transformation. If the car moves, the car’s transform is changed, but since the tires have translations relative to the car and not the scene’s origin, they come along with it. This happens because when pushing on matrices, they are typically multiplied by the one underneath. Therefore the matrices act like reference frames which can be combined together. When a matrix lower in the stack is changed, that is propagated to the matrices on top. Using this system of reference frames, we can accomplish very useful things such as rotating the tires as the car moves, without having to worry about where the car is in the scene. I figured some screenies would be helpful to illustrate the problem. Some collada files are composed of only one node, so the problem isn’t present. In the case of the duck, when the modeler exported this, it was one node, therefore I just represent this with a Model class from the library. But the plane has 2 nodes. Since the propeller will likely be expected to rotate independently from the plane, it was placed in its own node. However since we are currently using the Model() class which does not have its own transform, it results in being placed at the origin. Thus we really need a scenegraph.
Scene graphs can make creating this setup easier as every node in the graph can have a transformation. When rendering is done, the graph is traversed and matrix transformations are pushed and popped off with each node. Scene graphs are very useful structures and are found in collada files. This means for our library to support collada, we need support for both the matrix stack and a scenegraph. The native matrix stack state variable in present in OpenGL ES 1.1, but since 1.1 will eventually be phased out and 2.0 does not have this variable, we need to implement it ourselves. I started working on the stack, but I ran into a problem: If there are multiple canvases per page, should each have its own stack? I spent some time devising a way to have a global array which each element was a matrix stack so every scene can have its own. The solutions I came up with and ones suggested to me were a bit messy, I wanted a simple solution. Eventually Andrew suggested to just use a global for all canvases. I initially didn’t want to do this as I thought firefox’s threads would interfere with the state of the stack. Would the stack be updated by one scene and another scene will try to use it? I did some testing and found this doesn’t seem to be the case so I went ahead and wrote the global functions for manipulating the stack. I like this method as I didn’t want the stack to be tied to the context, which in some cases is necessary.
Speed is always an issue, so I did some primitive testing, how many matrix multiplications could the browser compute? Seems like a hundred in a couple of seconds. But if this needs to be faster, offloading it to the GPU via shaders is one option. Now I just need to beg someone to write a scenegraph in JS.
One aspect of the library which can use improvement is loading Models. Currently, to load a model, one would have export an asset to a .obj format from an authoring tool then run the file through a converter. The converter reads the vertices, normals, etc and writes them out to a .js file. That file simply contains the arrays need to load the model. That file is then imported into an html file as a js resource and the variables from the file are ready to be used. So a model can be created as such:
Var model = new Model();
model.init(sphereVerts, sphereNormals, SphereTex, sphereFaces);
Where the parameters are defined in the file. The problem with this approach is that is introduces possible naming conflicts and is awkward to use as a model has to go through several passes just to get it into a scene. This approach is used because JavaScript can’t directly read files. The tradeoffs of parsing data this way are a bit high and we are now working on loading collada data, a .dae file which is really just xml. The parsing will be slower, but the process of getting a model into a scene will be more intuitive and less work on the user’s side as they will only have to do minimal conversion. If they have an asset in another format, they can convert it. But this is something we pretty much can’t avoid. Even if we decided to use another format, we would have to jam it inside an xml file and that would just be awful. We might as well use a standard that’s not only supported by many authoring tools, but also web-friendly.
When deciding which format to support for model loading, we rejected collada because it appeared unacceptably slow. It turns out it was the script itself and not something in the .dae which was slowing it down. So now our model initialization becomes:
var model = new Model();
model.init(“car.dae”);
Inside the car.dae is a reference to a texture, which the parser will take care of loading and applying to the geometry. It makes creating models easier, but more complicated in the library. The collada file actually contains a scene graph and writing one in JS is a bit intimidating. Nonetheless, it must be done for proper support.
|
|
|
|
To start, here are the features you will find in the 0.5 release of our library:
- Support for text. Done by applying a 2D canvas as a texture to the model
- Texture/model support in both contexts
- many bug fixes and memory usage improvement issues
What all this comes down to is that our library is becoming more and more stable. We are resolving a lot of the technical issues (such as memory usage) and we are adding some very interesting effects and features.
Just before releasing 0.5 of our library we got a chance to meet up with Vlad. Vlad was showing us some of his demos and he had done involving 2D canvas, video, audio, css etc. A lot of it showed demos with a mix of these features. Vlad also showed a few examples he had done with canvas 3D. One in particular had caught our eye. It was a simple model viewer that loaded a Collada file. We did not want to have our own model format for our project. At the time we were worried about the performance of parsing and loading such a file. One of the early demos that loaded kmz files for example took quite a bit of time to load. However, this demo showed how quick it was to load a model from such a format. In our next release we hope to have support for loading models from collada files. This is a pretty big step forward and there are certainly issues that need to be worked out. However, it is an important step and will go a long way into making our library accessible.
