.obj to .dae
Andor Salga | 8 October, 2008 | 12:59One 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.
"JavaScript can’t directly read files" This blog post is so old
Joe Hocking | 28 February, 2011 | 14:29“JavaScript can’t directly read files”
This blog post is so old that you may already know about this, but I did figure out how to load binary data in JavaScript; I hacked in a .ply loader for a project I’m doing with C3DL.
The following is a copy-paste of all my notes when I was researching how to load binary files in JavaScript, but long story short you can use overrideMimeType() to make the XMLHttpRequest command return the unaltered byte array instead of trying to interpret the text streaming in.
//code adapted from http://www.storiesinflight.com/js_binary_loader/index.html
//and http://robert.accettura.com/blog/2006/12/02/xmlhttpreqoverridemimetype-in-ie7/
//and http://blog.nihilogic.dk/2008/05/reading-exif-data-with-javascript.html
//and http://msdn.microsoft.com/en-us/library/ms535874%28VS.85%29.aspx
//XMLHttpRequest origins documented http://blogs.msdn.com/b/ie/archive/2006/01/23/516393.aspx
//http://msdn.microsoft.com/en-us/library/cc534581%28VS.85%29.aspx
//http://developer.apple.com/internet/webcontent/xmlhttpreq.html
//extracting data from binary stream
//http://stackoverflow.com/questions/1240408/reading-bytes-from-javascript-string
//use this class to turn the byte array into integers, floats, etc.
//http://blog.vjeux.com/2010/javascript/javascript-binary-reader.html
//but use this version to correct problem in float decoding
//http://www.terrybutler.co.uk/2010/07/27/html5-quake-ii-md2-model-loader-and-renderer/