
glTF: Runtime asset format for WebGL, OpenGL ES, and OpenGL - wolfgke
https://github.com/KhronosGroup/glTF/blob/schema-8/specification/README.md
======
segphault
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...](http://montagestudio.com/blog/2014/01/22/build-3d-applications-
with-montagejs/)

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/](http://mason.gmu.edu/~bcoughl2/cs752/)

------
forrestthewoods
"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.

~~~
teamhappy
Collada is not a runtime format. (And neither is FBX.)

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

------
bhouston
I have used it a bit. We had integrated it as an export format for
[https://Clara.io](https://Clara.io) for a while, but then we removed it. We
can add it back now that the spec is near finished.

------
Keyframe
_Audio has mp3. Video has H.264. Images have png and jpg. What does 3D content
have?_

Wavefront .obj?

~~~
hesdeadjim
.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.

~~~
meelooo
Yes, and that's why one can wonder why they once again chose JSON for part of
this new "web standard". Text based data formats should die.

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

