One of my colleagues at Montage Studio was involved in developing the glTF spec. We built a set of open source components that make it easy to load a glTF scene and manipulate the contents with data bindings and CSS transforms: http://montagestudio.com/blog/2014/01/22/build-3d-applicatio...
Those who are interested might also want to check out this recent paper by Brian Coughlin that compares glTF and Declarative 3D: http://mason.gmu.edu/~bcoughl2/cs752/
"There are industry-standard interchange formats, namely COLLADA"
Haha. Most game devs I know wouldn't touch collada with a 10 foot pole. FBX on the other hand has established itself as an acceptable interchange format.
I applaud their effort and hope they can gain some real traction. Having written one of the proprietary content pipelines they speak of, I couldn't help but feel that I was reinventing the wheel in a lot of places.
I really wish that Rad Game Tools binary data format could be the basis of this spec's binary format. Their's is an extensible object tree that could be loaded directly into memory via a mmap, leading to blazing fast load times for any content that we used it with.
I have used it a bit. We had integrated it as an export format for https://Clara.io for a while, but then we removed it. We can add it back now that the spec is near finished.
a glTF asset is represented by:
* JSON file (.json) containing the node hierarchy, materials, and cameras
* Binary files (.bin) containing geometry and animations
* Image files (.jpg, .png, etc.) for textures
* GLSL text files (.glsl) for GLSL source code for individual stages
.obj is a horrid format for runtime usage in a game engine. The effort required to parse a non-trivial model will explode your load times on resource constrained systems.
The content pipeline that I implemented for our game engine always converted .obj files into a binary format that is trivial to load at runtime. In an ideal world (i.e. not Android), your binary format is one that you can simply mmap into your process and then at worst "loading" consists of copying this memory and doing some pointer fixups.
> There are industry-standard interchange formats, namely COLLADA, that allow sharing assets between modeling tools and within the content pipeline in general. However, these formats are not optimized for size or runtime use and neither are modeling-tool-specific formats. At runtime, an application wishing to render an asset needs to do a significant amount of processing to transform the asset's content into data appropriate for the GL APIs.
I saw the mention of COLLADA in the beginning, and prepared myself for the worst, and here it is.
Things I dislike about this:
0. Not a single editor looks like they write games/do web programming for a living. Their experience and expertise is questionable at best--and one of them is responsible for COLLADA.
1. We don't need shaders in our assets. Time and time again we find out that assets are fed into tech that's wildly changing, and having any prebaked assumptions about shading is a "Bad Idea (TM)". This format would be more useful, for example, if it didn't assume glsl, if it didn't assume multiple rendering passes, and so on.
2. Don't have an "extras" or "extension" section. There's no reason that it should take a long time to extend a format, especially if its tightly-scoped and simple to being with. Adding this flexibility here leads to issues with shoving in special data, lazy exporters, hard-to-write importers, and so on. Just no. Stop. That's why .OBJ has has such staying power--it is simple and non-extensible (barring weird shit like smuggling data into comments).
3. Schemas are silly in this use case. This is the Web, we don't really use schemas in our JSON. This is a practice pulled over from XML, and honestly one that just smells to me like "Oh, we had this in XML COLLADA...LETS DO IT IN JSON!!!!!one".
4. The material system is vague. It's an overly complicated wrapper for what, I assume, would normally just be a JSON object of param:value pairs. Better question: when would this ever be used in a real application? Hint: never. You want a simple mapping of faces to a material ID, and then maybe a separate definition of those materials in, say, a simple format (which is not what this spec does). Usually, you just punt to the rendering pipeline anyways.
5. They don't specify a binary format. This would be a useful thing to do, especially if paired with a decent reference parser. Punting that down to road means that they are forced to be overly generic in their notions of materials and animations and whatever else, without actually adding any value in terms of how to store the meat of the asset data.
6. Cameras are almost always determined by the application, and can be represented more compactly than they are here.
7. Optional and default values are the devil. No no no no. This format is intended for consumption by machines, and maybe by humans--if I have to read your spec to figure out why something is being set to what it is, I'm not going to use your format. Explicit >>> implicit for file formats.
~
I could go on, but why bother?
This just looks like a bad attempt to bring over the problems of COLLADA into JSON and then inflict it on web developers.
I'd much rather see people solving the problems that we actually have:
1. Make a simple binary/base64-wrapped format to handle static mesh geometry with material groups.
2. Make a simple binary/base64-wrapped format to handle animations and describe tracks. Go look at md5anim as a start.
3. Make a simple JSON format to describe a scene graph. Just nodes and translations.
4. Make a simple JSON format to describe all of the metadata associated with a scene--list of scene graph files, list of animation files, list of mesh files, list of materials files, and maybe grouped into device requirements (oh, on mobile, load this instead).
And so on. The idea is to have simple microformats that are straightforward to implement, standalone, and that compose nicely. COLLADA/glTF is not that.
Moreover, consider what we're trying to accomplish here: little dioramas and markup (ala VRML), or assets that are actually going to be reused in different applications as content atoms (like images or sounds are).
Those who are interested might also want to check out this recent paper by Brian Coughlin that compares glTF and Declarative 3D: http://mason.gmu.edu/~bcoughl2/cs752/