转自：http://www.xuanyusong.com/archives/3648
程序从svn上把工程更新下来，莫名其妙的多出了很多没上传svn的material文件。原因是这样的，如下图所示，美术同学把FBX文件拖入unity的时候。unity会自动在同级目录下生成一个Materials文件夹，里面会在生成一个material文件。而这个文件名是在FBX里指定的，换句话来说就是美术在3dmax里指定的。为什么会生成material，是因为默认这里勾选了import material。
如果有人告诉美术你的这个材质名字写错误需要更正一下，美术一般会投省事直接在unity里把这个错误的material删除，然后在unity里在创建一个名字正确的材质。接着美术会上传svn，问题似乎解决的天衣无缝。。可是另外一个人重新checkout一下这个工程，打开unity后错误的material文件又会被FBX重新生成出来，慢慢的项目里乱七八糟的材质就都出来了。。
为了解决这个问题，我想到了禁止fbx生成这个material文件，于是有了下面这段代码.
C#
usingUnityEngine;
usingSystem.Collections;
usingUnityEditor;
classDisableMaterialImport:AssetPostprocessor{
voidOnPreprocessModel()
{
ModelImporter modelImporter=assetImporter asModelImporter;
modelImporter.importMaterials=false;
}
}
可是问题紧接着来了，美术好不容易编辑好了场景，策划说调整一下模型吧。。于是乎换了新模型，糟糕！！因为新模型没关联上旧模型的材质信息。所以场景中材质都丢失了。。。 其实如果美术在编辑场景时都用prefab来做的话也不会这样，但是美术一般不会用prefab，他们做场景都是直接把fbx拖进去，如果发现材质不对那么在创建一个材质，如果需要复制多份儿他们就ctrl+d一下。。 所以一旦材质丢失后果不堪设想。
于是乎我又想到了一个办法，还是打开自动生成材质的开关。只是材质名必须和模型名保持一致，如果不一致程序就输出一个错误信息告诉美术。。于是乎又有了下面这样的代码。
using UnityEngine;
using System.Collections;
using UnityEditor;
classDisableMaterialImport:AssetPostprocessor{
voidOnPostprocessModel(GameObject model){
if(!assetPath.Contains("@")){
Renderer[]renderers=model.transform.GetComponentsInChildren<Renderer>();
for(inti=0;i<renderers.Length;i++){
if(renderers[i].sharedMaterial.name!=model.name){
Debug.LogError("材质名和模型名不匹配！");
//FileUtil.DeleteFileOrDirectory(Application.dataPath+assetPath.Replace("Assets",""));
AssetDatabase.Refresh();
break;
}
}
}
}
}
哎。我真是too young too simple！！ 什么提示警告啊， 提示错误啊，美术才不管这些呢。只要能导入unity，能上传svn 就OK了。。
所以还是老老实实把下面这段代码打开吧， 也就是如果FBX里材质名不正确，直接给他把模型删了，这样没有模型了自然美术就会想办法解决了，自然就会看Debug.LogError的信息了 哈哈！！
FileUtil.DeleteFileOrDirectory(Application.dataPath+assetPath.Replace(“Assets”,””));
那么如果你的项目模型是需要多个材质的，可以让美术在3DMAX里规定一个模型的默认材质比如model_0 然后model_1 model_2…. 则是在unity里创建的。
说了半天我们应该理解美术， 因为每个美术同学都是一个艺术家，艺术家喜欢干抽象的事，你非要让他干具体、严谨的事他们肯定也会出错的。所以作为程序我们还是要想办法帮助美术同学来避免错误。他们的错误率低，我们的活干的也就快也就爽。嘿嘿！ 另外如果你有更好的办法解决此类问题，欢迎再下面给我留言。。。
本文固定链接: http://www.xuanyusong.com/archives/3648
转载请注明: 雨松MOMO2015年09月14日 于 雨松MOMO程序研究院 发表
