Fix Missing Materials in Blender FBX Exports to Unity

There’s a bug in the FBX exporter for Blender 3.x (and now 4.x) that doesn’t export materials on instanced meshes. While the original mesh imports into Unity just fine (and remaps materials correctly under the importer’s Materials tab) duplicate instances of the same mesh import with only the default Lit material. If you’re (perhaps oldschool) like me, and use a lot of instancing to save disk space, this is a problem.

Here’s a Unity Editor script to fix things:

It supports Undo, regular and skinned meshes, and will walk down the hierarchy as far as it needs to. Can take a few seconds to grind through big hierarchies. Works on my ultra-complex Lighthouse prefab, and all the others I’ve thus far thrown at it. If you find a bug, let me know!

Here’s how to use it:

  1. Download & unzip the files.
  2. Add FixFBXImportMatsUI.cs to your project’s Editor folder. (If your project doesn’t currently have one, add a folder named “Editor” to your Assets folder.)
  3. Add FixFBXImportMats.cs to your project, wherever makes the most sense.
  4. After importing an FBX with missing Materials, open the Prefab or drag it into a Scene, and add a FixFBXImportMats Component to the root of the import’s hierarchy.
  5. Assign the Default Material you need replaced to the Component’s slot.
    • The default Material will vary depending on your render pipeline and import settings.
    • If using URP, it’s usually the Lit material, located in Packages: Universal RP: Runtime: Materials.
    • A quick way to find it is the select an instanced mesh in the hierarchy, and click on the Material shown in the Editor.
  6. Leave Clean Up After checked to have the Component remove itself after running.
  7. Click Fix Materials.

Useful Unity Components: PlaySounds

In this ZIP file you’ll find three C# scripts for Unity: PlaySounds.cs, PlaySoundsMultitrack.cs and PlaySoundsBySpeed.cs. The latter two are subclasses of PlaySounds.cs, and require the former in your project. These small, lightweight scripts are used throughout Lillie is the Keeper (along with a couple other subclasses that are dependent on features of the game).

Basically, they do everything that I wish Unity’s own AudioSource Component did by itself. Play through a list of AudioClips? No problem. Play a random clip from a list? Done. Play OnTriggerEnter()? One click. You can play a single clip or all clips, disable the GameObject after playing, trigger audio from an external script, and monitor playing status with UnityEvents or a simple bool.

Check the scripts’ headers for a full rundown of features and how to use them. You’ll also see helpful tooltips in the Unity Editor.

The two subclassed scripts, PlaySoundsMultitrack and PlaySoundsBySpeed let you do two additional things. With the former, you can swap between up to four wholly different sets of AudioClips. Think of a windmill randomly playing different sounds from a playlist at different speeds: a slow, creaky set of sound clips at lower speeds, and a higher, whooshier set at high speed. PlaySoundsBySpeed lets you specify a minimum velocity at which to trigger sounds, and scales the volume up from 0 to 100% at a maximum speed. (Setting both speeds equal always plays the sound at normal volume.)

There are a couple things you may want to customize. These are written for rapid prototyping, trying things out, and generally seeing what works. Just about everything that can be public is, rather than using [SerializeField] private. If there are no AudioClips in the list, PlaySounds will simply disable itself; you may prefer to throw an error. Additionally, you’ll notice that an AudioSource component is necessary, but not required in code via [RequireComponent(typeof(AudioSource))]. (Instead, PlaySounds logs the issue for you.) This is deliberate, to keep Component coupling loose while trying things out, but may not be what you want in production.

I encourage you to use these, without limitations, in your own work. (But if you do something cool, please do let me know!)