Jump to content

Loading GLTF Files

Josh

709 views

With an understanding of JSON for Modern C++ (an excellent library) I was able to dive into the new GLTF 2.0 file format and create a model loader. Here's what I've got so far:

Image1.thumb.jpg.9b26429e4ec449035bcbba429013c3f7.jpg

Although the file format is JSON-based, vertex and indice data is loaded from either a binary .bin file, or packed away at the end of the ASCII file. You can open GLTF files in NotePad and edit them, but GLB files are a mix of ASCII and binary. The model above loads in about 16 milliseconds.

I did find some big shortcomings in the file format, however, and I am going to list them here.

1. It's needlessly complicated

The way data is stored is ridiculously complex. Accessors, bufferviews, and buffers? Why not just provide an array of values. The designers of this spec must have been on some serious drugs when they came up with this. I understand why they did this, they are trying to make resource reuse as efficient as possible, and allow the file format to dictate how data is stored internally, because they are writing this from the perspective of a graphics API designer. Guess what? NO ONE is going to use it like that. Everyone is just going to load the data into their own mesh structures and send it to the GPU however they want. Allowing the file format to control how data is stored internally in the engine is a level of stupid I can barely conceive of.

Why does this matter? Well, if you are trying to get people to adopt your file format you make it as simple as possible. Collada was a disaster, and I personally know one programmer who nope'd out of there after taking one look at the GLTF specification due to bad experiences with Collada.

2. It's not a model file format

GLTF is a scenes (plural, we'll get to that later) file format and it's being shoehorned into something else. There is no guarantee of a single top-level node, so my loader has to create a root model to parent multiple nodes to if they are encountered.

3. It's not meant for games

GLTF stands for "GL Transmission Format" which sounds like an STD but is meant for serving up 3D scenes in a web browser. Thus, it uses JPEG and PNG files for textures and does not support the most common texture format for games, DDS. It doesn't even support Khronos' own KTX texture format that no one uses. Why does this matter? Widespread support for GLTF is one of the compelling reasons to use it. When you select a GLTF file in Windows 10 Explorer, it shows the model in a 3D preview window. Really nice!

Image1.jpg.e096913c3ea2ad33bed2e0b441550e3e.jpg

But if the model stores a DDS texture, it will fail to load! (It still loads successfully in Microsoft's 3D object viewer included in Windows 10.) I plan on using DDS textures in the new engine, but if all our 3D models won't display in Explorer, why use the format?

Image2.jpg.7345d8233910b90ef973b252aaac95c9.jpg

There's also no support for or concept of material files stored in external files. All materials are packed into the model file. I'm not sure how we are going to handle this.

4. It even sucks at what it's supposed to be

The design of the GLTF format is a giant catch-22. Check this out: All model and material data is stored in the file format, and there is no loading of models from external files (like other GLTF files). But it's a scene file format, right? Most games have more than one setting. You don't want to have all your models copied to all your different scene files redundantly. GLTF solves this by including multiple scenes in the file, with a value to indicate the first "map" to load. So all your models, textures, and scenes are getting packed into a single file!

Here's the kicker: There is no support for model compression, and this is supposed to be a file format for sending to web browsers. No problem, let's just use some ZIP compression to compress the whole file, right? Ha! Now you have to decompress ONE GIANT FILE containing EVERY MODEL AND SCENE used in your ENTIRE GAME just to load one scene!

The concept of having editable asset files and a separate file format for the published game is straight out of 1994. We're not going back to WAD files and we're not going to pack all our game content into one giant uncompressed file.

UYI8Tx4.png.29e0673e3347750bbb84dc733f47f4ef.png

I actually have a soft spot for WAD files. Leadwerks 6?

But Waitaminute...

Okay, so those criticisms aside, it's still pretty good. We have a fast-loading open-source 3D model format with widespread support. It's designed with the concept of PBR materials built-in. And with extensions, this file format that was not designed for game models is being shoehorned into a standard that is already ahead of FBX. So in the new engine we are going to try to use GLTF as the main model format, not just as an intermediate format we convert models from. There are still some unanswered questions that will be challenging to resolve, but I think this is going to give us the best workflow in the future. Oh, and GLTF destroys OpenGEX based on one simple factor: binary data. You do not want to load vertex arrays from text as it will cause very slow load times.

The whole concept of an "exchange format" is pretty dumb. It never works and it isn't what people want. People want an editable game-ready format, and GLTF while not perfect is pretty close to that.

  • Like 3


2 Comments


Recommended Comments

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...