实际问题描述
?????? 目前的导入方式，是将CATIA格式模型转为FBX格式，再导入到Unity3D中。在仿真过程的验证中发现，目前的模型占用资源很大，在运行加载过程中反应较慢，在一些性能不佳的计算机上甚至无法运行。另外如果能将模型轻量化，那么在计算机性能的支持下就可以提升3Dmaxs中的模型分辨率，增强模型在Unity3D中的仿真效果。
?图１ Skin Track (模型件和轨道的结合体)
思路分析
?????? CGR格式只保存了零件的外形信息，不包含任何参数化的数据，非常符合我们对模型特征的要求。结合04环轨自动钻铆机模型，对图1进行格式转换，并对转换后的FBX文件进行响应测试。FBX 格式是通用的转换格式。
?????? 将该文件另存为两个文件，一个是CATProduct格式，另一个是CGR格式。然后将两个文件都经过在3DMaxs中渲染，得到两个FBX文件。在比对二者的文件大小时，发现CGR格式导出的FBX文件明显比CATProduct格式大得多。（如图组2.2）
?
?图组2.2 两种CATIA模型FBX格式转换后内存大小
引出疑问：
- 为什么信息量少的CGR文件在渲染后得到的FBX文件却很大呢？
- 占用内存大，是不是评定模型复杂度确定的标准？或说模型在Unity中的响应运行速度与内存本身的大小关系是否有直接关系？与模型中包含的几何信息是否有直接关系？
- 将两类FBX文件导入到Unity3D中，二者的响应速度表现如何呢？是否存在利用内存换取速度的情况？
解决方法：
????? 通过测量模型导入到Unity中耗时和模型实例化响应耗时对比分析，可知FBX文件的大小直接决定了导入耗时和实例化响应耗时，并且基本符合正比关系，即不存在内存换取速度的情况。（具体测量数据如表１）也就是说如果轻量化模型经过3DMaxs渲染后FBX格式下文件反而变大了，那么在CATIA中的轻量化操作也就没有意义了。
表１ 导入和响应耗时时间统计
| 模型名称 | 文件大小 | 导入耗时(s) | 实例化耗时(ms) |
| Skin Track.FBX | 27.0MB | 15.93 | 3533.8 |
| Skin Track(Thin).FBX | 71.6MB | 42.76 | 16475.4 |
在多次尝试后发现，CGR文件转换成FBX格式时内存总是要比原CATIA格式转换成FBX格式时要大。（如表2所示）在尝试将CATProduct格式文件先转换成CATPart，再转换成CGR格式，最后转换成FBX格式的时候发现文件大小竟然基本吻合。（如表3所示）再次说明了原CATIA格式转FBX格式内存更小。而利用CGR格式进行轻量化模型，以达到减少Unity3D资源消耗的目标是不可行的。
表2 三种模型转FBX格式后占用内存大小对比（单位 KB）
| 模型格式/名 | Skin Track （CATProduct） | Skin of Equipment （CATPart） | Track of Equipment （CATProduct） |
| 原CATIA格式 | 951 | 31716 | 946 |
| 轻CGR格式 | 7136 | 6456 | 1182 |
| 原FBX格式 | 27729 | 4141 | 23561 |
| 轻FBX格式 | 73388 | 6390 | 65257 |
表3 两种CATIA格式转FBX格式后占用内存大小对比（单位 KB）
| 模型名／格式 | Skin Track（CATProduct） | Skin Track（CATpart） |
| 原CATIA格式 | 951 | 143484 |
| 轻CGR格式 | 7136 | 43055 |
| 原FBX格式 | 27729 | 27948 |
| 轻FBX格式 | 73388 | 72339 |
总结与思考
?????? 通过对比实验，我们发现由CATIA文件转换成的CGR轻量化文件，在转FBX格式时，所占内存空间反而会变大。我认为是CATIA文件与FBX格式之间的转换算法和CGR轻量化文件与FBX格式之间的转换算法不同导致的。
