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).
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?
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.
With this script one can modify the first material of a gameObject.
for (var go : GameObject in gos)
{
go.renderer.material = mat;
}
Trying to modify a specific element of the materials array of the renderer was not allowed:
for (var go : GameObject in gos)
{
go.renderer.materials[1] = mat;
}
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:
for (var go : GameObject in gos)
{
var l : int = go.renderer.sharedMaterials.Length;
for(var i = 0; i < l; i++)
{
if(...)
{
var tmp : Material[] = go.renderer.sharedMaterials;
tmp[i] = mat;
go.renderer.sharedMaterial = tmp;
}
}
}
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 * *var themats = go.renderer.materials themats[i] = ....; go.renderer.materials = themats;* * because all fields of go.renderer are otherwise read only
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…
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.
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)
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!