2
$\begingroup$

To be frank I'm not 100% sure if the problem I have is with Blender 3.0's FBX export or Unity 2020's FBX import, but that said maybe someone who knows more about this can help.

I have some scripting in Unity that dynamically modifies the first material on a MeshRenderer, and leaves the other materials, if any, alone. The idea is that the first material should be set by the artist as the "main" material, typically white, and the script can modify aspects such as HSV to give a visual effect.

Each material is applied to a distinct subset of faces of course.

The problem is that for some of the models I FBX-export from Blender, the first material slot shown in Unity (as an array of Materials) is not the first one that was defined in Blender. For example, Blender might show the following material slots with useful material names:

  1. White
  2. Grey
  3. Black

But after import the resultant FBX into Unity, the material array in the MeshRenderer shows in this order:

  1. Grey
  2. White
  3. Black

Grey and White have switched places. This means that the script operates on the Grey faces, not the White ones as intended. Reordering the elements of the MeshRenderer's array just applies the wrong materials to the wrong sets of faces, it doesn't change which set of faces is considered the assignment for the "first" material.

Changing the order of material slots in Blender seems to have no effect. I've also tried temporarily reassigning each set of faces to temporary materials, creating new materials in the correct slots, and assigning the faces back, but this doesn't seem to solve this problem either.

I've seen some historical comments from Blender developers along the lines of "material slots order doesn't matter" but I wonder if this is one situation where it might?

Or is there a better way to do this? Is there a convention for assigning metadata within an FBX to indicate to something like Unity which material is which? The script could search for a material name like "White" or "Main" but that seems to overload the purpose of the name somewhat.

(Is there a good FBX viewer that allows me to see the deserialised data within the binary FBX, so that I can see if changing anything in Blender actually changes anything with the serialisation order - that would help me work out if it's Blender's export or Unity's import that is the source of this issue).

$\endgroup$

2 Answers 2

3
$\begingroup$

I saw a solution to this problem on another forum and it helped me.

  1. Go to edit mode, press P and separate By Material.
  2. Export the file (or just save it if you're using blend files) and let Unity import the model.
  3. Back to blender, select the separated parts of the mesh, the object with the main material should be activated. Press Ctrl+J to join them.
  4. Export the file (or just save it if you're using blend files) and let Unity import the model. and done. Hope this helps.
$\endgroup$
1
  • $\begingroup$ a great solution, although, as far as my experience goes, it's only the steps 1 & 3 that are required here, and it's the order in which you select the parts while joining that is paramount here. Seems the Blender exports mesh parts in order dependent on when they were created in scene or something similar, and needs to have manual reordering in situation where it matters (it would also suggest that Unity retains the order from FBX correctly, so this behaviour would happen exclusively because of Blender). $\endgroup$
    – user213769
    Sep 4, 2022 at 16:56
0
$\begingroup$

The solution given by @Wneee works great in most cases, however a simpler solution is to simply go into Edit Mode, then under Mesh > Sort Elements... > Material and then select Faces as the elements. This will also result in the correct order of materials in Unity.

The issue occurs because for some reason the materials are sorted by their first occurrence in the mesh faces. Splitting and rejoining the submeshes results in the face order being in same order as the materials. The only downside to this is that the mesh might be split along vertices that are shared between two materials.

Just today I had a mesh where I wanted to sort the materials in Unity, but doing the split and rejoin trick caused it to render differently. While I'm unsure why the rendering was affected, I have found that sorting the elements didn't have this side effect since it doesn't create new vertices by cutting the mesh.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .