Skip to main content

一些建模的规范化注意事项

在进行了制作前的准备后，实际上我们还需要在软件上注意一下比较容易出现问题的点，这些情况可能会在后续制作一些动画，导入Unity等出现异常，我们在前期操作必须避免这些！

比例！

软件层面：

先来点高血压图片：

image.png建模阶段非正确的拉伸缩放物体

image.png导入Unity后的错误拉伸

image.png

image.png

完成建模后导出阶段并未注意到建模软件与引擎两者的单位换算会出现的情况

我们必须要注意的第一点：我们正在制作的是一个资产，其作用是导入进Unity为你的世界添加细节，在建模阶段我们首先要保证的就是其变换必须为默认情况（Transform，包括移动0.0  旋转0.0  缩放1.0）。并且在导出再导入进Unity的变换也为默认，这才是我们的首要目标，也是最不会出错的情况.

在进行整体建模（例如房屋外形）导出时，可以不注意平移属性。

image.png

这只是一些多软件工作流需要注意的软件层面的“比例”，当然，我们还需要注意的是我们准备建模的这个模型的“比例”

模型层面：

首先，我们首要确定的就是我们建模软件软件里的比例，这里依旧拿Maya举例：

image.png  image.png

窗口  - 设置/首选项 - 首选项 - 设置 - 工作单位

我们首先要确认的就是Unity中的工作（默认）单位，在我们经过搜索或尝试确认后能够知道是“米”，也就是说，我们在建模阶段为了和最终导入到Unity中比例不变，那我们最好的情况也是将建模软件中的工作单位首选项也设置成“米”。当然，这似乎并不一定正确......

就像Maya，如果为了避免工作单位设置成米后，导出到Unity中出现缩放变为100，我们需要在FBX导出设置的单位自动取消勾选，并且将文件单位转换为厘米，但是如果是默认工作单位厘米的话，我们在导出设置的单位设置就不需要这一步骤。

拓展：为什么FBX文件格式这么奇怪？似乎在Maya中，Blender中，甚至别的软件中导出都会或多或少出现一些些的小问题？      首先，FBX（FilmBox）格式是Autodesk自己的闭源中间格式，同时也是人家自己的知识产权，因为闭源也就导致了跨软件兼容性问题（最首要的也是影响最大的就是Blender，不难发现Blender在导入导出各种各样的FBX文件真的很容易出现各种各样的问题）；甚至FBX文件也是有版本的，不同版本FBX在软件上也会有各种各样的兼容性问题。                                                                那为什么不改用一些其他的中间格式来存储这些3D资产呢？（最经典的比如GLTF，ABC）                                                  Autodesk毕竟存在许久，其软件与一些设计规范早就成为业内的规范，从影视行业到游戏行业各种软件都对Autodesk软件或其格式做着适配与数据交换，你再找别的格式就很难找到这么通用的中间格式。随着更多更好用的格式与规范普及，或许在以后这个地位真的会被撼动。                                                                                                                                                                          FBX的格式问题：早期影视方面的应用中，厘米是最常见的单位标准，所以FBX格式也就沿用了下去。                                          那为什么我们要设置这么麻烦的单位转换？或者为什么如果我导出时不以厘米为标准就会出现比例问题？                                    首先，我们举一个正确导入导出的例子：我们在maya中创建了一个1*1*1米的立方体，我们导出设定FBX单位为厘米，那么这个FBX储存的单位就是100厘米，这个时候我们再导入到Unity，Unity知道FBX这个格式默认是厘米，所以在导入的时候会默认将100厘米再次转换成1米，这样的导入将是最完美的情况。                                                                                                                      那么错误的导出情况呢？这个时候我们在导出的时候设置了FBX单位为米，但是在导入到Unity中的时候，Unity认为这个模型是1厘米，因为错误的单位判断，Unity就会让其缩放比例因子放大至100，同样的，缩放比例因子为0.01也是一样的情况。

言而总之，软件内的工作单位是否是米（同步Unity工作单位）影响并不大，根据个人而言自行调整（我个人而言是毕竟喜欢把工作单位同步Unity的），最重要的是导出设置，它决定了你在导出后导入Unity中缩放比例是否正确。

image.png

命名与分组：不仅是对你，对你的团队友好

首先，在制作单一资产时，我仍建议一体化，即单模型导出，在可能存在需要制作动画或特殊需求的情况下是可以分组的，但也仍需注意分组的命名与按作用来区分父子级等。

对于命名方法，如果有团队则自行商议，如果个人我建议根据如下命名法则：

  • 完全避免特殊字符，空格，中文：因为各软件兼容性不同或操作系统问题，请完全避免这些，如需空格区分单词则以下划线（_）或以大小驼峰命名法命名。(如命名附带版本或LOD记录最好以下划线分割)

正确示例：

Apple_Red
AppleRed
appleRed
  • 如果你需要制作LOD模型示例：
Apple_Red
├── LOD0 
├── LOD1 
└── LOD2
  • 引擎内导入资产文件夹命名与分组示例：
Assets/
├── Characters/
│   ├── Apple_Girl/
│   │   ├── Meshes/
│   │   ├── Textures/
│   │   ├── Animations/
│   └── └── Materials/  
├── Environment/
│   ├── MyHouse/
├── Props/
│   └── Apple_Blue/
├── Prefabs/
│   └── Apple_Blue/
Assets
├── Mesh
│   └── Apple
├── Texture
├── Material
├── Prefabs
└── collision

 

没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完没写完

世界坐标系，对象坐标系，

No Comments
Back to top