A Custom glTF Importer for Unity
I've never really liked Unity's handling of Blender (
.blend) files, so after doing a bit of research, I decided to write a custom importer for glTF files. It actually turned out to be less work than I thought it would be, and being able to extend the importer with additional custom properties has been very useful!
Well for starters, the FBX (Filmbox) file format is proprietary (owned by Autodesk) and generally requires the use of Autodesk's C++ SDK to read and write FBX files. Because of the licenses involved with the SDK, the Blender Foundation was forced to basically reverse engineer the file format in order to provide an importer and exporter for Blender. Sadly, this resulted in the FBX exporter having a few annoying bugs that I've had to fix in the past.
Annoyingly, Unity uses Blender's FBX exporter to "import"
.blend files into their Editor. It does this by running Blender with a Python script that calls the FBX exporter (found in
Unity\Editor\Data\Tools\Unity-BlenderToFBX.py) for each
.blend file in the project. One of the issues with this is that the script uses the ASCII (text) version of the .FBX file format instead of the binary version which has had more support in Blender. This conversion process also does a fairly terrible job of handling the coordinate system differences between Blender and Unity which you may have noticed before (models likely have a non-zero default rotation applied).
I worked around this for a while by using a modified FBX exporter script for Blender as well as a custom version of Unity's
Unity-BlenderToFBX.py file and even wrote a simple C# script to handle updating the files each time Unity or Blender was updated.
One other issue that I have with FBX is that it's intended to be a full interchange format between modelling programs. This means that the data is stored in a way that might be friendly to a modelling program, but it requires additional processing to make it optimal for a game engine to use resulting in slower imports.
Well, here's the short description of the format from the glTF website:
glTF™ (GL Transmission Format) is a royalty-free specification for the efficient transmission and loading of 3D scenes and models by applications. glTF minimizes both the size of 3D assets, and the runtime processing needed to unpack and use those assets. glTF defines an extensible, common publishing format for 3D content tools and services that streamlines authoring workflows and enables interoperable use of content across the industry.
So, it's a royalty-free specification developed by the Khronos Group with a primary goal being to quickly present 3D scenes and models. The data stored in glTF files can be quickly read and converted to most game or rendering engines with minimal processing. It's also easy to extend with custom properties which I'll cover that in just a bit.
All the details about the glTF file format can be found in their GitHub repository including links to existing importers and exporters as well as sample files. And the good news is that Blender already includes a glTF exporter capable of exporting meshes (rigid and skinned), PBR materials, scene hierarchies, and animations.
The actual glTF specification is the likely the best way to learn about the file format, so I'll be quite brief here. There are variations of the format represented by two file extensions:
.gltf files are actually just JSON files that describe one or more scenes including node hierarchies, materials, cameras, meshes, animations, etc. Large data arrays for these objects are stored in either a separate
.bin file or embedded directly into the JSON using base64 encoding. Textures may be stored as individual files (as
.jpg) or they may also be stored inside the JSON file using base64 encoding.
.glb files (at least those exported by Blender) combine the JSON data, buffer data, and images into a single binary file. While this might be helpful for uploading to SketchFab or possibly for runtime mods, the inability to edit textures makes this variation less than ideal for game development. Since the JSON data is the same (other than being embedded), it's still pretty easy to support this format if desired.
The JSON data is fairly straightforward to understand just by looking through the spec and a few examples. The Properties Reference section of the spec describes each of the object types and their required fields and default values. The only thing that might seem a bit odd at first is the use of Accessors and BufferViews that simply specify the datatype and starting offset into the binary data for things such as vertices and animation keys.
One important thing to note about glTF files is that the coordinate system is right-handed, Y-Up (vs. Unity's left-handed Y-Up coordinate system). glTF models should face down the +Z axis as the specification states that model viewers should orient their default camera pointing down the -Z axis. Note that in Blender models should face down the -Y axis in order to export to glTF correctly.
The Khronos Group maintains their own importer for Unity called UnityGLTF. It's a great resource, but there are a few things that I wanted to improve on:
- UnityGLTF has a dependency on the Newtonsoft.Json package which I'd definitely like to avoid. It's actually quite easy to make a set of classes that mimic the glTF JSON schema and use Unity's built-in
JsonUtility.FromJsonOverwritemethods to handle deserialization of all JSON data and avoid the extra dependency.
- UnityGLTF includes an exporter as well. This might be useful for some people, but it's not something I need, so I'd like to avoid including it.
- In a similar vein, UnityGLTF has to be everything to everyone (or at least that's how everyone seems to view it). There are several feature requests for things that I know I'll never need and this just leads to code bloat and the potential for additional bugs.
- It appears that UnityGLTF currently only supports importing materials into Unity's standard (non-scriptable) rendering pipeline. Since I'll be using either the Universal or HD pipeline, I would have to modify their importer. With a custom importer, I can import materials exactly as needed including how existing materials are handled.
- UnityGLTF still has several optimizations (both performance and memory) that could be made. I'd like importing to be as fast as possible and require as few GC allocations as possible, so being in control of that is important to me. I'm perfectly fine with using a few
unsafeblocks and memory-mapping binary data files to eke out as much performance as possible.
Because it is a custom importer, it's also easy to export additional properties from Blender. These properties can then be used to automatically add colliders and NavMesh settings to imported models without having to remember to add them manually.
So to sum up, I'm not a huge fan of third party libraries having had many headaches with them in the past. For something as critical as models and animations, I'm okay with writing an importer especially when it should save some work and time in the future.
Once I have time to test the importer more thoroughly, I'll create a repository for it on GitHub for anyone wishing to customize it to their needs. For now, I'll briefly cover a few of the important details. Feel free to leave a comment if you are interested in additional details.
To start with, I created several classes that map directly to the objects in the glTF specification. These classes are pretty minimal with fields whose names match the properties in the spec. The most important thing to remember is that each class needs to have the
[Serializable] attribute for Unity's JSON importer to work properly. Here's an example of the
Node class that I use (with comments removed).
I use default values of -1 for all fields that represent indices and since the spec defines the
translation values as arrays in JSON, I do the same. Note that rotation values are always quaternions.
.gltf JSON file and memory mapping its binary data (
.bin file) is then a simple matter of doing:
public static Gltf LoadGltf( string filename )
For anyone unfamiliar with memory mapped files, be sure to check out the
MemoryMappedFile documentation on MSDN. The
MemoryMapBinaryData method shown below opens the file for read-only memory-mapped access, creates a view accessor, and then stores a
byte* that can be used to directly access the binary data:
void MemoryMapBinaryData( string filename )
Also note that it is very important that the
Gltf class that wraps this access implement the
IDispose interface and properly release the acquired pointer and dispose the view accessor and file. It's also very important to call
Dispose or use a
using statement for immediate cleanup of the
Gltf instance where it's created (see next code snippet).
The first step here is to create a new class that derives from Unity's
ScriptedImporter class and load the glTF data inside the overridden
Note: To avoid name collisions with Unity, I put all of the
Gltf object model classes inside a
Gltf namespace including the root
Gltf class. It looks a little odd in the line above, but it ended up being the cleanest approach.
Import method simply calls methods that loop over the arrays of meshes, materials, nodes, and animations from the glTF file and converts each object into its Unity counterpart.
void Import( AssetImportContext context, Gltf.Gltf gltf)
Once the objects are converted, it then adds the root GameObject to the Unity asset and sets it as the "main" object. Meshes and animation clips are also added to the asset. Materials are created as separate asset files only if they are not already found in the same directory as the glTF file. If a material's name starts with a "'/", is is assumed to exist in the global materials directory and is not automatically created.
Converting the objects is fairly straight forward, but as previously mentioned, glTF uses a different coordinate system than Unity. Luckily this is a pretty simple transformation:
- Positions and directions (including tangents) need to negate their
- Quaternion rotations need to negate both their
- Triangle vertex indices need to be reversed to preserve the proper winding when changing from a right-handed to a left-handed coordinate system.
- Bind pose matrices used for skinning need to be pre and post multiplied by (-1, 1, 1). This can be done simply by negating the following values after copying the glTF matrix:
bindPose.m01 = -bindPose.m01;
Custom properties are quite easy to import from Blender. Simply create a nested, serializable
Extras class inside the
Node class and add additional properties to it. Then custom properties with the same name that are added to objects in Blender will be automatically imported:
In Blender, it's possible to add additional properties from the bottom of the Object Properties panel (the orange box icon) using the Custom Properties sub-panel. This can get a bit tedious and is prone to typos, so a nicer way to add custom properties in Blender is to extend a type (Object, Mesh, Action, etc.) with the desired properties (note that currently custom properties for actions do not export to glTF, but this should be fixed shortly):
# Add custom properties to Objects (glTF Nodes).
A custom sub-panel can then be created to display the properties inside Blender's Object Properties panel:
# A custom UI Panel for exported Objects (glTF Nodes).
If you happen to be using Git for your version control, it's likely that you'll need to add an entry in your
.gitattributes file for the glTF
.bin files. Since the
.gltf files are actually text (JSON), there shouldn't be a need to add an entry for them. You can check out our .gitattributes for Unity Projects file or simply add an entry to yours:
*.bin filter=lfs diff=lfs merge=lfs -text
I was originally hoping to simply replace Unity's built-in importer for
.blend files, but unfortunately Unity does not allow this. It's not a huge issue, as I finally decided that having Unity launch Blender to do conversions has its drawback. Others on the project may not have Blender installed and having it load large sculpted models is a waste of time when only a low-poly version is needed for import.
Sadly, it's also not possible to disable the automatic import of
.blend files which is quite annoying. In the next article, I'll discuss a simple work-around for this issue as I find it very convenient to have Blender files located inside the
Assets/ folder where they can be easily loaded from Unity's Project window.