Canvas 3d JS Library

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

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.

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:

1. 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
2. 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.

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:

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

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.

Yesterday I fixed a bug in the grayscale effect. Today I fixed rendering sphere objects as points. That means there are now about two known remnant bugs from the Canvas 3D to the WebGL port. Almost done!

I was using one of our mocap demos as a test for the last bug. Looking at it, I thought I should update it and make it a bit more intuitive. Hitting keys to change the script state? What was I thinking? So I created a form and added some simple controls along with jQuery UI sliders on the page. Use your cursor to orbit around the scene and the scroll wheel to zoom.

Enjoy!



Isn’t WebGL fun!?