Canvas 3d JS Library

C3DL 2.0-WebGL and beyond

Cathy Leung — Mon, 22 Feb 2010 05:59:12 +0000

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! If you are looking for our Canvas 3D related demos please check our Archive link.

Preliminary WebGL RTS Game

Andor Salga — Mon, 15 Feb 2010 22:08:08 +0000

Cathy asked me to make a cool demo using our library. After thinking about, I started getting many ideas, but creating a preliminary real-time strategy game made the most sense. It not only demonstrates a lot of C3DL features such as model loading, transformations, lighting, shaders, picking, cameras, textures, etc, but since animation is kept to a minimum, the frame rate on slower machines shouldn’t be a big deal.

You’ll need a WebGL-compatible browser to run it. You can either download Minefield, WebKit or Chromium. Please let us know if it fails to load. Keep in mind I hacked this thing together in a day so the code isn’t pretty, but here it is anyway!

Asteroids in 3D… and a bit of 2D

Cathy Leung — Mon, 01 Feb 2010 11:12:55 +0000

So I’ve been working on this little demo in preparation for the upcoming (very very soon…docs left only) release of C3DL’s webGL release. I adapted it from Peter Callaghan’s Asteroids game and the models were from an old demo made as part of our user testing last year. This demo is kind of cool because it demonstrates many of the features of C3DL and puts it all together in one. Namely it uses:

collada model loading – you can export to collada from a good number of modeling programs including blender, 3ds max and google sketchup
particle systems – watch the rocks when they explode!
lighting – ok… this is not featured well… I’ll try to see if I can do better with it
picking – click on rock to identify which one

I will probably add something to that uses the effects system as that is one key component not highlighted. Its not quite done yet but I figured I’d link it anyways since I won’t have time to finish it till probably Wednesday…. I still have to add scoring and end game functionalities, the keys should be changed to a and d instead of using arrows, and I think my health bar is messed up when it drops below 25 but… its a start. I also have not tested well on webkit (there was a bug of constantly rotating ship at one point but have not been able to reproduce it) and I can’t seem to run chrome on my desktop atm so no testing there. This demo uses webGL in the main display and I painted the hud with 2D canvas. Click on the asteroids to shoot them. Use arrow keys to rotate the ship. https://cs.senecac.on.ca/~catherine.leung/c3dl/Asteroids3/asteroids.html NOTE: To see this demo you need a web browser that supports webGL and it must be enabled.

Another demo updated

peter — Thu, 28 Jan 2010 21:25:35 +0000

I’ve just finished updating the particle systems demo. There wasn’t anything wrong with the demo itself, but there was an array in the particle system class that wasn’t being initialized properly that suddenly started causing Minefield to crash. The strange thing is that until recently Minefield wasn’t complaining about it. But as of the nightly build on the 23rd it didn’t just complain, it outright crashed. By populating the array with 0s when it is initialized, I’ve got particles working again. The misleading problem was that this happened at the same time I was fixing an issue with colours for Chromium was preventing it from displaying. It started crashing one browser at the same time I fixed a problem for another. It turns out that was caused because colour values were being read out of a file and split into an array, but they were never explicitly made into floating point values. Minefield and Webkit understood them as such anyway, but Chromium didn’t like that. A temporary solution was to multiply the values by 1 before using them, but that isn’t a very good solution. Once I actually traced the problem to its source, a quick parseFloat took care of it. Slightly slower, but more correct.

Simplifying the Interface

Andor Salga — Sat, 23 Jan 2010 22:37:24 +0000

Something we need to do is simplify the C3DL library interface. When approaching such tasks, one method I found extremely useful was to analyze the code in terms of the interface, or that is from the user’s perspective. To do this I first created a basic demo of a spinning cube by writing the necessary HTML and JavaScript files. As for the HTML, it will need to be something like this:
(I emphasized the code which potentially could be changed)



  
    Cavas3D Demo

It would be great if this could be simplified to something like this:



  
    Cavas3D Demo

I removed the somewhat unintuitive SCRIPT_PATH variable and moved the basic_demo.js resource into the canvas tag making it more obvious which .js file is associated to which canvas. These changes haven’t actually been made, I’m just playing with possible changes, brainstorming which parts might be able to be modified.

Now, very few changes were made here and it will probably require a significant amount of effort to make it work. But this work is justified by the fact that the user’s experience and first impression will be more positive. If the user has to spend more than a few minutes trying to get a simple example to render, they’ll probably look for alternatives.

Let’s see how the JavaScript could be changed. Right now, you need to write something like this:
(Again, I emphasized the code which potentially could be changed)

c3dl.addModel('cube.dae');
c3dl.addMainCallBack(mainDemo, 'demo');

function mainDemo(canvasName)
{
  var scn = new c3dl.Scene();		
  scn.setCanvasTag(canvasName);
  var renderer = new c3dl.OpenGLES20();
  scn.setRenderer(renderer);
  scn.init();
  
  var cam = new c3dl.FreeCamera();
  cam.setPosition([0,0,50]);
  cam.setLookAtPoint([0,0,-1]);

  var cube = new c3dl.Collada();
  cube.init('cube.dae');
  cube.setAngularVel([0.001,0.001,0.0]);

  scn.addObjectToScene(cube);
  scn.setCamera(cam);
  scn.startScene();
}

Some changes I had in mind involved getting rid of the global c3dl.addModel() and c3dl.addMainCallback() calls and changing OpenGLES20 to just Renderer. The Renderer is an interesting problem. When WebGL started out as Canvas3D, we called the renderer OpenGLES11, then later it became OpenGLES20 and now it could probably be WebGL. Considering how much it has changed and will change, we’ll have to invest some time to make this stop. One simple solution is to abstract the renderer.

For example, if we change OpenGLES20 class to Renderer, the user will no longer need to be concerned what underlying rendering method is used. If a visitor loads the user’s demo, but visitor’s browser doesn’t support WebGL (i.e. it’s I.E.), the demo still loads. This of course only works if we accommodate for this case. So if the browser is IE, we use DirectX. If the browser supports WebGL, we use that. The end result is the user’s page will create the appropriate renderer without them needing to worry about the user’s browser. So let’s look at what lines changed:

function mainDemo(canvasName)
{
  var scn = new c3dl.Scene();
  var renderer = new c3dl.Renderer();
  scn.init(renderer);
  
  var cam = new c3dl.FreeCamera();
  cam.setPosition([0,0,50]);
  cam.setLookAtPoint([0,0,-1]);

  var cube = new c3dl.Collada();
  cube.init('cube.dae');
  cube.setAngularVel([0.001,0.001,0.001]);

  scn.addObjectToScene(cube);  
  scn.setCamera(cam);
  scn.startScene();
}

In terms of the lines trimmed, I’m not certain how much of it is viable. The reason some of the seemingly redundant code is required was because I couldn’t devise any alternative at the time. Looking at it from a different perspective, I should be able to come up with something. In the end we’ll have an interface which is more flexible, easier to understand and of course simple.

Updating Demos

peter — Tue, 19 Jan 2010 15:40:09 +0000

I’m continuing to update the demos with the copy of the library that works cross-browser (and will continue to do so). There was a slight delay in the motion capture demo due to the difference in how the browsers read xml files. We had been using:

xmlDoc = document.implementation.createDocument("","",null);
xmlDoc.async = false;
xmlDoc.load(xmlFile);

but Safari and Chrome don’t accept that. After a quick search (ignoring the pages that make it sound more complicated than it is and want to sell you code to take care of it) I found the answer to be quite simple.

xmlDoc = document.implementation.createDocument("","",null);
xmlDoc.async = false;
var xmlReq = new XMLHttpRequest();
xmlReq.open("GET", xmlFile, false);
xmlReq.send(null);
xmlDoc=xmlReq.responseXML;

It ends up as a few extra lines, but it works for all three. This was a problem with the code for that individual page, but it seems to be the kind of thing we can expect when trying to write complex code for multiple browsers.

I’ll be working on the particle systems demo next, as it also has a bit of code that is firefox only.

Cross-browser progress update

peter — Fri, 15 Jan 2010 18:28:33 +0000

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.

let there be vars

peter — Mon, 07 Dec 2009 15:30:45 +0000

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).

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

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:

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.

Creating tester pages

Cathy Leung — Sun, 29 Nov 2009 22:19:10 +0000

Recently there has been a lot more interest in WebGL. Our previous work on its predecessor (Canvas 3D) has led to more interest in our work as well. When we were developing the library for Canvas 3D, we had really only one browser to test for. Usually the video card/OS determined whether our library would work or not. However, as we port to WebGL it became clear that we needed a better way to allow feedback from users. Currently what we have are just comments… user says “doesn’t work on my system running….” in the comments. However, I do not feel that this is a good way to do this. Two reasons for this:

It is not simple. I firmly believe the easier we make it for someone to give us feedback, the easier it would be for us
It doesn’t give any positive feedback. We know when things do not work but what we don’t know is when things do.

What we would like to do is create a series of tester pages (easy enough as we have tests for all our features) and allow the user to easily give us feedback on whether or not they see the expected result. The results can then be placed on the tester page like a comment (possibly with the information analyzed so we don’t end up with multiple entries saying the same thing).

We would like to put up something like this(NOTE: this page doesn’t work! just shows you what we want to do): http://www.c3dl.org/wp-content/tester_template/

Our site is wordpress driven and while wordpress has some very nice features, there are definitely downsides to it. Often we find that if we want to do something out of the ordinary, we end up having to jump through hoops to get wordpress to play nice and not get in the way.

For the past week or so, I have been trying to hunt down a plug-in that will allow us to create a form on a page and then let it display the results (pretty much a customizable comment form that is different from the comment forms on our other pages). At first I thought I could do this with a contact form plug-in. I have since discovered that a comment form is not exactly the same as a contact form. BTW… I’ve just started doing research into this area so if I’m mistaken about this, please let me know. Contact forms get mailed back to you while comment forms are shown in page. I was hoping that I would be able to find a plug-in that would let me do this but no luck so far. While there are lots of contact form plugins, I don’t think I see any that show the information right back to the page. I think I can get what I want by doing some theme editing but I was hoping there would be a simpler solution. In any case, hopefully I’ll be able to find something soon to solve this.

Problems with porting

peter — Mon, 23 Nov 2009 21:28:19 +0000

I’m currently in the process of trying to port over our library so that it works in Safari(WebKit) (and eventually Chrome too) and not just Firefox. The first step of this was getting rid of our use of a ‘const’ namespace, and I’ve accomplished that (I haven’t actually released it because I want to make sure it works right before I release it and start letting people use something that’s broken), but now I’m having trouble with the differences between how Firefox handles including extra files in script tags, and how Safari does it.

The issue is that to use c3dl you have to tell the browser to include some extra files (normally using script tags) and instead of having to manually include each file (there are quite a few of them, it is a library after all), it is handy to include one file, which then gives instructions to include all the others. Doing it this way means that you can make changes to the library (maybe add some now files or get rid of some obsolete ones) and you only have to change the file that says what files to include, which will cascade to all the pages that include it. If we manually put all the includes in every web page, you’d have to update every one of them every time there was a change to the file structure of the library.

Firefox seems to accept this and when the first file you tell it to include (from now on we’ll refer to that as fileA), says to include some other files (we’ll call them fileC, fileD, and fileE) it reads them before it gets to the next file that the page tells it to include (we’ll call that one fileB). To rephrase that: The page says to include fileA and fileB. FileA says include fileC, fileD and FileE. FileB has some other code (in our model, this is the actual 3d app that you’re trying to display in the canvas). Firefox includes fileA and based on what it says also includes FileC, FileD and FileE. Then it includes fileB. Safari includes fileA, then fileB and then gets around to what FileA told it to do and includes fileC, fileD and fileE (I think…it crashes before it can get here). The problem is that files C,D and E are the library, while B is the code that needs the library to run. So we have to get C,D and E before B, or to go back to the real code, we need the library before we read the code that uses the library. So I need some way to force Safari to read the files in the library before it reads the file that says what the page does.

Now, I keep using the word ‘include’ and I know JavaScript does not have an include statement, but I mean the general idea of reading code that is in some other file. Here this is accomplished with a script tag such as:

So Firefox would include c3dapi.js, then everything c3dapi.js says to include (it just adds some more script tags like this to the DOM, each of which specifies some other .js file to use), then it would include orbiter.js. Safari includes c3dapi.js, then orbiter.js, then all the other files that c3dapi.js added. So I need some way to force Safari to include them in a specific order. We have already received an email or two with suggestions (Thanks Tim) on how to make the code work on Safari, and they at least allow us to do away with the SCRIPT_PATH variable, but they still fall victim to the same problem about the order of the includes. Right now I’m using appendChild on the head element to add the extra script tags, but I’m thinking there might be a way to sneak them into the middle of the head’s child tags so we can get them to be read before the next script tag that actually did appear on the page. I’m thinking something like insertBefore or insertAfter, but I need a little more time to play with those.

I’m going to keep working on this, and if anyone has any suggestions, I’d be happy to listen.