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 is running.
  • The ability to texture an object with video files and canvas tags.
  • More information about objects, such as the number of triangles, the size of the object (and the ability to scale it to a particular size) and the ability to center an object.
  • Primitive objects such as cubes, planes and spheres.
  • Upgraded collision detection.
  • The ability to pause/stop/start the scene (rendering and updating).
  • The ability to label an object in the scene as static, so time won’t be wasted trying to calculate the movements of an object that does not move.
  • Using RequestAnimationFrame so as not to waste time rendering a page that isn’t visible.
  • Frustrum culling.
  • General improvements to the performance of the library.

We have a number of other changes coming, along with new tutorials and demos planned. And as always, you can request new features and/or report bugs through our lighthouse account

It has been a long time coming but we have now updated all the core features of C3DL to use WebGL. You can dowload our 2.0 release here. We have also updated all our demos to use WebGL. Our tutorials have all been updated (tutorial 5 and 6 needs a better example but we’re getting to it). Our documentation has also been updated for release 2.0

C3DL 2.0 includes the following features:
  • uses WebGL (as opposed to Canvas 3D) – you will need a WebGL enabled browser to see demos (see tutorial #1 on how to do this)
  • ports all c3dl features including:
    • Collada model loading
    • Picking
    • Lighting System
    • camera system
    • Particle system
    • Effects system that allows a swappable shader to be applied to alter its look. Currently we have the following effects implements:
      • cartoon (with or without outlines)
      • greyscale
      • solid colour
      • sepia
      • gooch
  • lines and dots
Many of these features can be observed in our Asteroids-3D demo. (click on rocks to fire at them). We have also moved our repository onto github and a bug tracker at lighthouse. Try it out and give us some feedback! :D If you are looking for our Canvas 3D related demos please check our Archive link.

I finally have our library working properly on Firefox (Gecko/20100114 Minefield/3.7a1pre), Safari (Version 4.0.4 (5531.21.10, r53178)) and Chrome (Chromium 4.0.299.0 (36242))

I’ve updated the orbiter demo with the new code, and will shortly be updating some of the older demos. There are still a few minor issues to deal with, such as the moon not showing up properly sometimes, but we’re not getting exceptions anymore.

Another of these issues (Chrome only) has to do with reading floating point values from collada files. When we try to use the values, it throws an exception, but if I multiply the values by 1 before we use them, it works. I’ll have to spend a little more time trying to figure out if this is caused by something I’m doing wrong, or if it might be a bug.

I now have a proof-of-concept working that demonstrates that our library will work for multiple browsers. We had been having a problem where Safari doesn’t support the keyword const, so I took those out. Then I found out that someone who had worked on the library before me had been using ‘let’ to create variables. This wasn’t a problem when we where only on Firefox, but other browsers don’t support it, so I had to find all the lets and convert them to vars. Then I had to find all the spots where we used Canvas…Array and switch them to WebGL…Array, but only when running Safari (borrowing a bit of code from the lessons at LearningWebGL made that much simpler).



Screen shot
Cross-Browser Orbiter Demo

With all that done, we finally have the library working for both browsers (I’ll get to Chrome soon, I promise…), but there’s a fairly serious problem. Our library works by putting a link in the header telling the page to include a js file (c3dapi.js to be precise), which then has some JavaScript code that adds more script tags linking to js files (the actual library) to the DOM. This works fine on Firefox, but Safari doesn’t like it. It knows the files are there (I got it to list all the script tags and they’re there and in the correct order), but it doesn’t actually read them. I’ve temporarily fixed this problem by manually adding all the script tags to the html page, but this is ridiculous to have to do every time.

On Firefox we just put

<script type="application/javascript" src="../../canvas3dapi/c3dapi.js" ></script>

and the beginning of c3dapi.js looks like this
var scripts = document.getElementsByTagName("script");
var parts = scripts[scripts.length -1].src.split("/");
parts.pop();
var basePath = parts.join("/");
var head = document.getElementsByTagName("head")[0];

c3dl_require = function(path) {
    var includeResource=document.createElement('script');
    includeResource.setAttribute('type',"text/javascript;version=1.8");
    includeResource.setAttribute('src',basePath + "/" + path);
    var scripts = document.getElementsByTagName("script");
    head.insertBefore(includeResource,scripts[scripts.length]);
	
}

c3dl_require('c3dlnamespace.js');
c3dl_require('constants.js');
c3dl_require('effects/effect_docs.js');

For Safari that doesn’t work, so we’ve had to put all those script tags into the page header manually, which looks like this:
<script type="application/javascript" src="../../canvas3dapi/c3dlnamespace.js" ></script>
<script type="application/javascript" src="../../canvas3dapi/constants.js" ></script>
<script type="application/javascript" src="../../canvas3dapi/effects/effect_docs.js" ></script>
with about 50 more script tags.

In short, we’ve got a demo that works for both Firefox and Safari, but it only works because of a temporary fix. Fixing it permanently is the next thing on my to-do list. I should also mention there is a known issue: The moon is not being lit in Safari. After I sort out this issue with including files, I’ll investigate that too.

Some time ago we had a demo that would give a 3D representation of routes obtained from the Google maps api, along with some points of interest the user could search for (like coffee shops). While the library keeps getting updated, this demo did not, and no longer worked on systems running recent versions of the library. This was unfortunate as the demo showed some neat applications for C3DL, so we decided to resurrect it.

Having never seen the original working, I had a difficult decision to make. Do I update the existing code to work with the newer versions of the library? Or do I write a new demo from scratch? In theory the update should have been the easier route, but it was using code that had been rendered obsolete before I joined this project. Instead of learning an outdated version of the library to update one demo, I kept only the basis of the code (mostly the interaction with the Google Maps API), and wrote most of the rest. As the demo progressed we had several ideas about things to be improved or added. For example, each of those points of interest gets a little 3D model (a tetrahedron for now) to show where it is, but we realized it would be better if the user could click on that point of interest and find out what it is, what the address is etc., so now you get a pop-up with the name, address and phone-number of the point.

Without further ado, here’s a picture of (and link to) the demo:

mapsInAction

I did have to limit the number of roads that are visible at one time, and only show points of interest that are close by, just to reduce the strain on the system (A trip from Toronto to Vancouver involves a lot of roads and an extraordinary number of coffee shops).

There are a few things that I’d like to improve on when the opportunity presents itself, or would be happy to see other people try.

  • This uses an old version of Google’s API. It would be nice to bring it up to version 3.
  • The overhead compass would look nicer if it was partially transparent (So you could see the letters indicating the directions, but not the rectangle they sit on). While this concept is supported by OpenGL and the png format, support for it isn’t in the library yet.
  • The tetrahedron’s that indicate points of interest work, but a better model would make the demo look nicer.
  • A road model that was more than just a flat rectangle could make the demo look nicer too.
  • When you click on a point of interest, it causes a pop-up with information about that location, instead it would be nice to have that information appear as floating text in the canvas, so it doesn’t interrupt the demo.
  • It would also be nice to get elevation data, but the Google Maps API doesn’t provide it, so it would have to come from somewhere else. Then we could make the roads go up and down with the elevation instead of assuming the world is perfectly flat. That would require a little extra code to accommodate the new data, but most of the hard calculations are already done.
  • The overhead compass often misses getting drawn when the page first loads, but will show up on a refresh. This is peculiar as the code is supposed to wait until all models are loaded before it actually starts.