Multi Material ID

Hi,
I'm trying to work with a mesh with a multi material.
I've a set of models with 4 ID each
1234
and 4 relative materials in Unity to assign
1234

When I import the FBX (from Max), Unity assigns random materials only on some meshes. The courious fact is that they are all the same.
mesh1, ID 1234, Mat 1234
mesh2, ID 1234, Mat 1423
and so on...

The question is: is there a way to fix the Mat ID order of imported meshes manually? Because with Drag&Drop Unity does a mess swapping materials (again randomly).

Thanks!

 

have you tried baking the textures? thats working realy well for me atm.

 

hi timbo, thanks for the reply, but baking cannot work because I have to change at runtime some materials on ID 1.
My programmer says that it's impossible to reach this parameter from scripting too, is that possible that there is something unavailable by code?

 

There are no random assignements.
The modelling application likely is just not storing them in the same order causing the hickup.

And you can reach about anything of importance in that case through coding in Unity Pro

 

It's strange because in max file (source) the ID are ok and in Unity they are randomly messed up. But if we reimport the model in max (Unityzed) the ID are correct again. By the way we are swapping material using names and not the array#, that seems not working as we expect.

 

The problem is the following:

With this script one can modify the first material of a gameObject.

Code (csharp):

1.  
2. for (var go : GameObject in gos)  
3. {
4.   go.renderer.material = mat;
5. }
6.  

Trying to modify a specific element of the materials array of the renderer was not allowed:

Code (csharp):

1.  
2. for (var go : GameObject in gos)  
3. {
4.   go.renderer.materials[1] = mat;
5. }
6.  

The same was for the sharedMaterials array of the renderer. This obviously sounds strange but is how it is in reality.... I may understand that changing the materials array is not allowed since one gets just the Instance of the material, but being not allowed to change the material accessing the sharedMaterial array was crazy.

The workaround that i discovered is copying the whole sharedMaterials array of the renderer in a temp array, change the needed material in the temp array and finally copy the temp array into the sharedMaterials array of the renderer. For more clarity:

Code (csharp):

1.  
2. for (var go : GameObject in gos)  
3. {
4.   var l : int = go.renderer.sharedMaterials.Length;
5.   for(var i = 0; i < l; i++)
6.   {
7.     if(...)
8.     {
9.       var tmp : Material[] = go.renderer.sharedMaterials;
10.       tmp[i] = mat;
11.       go.renderer.sharedMaterial = tmp;
12.     }
13.   }
14. }
15.  

 

go.renderer is a property.
In such specific situations, at least in C#, you can not toy around with go.renderer.materials directly, you would have

Code (csharp):

1. var themats = go.renderer.materials
2. themats[i] = ....;
3. go.renderer.materials = themats;

because all fields of go.renderer are otherwise read only

 

It's exactly the same as I did even without knowing the details of it...

The point of being read only but however modifiable sounds a bit strange.....

Thanks

 

Hi lucaderiu!

Did you find a work around to this issue?? I´m having the same issue with a mesh that have 12 parts with 2 materials IDs; my programmer need that every piece have the same material in the ID 1... but for some odd reason Unity is messing up the model and 1 of the parts comes with the materials ID swapped! :S

I already checked in 3dsmax the IDs, they are fine and i even checked it at Motionbuilder and the same result... and even the ASCII fbx file. So it has to be the unity importer and haven´t found a solution yet...

Any help will be greatly appreciated!!

Thanks in advance!!

 

Hey Dakkon, I have exactly the same problem, have you resolved this issue?

 

Hi guys! I've been looking for a solution to this issue too and think I might have discovered an insight.

I have a bunch of meshes with two materials - the first material is the base, the second material is the 'light'. It's important that they're in slot 0 and 1 respectively (for my scripts)

But on one particular object, Unity decided the 'light' material should be first, royally screwing things up.

So I swapped ID's in MAX, but it stayed exactly the same. That's when I realised the material order corresponded to the mesh's face order. ie, whatever material "face #1" is using becomes the first material listed in Unity. I confirmed this by manually hunting down the first face and changing it to be the base material, and suddenly the order was right in Unity.

So it's true that the assignment is not 'random', but it seems possible that it is stupid. (considering face order is not something I can control as an artist)

 

damn that sounds really really ugly. One of our artists resolved it by splitting the model and reattaching it in the material order. Sounds like it could collaborate your findings.

Is there a open source alternative?

 

Damn I'm running into the same problem. it would be difficult to determine what face to look for each id, especially when your importing multiple models expecting to change specific material id's.

Examples:
head with hair on it. (Could be different on models)
chrome on car. (Would be different on models)

Is there any way to fix this?

 

Bump

Can one of the mods comment? I submitted a bug report, I'm just wondering if there are any intentions on changing the way this works. I can see ways to get around this, but it would be nice to have it work when you bring in the max file.

 

It's a bit late, but I have come over this exactly as PaulUsul's way, but de-attaching and reattaching them again usually ends up with face normals problem and also if there are a lot of submeshes, imagine how frustrating it can be to sort every submesh's name.

And if as Sycle says it takes the mesh's first face, so what happens to for example 4th material order?! and in this case what is material ID for then?

 

Is this problem still happening for fbx generated on 3dsmax files? It seems like I currently experience the same problem when I create an FBX from Maya file. Since Maya isn't based on a meterial ids system like Max, for Unreal we had to append a prefix at the end of our materials names to make sure Unreal would re-assign materials at the proper position in the array on re-importation.

Maybe I should use maya files instead and Unity will take them based on their alphabetical order like the hypershade does?

Do we have something similar for Unity? I'm surprised how few post we can find for this problem. I guess it's because peoples are mainly using only one material per object to save draw calls but how about PC developers?

Thanks for letting me know if there is anything to fix this issue!

 

I am interested in a solution to this, too.

 

2 hours lost because of this issue!!!
I think the sollution of the Paul Usul is the best - deteach and attach each part in desired order.
Thanks.

 

trzmiel Paul Usul , yes, I tried that, too, and finally solved the issue. (in 3ds max)

- Apply the material you want for Element 0 to everything
- Detach the parts that should have a different material
- then apply the other materials to the detached parts
- select the part again that has the material that should be the Element 0 material
- and attach in the desired order the other parts again.

 

Just in case anyone runs into this issue in the future and stumbles across this thread;

As of 2.75 you can reorder your materials in Blender and then reorder the mesh elements to match as per the helpful tutorial below.

http://blairwillems.com/2013/05/unity-and-blender-quick-tip-on-order-of-materials-during-import/

Hope this helps someone.

 

October 3rd 2017 15h30, the issue is still here, this is a joke. Materials IDs works the same in every 3D software, but not in unity of course. Maybe there is a good reason ?

Can you fix it or I have to purchase something on the asset store for 10$ to make it work properly ?

Thanks for the tips Tonyclifon Paul Usul it works but damn this is complicated.

 

Same problem (years later, this still an issue), we're moving to Unity but our workflow involves template materials that have set material ID's that all our artists use to unify the level visuals ....and Unity ignores the order they've modeled with!??

 

Pretty much.

 

Seems the way Unity imports FBX model is: all polys in order that they appear in the file, and assigns submesh indices from zero, as they are needed. That can be observed if ASCII FBX is loaded. There you will have these structures: (truncated example of simple box with 4 different materials)

....some properties and vertex coordinates first... and then info about polys:

PolygonVertexIndex: *24 {
a: 0,2,3,-2,4,5,7,-7,0,1,5,-5,1,3,7,-6,3,2,6,-8,2,0,4,-7

(meaning: poly0(0,2,3,1), poly1(4,5,7,6), poly2(0,1,5,4), poly3(1,3,7,5), poly4(3,2,6,7), poly5(2,0,4,6)... where numbers are vertex indices)

... then info about UVs, normals, ... and then crucial part:

LayerElementMaterial: 0 {
Version: 101
Name: ""
MappingInformationType: "ByPolygon"
ReferenceInformationType: "IndexToDirect"
Materials: *6 {
a: 1,0,3,3,1,2
}

(meaning: assigning materials: poly0 <- material[1], poly1 <- material[0], poly2 <-material[3], poly3 <-material[3] ... where this material array is defined further down in the FBX file)
And really with this example imported box in unity did have materials array in order Mat1,Mat0,Mat3,Mat2.

Maybe, as a workaround, this information could be used by game scripts for automatic material assignment.

Or maybe by some external script to rearange ASCII FBX and encode it to binary; but its structure is so complex, that could easily end up in error. It would be best if unity used this material information while importing.

For now I'm using little template mesh with 6 minuscule triangles (for 6 materials), that exports in correct order to Unity, and then attaching other complex models to that template. Since those first 6 polys create order of materials, other models can be attached, removed or modified in any order. It's not pretty but...

I'm sorry for the long post. I hope this helps someone.

 

We recently ran into this problem at my current job. We found a slightly simpler solution. Maybe it will help someone out.

After assigning all of your materials and getting your material IDs, you will need to detach each of the sub-object elements by their material ID. Make sure to leave the #1 Material ID as your main object.

***Edit*** It seems I forgot a step. After detaching the objects, you will then need to reapply each of the original materials back to each object. If you don't, it will keep the settings from the previous multi-sub material that was created. ***Edit***

Once you have reapplied the materials, one by one, reattach each object in the order you want their IDs to appear in Unity. Make sure to leave the first option checked when combining meshes:

This should have the desired effect of making your Unity Material IDs match your Max Material IDs. It's worked so far on the handful of objects we've needed to fix. Would love to have greater feedback if this is a 100% viable solution.

 

We have also ran into this issue. We tried having changeable materials on models based on material ids, where the materials for certain things would be identified by the material id. But as the material ids aren't imported in the same order as they are in max, we can't do this. Maybe an issue should be posted to the issue tracker about this? I can't imagine this is the way the importer is supposed to work.

 

Yup exactly what stated ! been trying to force this by maxscript for the last hour and whatever you try the ID list order is always linked based on the order you attached the models... because, well, autodesk logic ... Be also aware that you cannot set the ID in the Edit poly field "Set ID" without applying a new material on the faces. Thx a lot for refreshing my memory on those cheap fix solution of detach/attach !

 

I just came across this now. Unity 2018.3.0f2 and 3DSMax 2017. I fixed it as others have stated. In polygon selection mode, I used the Select ID button to select materials based on their IDs, and Detached them, one by one. Leaving only the root object with no mesh. Then using the Attach List feature, I reattached each piece in order of their Material IDs. Then welded verts. Then saved. That fixed it in Unity.

 

i need a 3ds max fbx have element 0 and its skinned mesh renderer i cant dettach and attach the eyes coz they broke, this is a big deception now im stuck and cant see a solution

 

And of course nobody from unity don't even care for aswering, and the problem still exist. But we care about the environment, children, and other s@#t, it's more important than fix the engine, of course.