Canvas 3d JS Library

WebGL made easy!
  • rss
  • What is C3DL?
  • Download
  • Tutorials
    • Tutorial #1: WebGL Browsers
    • Tutorial #2: A simple scene
    • Tutorial #3: Callback
    • Tutorial #4: Models
    • Tutorial #5: Light effects
    • Tutorial #6: Picking
    • Tutorial #7: Materials
    • Tutorial #8: Particle Systems
    • Tutorial #9: Camera Basics
    • Tutorial #10: Advanced FreeCamera
    • Tutorial #11: OrbitCamera
    • Tutorial #12: Advanced Camera Functions
  • Development News
  • Documentation
  • Community
  • Resources
  • Contact
  • About
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.
duck
collada plane


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.

Last week I posted our 0.5 release of our library. I’m very excited as I’m now seeing a lot of all our little efforts finally taking hold in a real way. Other developments recently have also shown where our library will go in the future and the features we intend to add.

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.

Videos

Demos

  • Asteroids-3D
  • RTS Prototype
  • Particle Systems Demo
  • Cross-Browser Orbiter
  • Mocap Demo With Spheres
  • Google Maps-3D

C3DL Development News

A spec change that keeps coming back to haunt me

At some point, the way firefox handles keyboard events changed. I’m not sure exactly when it happened, all I know is that it broke how I was dealing with keyboard interaction on almost every demo I’ve written (for example,the mocap demo and MotionView). When I wrote the demos, the keydown event would be fired once, [...]

Release 2.2

The 2.2 Release of the Canvas 3D Library includes a number of new features, updates to old features and fixes for several bugs along with the requisite changes to meet the evolving WebGL spec. Some of the things included (in no particular order) are: Better picking code. The ability to swap textures as a scene [...]

Tutorials

  • Tutorial #1: WebGL Browsers
  • Tutorial #2: A simple scene
  • Tutorial #3: Callback
  • Tutorial #4: Models
  • Tutorial #5: Light effects
  • Tutorial #6: Picking
  • Tutorial #7: Materials
  • Tutorial #8: Particle Systems
  • Tutorial #9: Camera Basics
    • Tutorial9-YawPitchRoll
  • Tutorial #10: Advanced FreeCamera
  • Tutorial #11: OrbitCamera
  • Tutorial #12: Advanced Camera Functions

Documentation

Archives

Archives

C3DL Development News

Recent Comments

  • June 2011
  • March 2011
  • October 2010
  • July 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • A spec change that keeps coming back to haunt me
  • Release 2.2
  • 2.1 Release and things to come
  • Level Up! An Open Web Game Jam
  • Site moved!
  • SceneCreator0.3
  • WWW2010 in Raleigh
  • Motionview
  • On the train to Mountainview
  • C3DL 2.0-WebGL and beyond
  • That depends on what... - peter
  • This application is ... - Haisens
  • I think that example... - peter
  • The above links are ... - Atash
  • Hi there, just wante... - Patrick H. Lauke
  • Firefox 4 was releas... - Cathy Leung
  • In order to access l... - peter
  • I am not able to dis... - preksha
  • "JavaScript can’t di... - Joe Hocking
  • I should point out t... - peter



Canvas 3d JS Library

©2007- 2010 Canvas 3d JS Library

Disclaimer: This website is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Canada License.
The Canvas 3d JS Library and Demos found on this website are licenced under the MIT License

Creative Commons License