Why JSON Rulez!

One of the issues that came up as we developed O3D was what format to load for 3D content. There are a few standards out there, the most notable probably being Collada, and so originally we planned on loading Collada files directly in O3D. We quickly ran into limitations.

There's nothing wrong with Collada per se, it's just that it's designed to do one thing: exchange 3D data. If your application doesn't fit its model you either have to work around it by trying to squeeze your extra data in to the nooks and crannies of the Collada spec or you have to redesign your application to fit what Collada supports.

After a few months of working with the limitations of Collada, we thought about it more and realized that similar to how other 3D APIs like OpenGL or DirectX do not define a file format, we shouldn't either. Instead, we should provide the pieces needed to make it possible to load data into our API, and then leave file formats up to the individual application developer. This allows the developer to tailor the data they send over the net to match their application. A mapping application might only need to send line segments, street widths and names. A 3D viewer might need triangles, materials and a transform hierarchy. A game might need all that plus collision data, character data, A.I. data, etc.

In switching to JSON we made all of that possible. Instead of some "black box" in which you give a URL and it magically loads the file with no control from the developer, we instead made the process completely transparent. Not only can you see exactly what is happening but you can also change almost every part of it to suit your situation.

Some parts of the data seemed like they were probably too large for JSON. Textures of course fit into this category, but also other elements such as vertices, animation and skinning data can get quite large. Even though, those assets can still be 100% in JSON if you like (depending on the size of your assets), we made it possible to load those types of assets from binary data and provided an API to load the data from gzipped tar files so you can package all of this up into manageable, easy-to-download pieces.

Having this process be open might sound like more work for each developer, but we provide a solution for this problem as well. We have a sample offline converter that takes a Collada file and converts it to a sample JSON format. We then have a sample library that reads that JSON format and recreates the Collada scene in O3D. With one command to convert your data and a couple of lines to load your scene, you'll find that it's very easy to use.

However, the offline converter and loading library are just that, samples. If you want different data you are free to modify the converter or write your own. For example, if you want something different to happen at load time, the loader is written entirely in JavaScript (most of it is in serialization.js) which you can use as a starting point and modify to fit your needs. If we had chosen a fixed format, all of that flexibility would have been lost.

Given this flexibility, we're excited to see the myriad of applications that will come out of O3D. Make something cool and share it with us via the discussion groups and come meet us at Google I/O.

Posted by Gregg Tavares, software engineer, O3D Team.