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.