Canvas 3d JS Library

Portable Canvas version 0.2 is available!!

It is now a usable browser, but restricted to pages on c3dl.org only. It can display canvas elements right out of the box, and doesn’t require anything else to be on your system (not even FF3!)*. It’s only been tested on Windows XP, but in theory it should be easy to port to other platforms.

The removal of the URL bar (and the ability to visit sites outside c3dl.org) has been explained by security. The canvas library has direct access to your video card (via Open GL calls). Allowing anyone the ability to create a canvas element, host it somewhere, and link it to you, will potentially allow them to do damage to your video card. However, we can guarantee that any canvas element on c3dl.org will be safe.

The unanswered question I’m left with is, “What happens when you want your canvas application to access a SQL server?” As far as I know, canvas elements can’t (and shouldn’t) hold or run SQL querries; they’d have to be run by a host php page or similar. Will we support these kinds of applications for use with portable canvas? Will we host them on c3dl.org? What if these applications use a technology that isn’t available on c3dl’s web server (such as Iron Python)?

We are in the beginning phases of c3dl development. It makes sense to focus on tools that develop canvas elements. But, while changes are still easy to make, we should consider how canvas 3d might be combined with other technologies for complex applications further down the road. (There’s probably an article on this topic that I should’ve read by now, and that I can hang my head in shame for not knowing about…)

The discussion page for this can be found at: http://zenit.senecac.on.ca/wiki/index.php/Canvas3D_XUL_Runner_App_0.2

For convenience, you can download portable canvas 0.2 from here.

* I lie. You will need an Internet connection.

As our library expands with more functions, classes and global variables, the need for namespacing increases.  I started placing code in a C3DL namespace when I wrote the matrix stack operations.  However, yesterday I was looking in the constants.js file and saw the ‘tolerance’ variable.  It’s a const variable used when comparing floats to check if they are close enough to be considered equal.  Tolerance is global which allows us to easily use it wherever necessary. However, it is likely that users will have their own variable named ‘tolerance’, so it makes sense to just pack our tolerance into the C3DL namespace. This is where the problem started. I couldn’t find the syntax to properly create a const within a namespace.  Hopefully I’m wrong and there is a way to do this, but from what it looks like I’m left with few alternatives.

I could remove the constness from the variable and then I would be able to place it in the C3DL namespace.  It would be up to us to make sure our library does not assign new values to variables which should stay constant such as ‘tolerance’, ‘far_clipping_plane’, ‘near_clipping_plane’, etc. Although if users start using our globals for their own needs, they may assume we made sure it is const and users can end up accidentally overriding it, possibly creating bugs.

We could also just ditch the javascript ‘namespacing’ idea and place C3DL_ in front of everything. That way our variables can stay constant and be unique.  The problem I have with this is that if used with functions, C3DL_popMatrix() is just too awkward.

Last idea I have is to use a hybrid naming system: place all our functions in the C3DL namespace but prepend symbolic constants with C3DL_.  This will allow us to keep the variables constant and unique by name as well as keep the functions unique by namespace.  The only problem I have with this is there is a slight inconsistency, but will users mind?  If we decide to use this method, our function calls will look something like C3DL.popMatrix() and constants would be C3DL_TOLERANCE.  I’m open to suggestions on other ways to fix this issue.

We have code which parses collada/DAE files, but to a limited degree. The parser only extracts the geometry data. Therefore if a file is ‘simple’, it loads correctly since the scene graph has only one transform node. However if the collada file contains many transform nodes, each node with different geometry will be placed at the origin. This happens because we currently don’t have a scene graph which the transform nodes should be placed inside. I have started working on a scene graph and realized some of my earlier code must be reworked.

some general requirements:

• Collada files must only be parsed once. Once the file is parsed there’s no reason it should be parsed again. Parsing is already slower than having the js arrays already defined, so it should be kept to the absolute minimum. We will know which files are parsed based on the path users provide, such as “models/plane.dae” or “dragon.dae”. It will be up to the user to prevent scenarios such as loading “models/plane.dae” and then loading “plane.dae” where both files are duplicates. In this case our checks will fail and the file will be parsed and loaded twice in memory.
• Once a collada file is parsed, it will reside in a table as a scene graph uniquely identifiable by a pathname.
• Loading models from collada files must be at least as easy as loading from JS arrays.

The implementation will resemble:

var plane = new Collada();
plane.init(“models/plane.dae”);

var plane2 = new Collada();
plane2.init(“models/plane.dae”);

It is likely that collada files will structure geometry using the scene graph, however users will probably not care. If they have a plane and want it to give it a linear velocity, they should not have to deal with the scene graph, so the following should be valid:

plane2.setLinearVel(makeVector(0,0,1));

This will be interpreted as giving the root node of the scene graph the linear velocity, so all the objects attached to the plane will move. If the user wants to rotate the plane’s propeller, they will have to deal with the scene graph since the propeller’s transform node is a child of the plane’s transform node.

// collada objects will have a scenegraph
var planesg = plane.getSceneGraph();

// all node’s will have a findNode() which will return the
// first node which matches the string specified by the user.
var propeller = planesg.getRoot().findNode(“propeller”).
propeller.setAngularVel(makeVector(0,0,0.001));

The issue with this is that the user must know the name of the node, but if they are doing things like moving the nodes in the graph, they would have to know at least that much.

The main issue I have implementing the scene graph is using inheritance, not surprisingly . I wanted to place simple methods like get/SetName() into an ‘abstract’ BranchNode class and have TransformNode and GeometryNode inherit it. The angular velocity transformations seemed to work when there was only one TransformNode with one GeometryNode, but when I created two TransformNodes, I had a some sort of infinite recursion as the browser got really busy and nothing was rendered. The TransformNode was supposed to push its matrix on the matrix stack and then call the base class (BranchNode) render(), but then the BranchNode just called transformNode’s render(). Without inheritance everything seems okay, until I resolve this I will have to go on without it.

First some background:
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.