Neil_TrevettThe Khronos Group announced that the open standard of glTF was gaining momentum by some of the key players within the graphics industry before SIGGRAPH this year. glTF provides a standardized baseline and interchange format to deliver 3D content to different tools and services; it’s been described as being analogous to the flexible and widely used JPEG format for images. The traction for a glTF open standard means that one of the fundamental building blocks for the metaverse is coming into place.

LISTEN TO THE VOICES OF VR PODCAST

I had a chance to sit down with the Khronos Group President Neil Trevett at SIGGRAPH where he explained the significance of this emerging consensus. He expands upon what glTF includes, and what it doesn’t. For example, there are not any point clouds or light fields within glTF. He also emphasized that previous efforts for an open format like VRML and X3D have included logic and code in the file, but glTF is meant to be simply a lightweight wrapper for 3D objects and textures. The code and logic for what to do with these assets will be in a separate format since it could range from JavaScript to C# to C++ to other emerging languages.

Neil said that an open standard for transmitting mesh data is something that many major companies were already independently working on. One of the primary use cases is being able to transmit 3D objects between all of the major authoring programs and eventually onto the web. But the Khronos group had already a proposed the glTF spec, and most of the preliminary feedback was that it could be a viable solution that solves many of the most difficult problems.

There are some available extensions to glTF, like physically-based rendering in order to add material and reflective properties. But Neil emphasized that they want to keep the initial glTF specification lean and simple in order to make it simpler to implement to maximize the adoption. They’ll be paying attention to popular extensions, and if there’s wide enough adoption then there’s a chance that it’ll be rolling into the official glTF specification.

There’s a glTF validator that’s available, and for more information, then be sure to check out this glTF resource page on the Khronos Group’s website.

Support Voices of VR

Music: Fatality & Summer Trip

Newsletter graphic

This article may contain affiliate links. If you click an affiliate link and buy a product we may receive a small commission which helps support the publication. More information.


Kent Bye
  • Jeri Haapavuo

    If he really said that this is “the JPEG of 3D”, he doesn’t know anything he’s talking about.

    JPEG is a lossy packaging format for 2D. Some data is always lost when doing a JPEG conversion. So GLTF looses data too? Nah, I don’t think so. It is more like “the PNG of 3D” then, which would be lossless and still portable.

    I didn’t listen the podcast but did he say that GLTF actually packs the data? Or just makes it portable? And do we loose information when using it?

    • rabs

      Usually it only means “as popular as JPEG”.

      • Jim Cherry

        also listen to the podcast

  • Jolly

    I guess it will have a smaller file size than an equivalent .fbx.

  • DaKangaroo

    Isn’t this the same group who designed COLLADA?

    No thanks.

    As a person who is hip deep in code right now writing importers for 3D mesh formats, I know how desperately the industry needs a good lightweight and straight forward 3D file format for mesh data. But what it doesn’t need is another file format designed by a committee like COLLADA, or another undocumented proprietary file format like FBX. And both formats are waaay too verbose for most real time 3D applications, and too bloated for the future of VR which will need a file format which is smaller in size to save on bandwidth for streaming 3D worlds.

    The whole goal itself even of creating a 3D file format that can describe all kinds of 3D objects and/or 3D scenes is completely wrong. We just need a good 3D file format for storing mesh, with vertex attributes, bone rigging and shape keys, etc, that’s it. How one piece of software renders materials/lights/cameras differs to the next piece of software by such a large margin that there’s really no point to including that data, most of the time it isn’t used anyway when transferring 3D models from something like 3D Max to Blender or ZBrush to Unity, etc. And there’s certainly no point in designing another file format which stores bezier curve surfaces and other complex stuff like that which 99% of software won’t support.

    For my own projects, like a lot of other coders, I’m writing importers for a conversion tool, and will be using my own custom 3D mesh format. Because it wastes too much CPU time to be parsing formats like COLLADA or FBX while trying to stream 3D models on the fly, so I just rolled a simple binary format which can be read and loaded almost directly into VBOs. Maybe when I’m done I’ll write up a proper file format spec doc and write some plugins for Blender and ZBrush and other software, and make available a conversion tool, see if I can make it popular! Why not right?

    After all, yeah my format is just the result of a week of coding from a random scrub programmer doing a hobby project, but unlike COLLADA, at least to read my file format you don’t have to start by asking, “OK, now in this file, which direction is up?”.

    • Narabel

      You fail hard.