To place a model into a scene, the model must first be created in a modeling application such as 3D Studio Max, Blender or softImage.  Once it has been created, the vertices, normals, etc. must be exported to a file. Since JavaScript can’t natively read files, we have decided to create a conversion tool to convert the exported file into a set of javascript arrays within a .js file which can then easily be used.  We decided on using the Wavefront obj specification as many modeling applications can export obj files, it is simple, human readable and easy to convert into other formats. The workflow to get a model into a scene, such as a car would be: 1 – Create the car in a modeling tool. 2 – Export to the obj file standard, let’s say car.obj. 3 – Use our tool to convert car.obj into car.js, where car.js will contain a set of JavaScript arrays for the vertices, normals, texture coordinates and faces. 4 – Somewhere in a script, include the lines: Model car = new Model(); car.init(carVertices, carUVs, carNormals, carFaces); Then the car can be translated, scaled and rotated into the scene. The converter Here is the current interface of the converter: objconverter objFile [jsFile] [prefix] objFile – The file to convert. jsFile – An optional argument which is the path where to place the converted data, if omitted, it will default using the first part of the objFile, in this case “car” with an appended “.js”. prefix – An optional argument. If ther user wants, they can choose the prefix of their variables. If omitted, the arrays will be carVerts, carUVs, carNormals and carFaces. If they provide an argument, it will be used instead of “car”. This is simply made as a convenience. Users can just as easily open the file and rename the variables on their own. Limitations Currently, the tool has some limitations. The first is trying to convert an obj file which contains a model which has not been triangulated and another is converting a model which does not have texture coordinates or normals. Typically, triangles are used to approximate a model, but quadrilaterals can also be used.  Currently, the our Model ‘class’ only accepts triangles, so this creates a problem. I have found Blender to be notorious for exporting quads instead of triangles.  So a face in an .obj file may look like this: f 1/1/1 2/2/2 3/3/3 4/4/4 instead of this: f 1/1/1 2/2/2 3/3/3 (Check out the File Format section in tutorial 4 for an explanation of vertex, normal and face arrays) If a face with 4 parts is found, the converter rejects it and informs the user the model has not been triangulated.  However, correcting this is not difficult, Blender does provide a means to triangulate the model with a click of a button during exporting. Models must always have vertices, but normals and texture coordinates may not always be present. This creates a small problem when trying to place a model into a scene since the init() method of a Model requires the normals and texture coordinate arrays. I have decided to address the problem by issuing a warning to the user. The warning simple states that since some data was not found in the .obj file, the exported data may not work with older versions of the library. I am presuming in some future release the normals and texture coordinates will be optional (currently they are required). Annoyances and amends One annoying thing I found when working with a .js file is that the array variables in the file were tricky to find and copy to place in the Model.init() call. So, I made the converter place a list of the arrays at the top of the file in a comment, so copying is easy. So, if the Blender monkey was converted, the comment would be: /* monkey has… 507 vertices 2904 texture coords 946 normals 968 faces monkeyVertices, monkeyNormals, monkeyUVs, monkeyFaces */ Another small annoyance was having to open a command line window just to convert the file. To fix this, I tweaked the code to properly accept files dropped onto the converter. However I haven’t tried this on my mac yet. Now what’s left to do is more testing and porting over to Mac. The next demo I am currently working on is a 3d map using the Google Maps API. The reason for this demo is to bring together canvas 3d with other web technologies. So far I can create a route in 3d that is an exact representation of the route Google Maps gives you when asking for directions between locations. The route is a 1:1 scale in the canvas so I needed to set the camera really high up to look down and see the whole map. I then added a zoom function to scale everything so the camera would not have to be set so high. The other reason for the zoom function was the route actually went out of the 3d rendering space. Part of the route was not getting rendered. Besides there is no need for a 1:1 mapping anyways. Next step is to have the camera travel along the 3d map. Then I would like to add features such as 3d Street signs. As the camera moves along the path the user can see the names of upcoming streets. Another feature would be simple 3d buildings that would have the name of the business on them or maybe a bubble or cloud that has the name of the business along the route. Some of the ideas I have floating around in my grey matter. The source code for the Typing Game and Flickr/Picking demo have been uploaded. On the demo page at the very bottom there is a link to the source code. In the source code it mentions which version of the Canvas 3D API the demo is using. The user will need to download the correct API and extract it to use the demo. A link has been provided in the demo file to get the appropriate API release. Enjoy! I posted the two demos I have been working on: Explorer and Ricochet. Explorer is a simple demonstration of some of the camera’s functionality, model loading, texturing and it also has a skybox. The skybox currently is not part of the library however, it is very easy to create. Explorer has limited user interaction but its main purpose is to show users how easy it is to create a 3D environment with the library.

Ricochet is a Pong-inspired game. It’s an earlier demo with collision detection, scoring and basic camera manipulation. Both are somewhat preliminary and I plan to refine them as time goes on. However, their main purpose is to showcase some of the features of the library which I hope I have done. As the library becomes more efficient (and as I hone my javascirpt skills), I foresee demos which are better and faster….and don’t eat memory for breakfast! ;)

Here are the demos:
Explorer
Ricochet

Both demos detect if the canvas loaded properly. If canvas loading failed, an image is displayed instead with a screenshot of the demo and some text directing the user to setup instructions. It took me a little longer than I was anticipating but the flickr/picking demo is done.  It is available under the demo section of the website.  This demo grabs different sized images from Flickr and textures them onto some cubes.  The user can rotate the cube as well as zoom in on the cube.  For those that don’t know of Flickr, it is a photo management system.  It allows people to upload there personal images and they can be made public or private. I would have published earlier but I ran into some problems.  Apparently I misunderstood what the client mouse position was.  I thought I was getting the coordinates of the mouse on the element that generated the mouse callback.  What actually gets returned is the mouse position with regards to the client window.  I realized this problem when I was adding my demo to a webpage and I moved the actual location of the canvas on the page.  Now the mouse position on the screen didn’t match the mouse position over the canvas.  Further more if the page scrolls but the mouse stays still, the actual position of the mouse in the canvas has changed but the mouse position to the client has not. I spent a few hours researching this problem until I discovered a script by Peter-Paul Koch that finds the actual position of any object in a page relative to the page. That only helped while the canvas was on the screen and the page did not move.  Once the page scrolled or was resized then my mouse position no longer reflected its correct position within the canvas.  I then did some more research and found that the window has an attritube pageXoffset and pageYoffset which holds the amount a page was scrolled by or resized by.  Hallelujah!  My demo now works regardless of scrolling or resizing. On a side note: I noticed a problem with using Intervals in javascript.  The problem is the interval is not executing at the time set in the setInterval function.  This might have something to do with our update Interval.  The scene runs an update every 25 milliseconds.  I wanted an interval to run every 250 milliseconds to check my camera position while it was moving.  I decided to change it to 100 milliseconds and noticed that my interval was only getting called 5 times.  I reduced the interval to 25 milliseconds and still it only was getting called 5 times during 1 to 2 seconds.  I’ll have to research to find out about the limitations of using Interval.