尧图网页设计 
简介一份以《死神》为案例的三维角色资源制作规范文档面向游戏或动画项目的建模师、贴图师及美术团队管理者。内容完整覆盖从原画分析、模型重建、UV展开、贴图绘制到文件命名和后期检查的流程并给出关键参数人物角色与武器三角面控制在1500至2000面复杂角色放宽到2500面大型BOSS可在3000至5000面贴图采用tga格式先以1024分辨率绘制最终缩小到512并锐化角色与武器共用一张贴图命名规则如yihu_b.max、dongshilang_t.tga。文档还重点强调关节布线、多余点焊接、材质球统一命名、模型尺寸以厘米为单位、坐标轴归零以及光滑组设为1等优化细节能帮助读者建立规范意识、减少返工提高角色资产在建模、绑定、贴图等环节间的协作效率。压缩包内为1个docx文档整体约4.89MB便于查阅目前已有110人学习下载。1. 3D角色资源制作规范到底在管什么一份文档解决的三类返工在游戏、影视和实时渲染项目里3D角色资源是所有管线中最容易“翻车”的环节——不是因为建模难而是因为每个人对“做完”的定义不一样。模型师按自己的习惯建了高模绑定师发现骨骼命名对不上TA调材质时贴图后缀不统一程序侧加载进引擎发现缩放比例错了一百倍。这些问题的根源不是某个人的技术不行而是整个团队缺少一份可执行的3D角色资源制作规范.docx把“角色资产必须满足哪些硬性条件”写清楚、锁死。这份文档解决的从来不是单个角色的制作问题而是多人协作时反复出现的三类返工格式不统一导致的导入失败、命名混乱导致的流程断裂、以及精度标准缺失导致的视觉效果不一致。它本质上是一份跨角色分工的交接契约。适用对象也很明确小型独立团队在人数扩张后需要对外包提需求中型项目组要在Unity和UE之间统一资产标准以及任何被“为什么我导出的模型在引擎里灰了”这类问题反复折磨的人。接下来我按从文档内容到落地检查的顺序把这份规范拆开讲。2. 先把基础字段写死单位、命名与目录结构是后续一切的前提2.1 为什么“单位”和“缩放”是规范里最先要定的规则我见过最离谱的一次翻车是外包发来的角色模型在Maya里看是正常的导进Unity整个人物缩成了一粒芝麻。查了两小时发现对方场景单位是厘米我们约定的是米FBX导出时又勾选了“自动缩放”引擎按文件头里的单位信息做了二次换算。所以任何一份3D角色资源制作规范第一步必须锁死两件事场景单位和轴向。常见做法是统一使用厘米作为工作单位轴向设为Y轴向上因为这是Maya和3ds Max的默认取向也是FBX格式最稳定的姿态。规范里要明确写“所有DCC软件中Grid Snap和Unit Snap必须为1单位 1厘米”并禁止在导出时勾选或依赖“自动缩放”选项——这个选项的存在本身就意味着“不同单位制之间的自动换算”而自动换算在两个不同单位制的软件之间传递时很容易把角色打断。轴向之外还有比例参考。角色身高、肩宽、臂长这些骨骼比例数据应该由项目组在规范附件里给出一份“角色体型参考表”哪怕是简单的“身高180cm肩宽45cm臂展80cm”。因为角色模型师在缺乏参考时很容易按审美把比例拉长或压扁绑定师拿到手才发现手臂长度影响骨骼旋转半径动画师调动作时又发现重心位置不对。规范中我一般会给出三档模板写实男性、写实女性、卡通Q版每档明确身高和比例系数。这样模型师拿到手就能对位而不是靠经验和感觉。2.2 命名规范前缀、后缀与“禁止使用”清单命名是整份文档里最朴素但也最容易被无视的章节。没有命名规范等于把资产追溯变成了“手动翻文件夹猜是谁做的”。我在规范里一般把命名拆成三段式资产类型前缀_角色名_部件/用途后缀。比如写实角色“Knight”的头部网格就是mesh_Knight_Head它的高模是mesh_Knight_Head_High低模是mesh_Knight_Head_Low。贴图命名在下一章细说这里先强调网格和骨骼。骨骼命名更要严格因为它直接影响蒙皮数据和动画重定向。规范中要交代“所有骨骼必须使用Biped_或Joint_作为前缀控制器使用Ctrl_末尾加_L/_R区分左右”比如Joint_Shoulder_L、Ctrl_Hand_R。同时要有一个明确的“禁止使用”清单禁止使用默认的Bone001/Joint1这类名称禁止使用中文或带空格的名字禁止改名后不更新蒙皮数据。如果你还允许骨骼在建模软件里随意移动绑定阶段一定会因此翻车。2.3 目录结构文件路径分层决定项目后期好不好维护文件结构本身直接决定管理和交接效率。规范里需要固定一个“资产根目录”的骨架团队所有成员提交文件时遵循同样层级Assets/Characters/ └── Knight/Warrior/... 角色名 ├── Model/ # 原始模型文件 .ma/.max/.blend ├── Mesh/ # 导出用网格 .fbx ├── Textures/ # 贴图输出目录 ├── Materials/ # 材质预设或 .mat 文件 └── Rig/ # 绑定文件 .fbx/.rig这段目录结构对应的核心逻辑原始文件与导出文件分离。Model里的.ma是工作档案.fbx是交接给上下游的产物。如果两者混放就会出现“改了模型但导出的FBX还是旧版”的低级错误这在多人协作项目里已经反复发生过多次。我的建议是规范文档中除了文字描述还要配一张目录树截图作为“标准答案”放在附录中因为文字描述远不如一张图直接外包和新人进来对照着摆放即可。3. 网格与UV规范拓扑、接缝和贴图密度直接决定角色在屏幕上的质感3.1 三角形预算移动端和PC端的标准差异角色好不好看很大程度由网格的三角形面数预算决定。规范里必须针对目标平台给出不同档位的参考值而不是笼统地说“能用就行”。我常写的一组参数是移动端主角色低模不超过30000个三角形次角色不超过15000个PC端主角色低模可以给到50000到80000个三角形。但要注意“低模”在这里是相对高模而言不等于“可以随意加线”。高模用于细节烘焙一般在百万三角面以上但最终进引擎的一定是低模加法线贴图。规范里要强调高模只用于离线烘焙永远不要直接导出进入引擎否则不仅渲染压力大而且顶点数超标的资产还会拖慢整个场景的加载与裁剪。顺便一提现在许多角色直接从ZBrush雕刻出来带了大量细分网格如果不做减面处理直接丢进引擎效果等同于场景里塞了一颗噪点炸弹。规范中我建议附上减面工具类的操作备注保留五官轮廓与服装边缘的走线减掉手指之间不可见的区域、口腔内部、以及背部大平面的多余分段。这样写的目的是让模型师明白减面不是“无脑删点”而是要有目的地规划。3.2 拓扑结构规范哪里能三角化哪里必须保持环形边拓扑本身没有绝对正确但有“更适合动画和绑定”的结构。规范中需要特别注明几个关键部位的拓扑要求肩部、胯部、膝盖、手肘这些关节处必须保持环形边因为环形边能在蒙皮权重计算时提供更平滑的形变过渡。而如果这些位置出现不规则的三角面绑定时权重分配会受牵制动画时容易产生“肩部塌陷”或“膝盖起角”的形变问题。另一个经常被忽略的是“无限Z轴3D打印机”那种面向打印的场景类型但在我们当前讨论的实时渲染角色资源里需要补充的是非可视区域三角面。比如口腔内部、牙齿背面、眼睑内侧如果不需要特写镜头这些区域要么删除、要么用简单的平面代替即可。规范中写明“眼睛与口腔内部在不参与特写镜头的前提下允许使用低精度平面或直通面”直接为模型师省去不必要的细分工作量。这一步做的越清楚渲染和烘焙时出现“模型闪面”的概率就越低。3.3 UV布局与接缝规则烘焙法线贴图时的四个边界坑UV布局看似简单实则是最容易发生“烘焙出黑线、接缝处偏色”等玄学问题的源头。规范中我要求每个角色道具的UV必须展开在0到1象限内并在原本第2象限保留一个“用于光照贴图”的空白通道以兼容部分引擎需要Lightmap UV的情况。纹素密度TEXEL必须按平台设定移动端控制在1024px/mPC端控制在2048px/m以上。UV接缝要尽可能藏在角色的内侧或视线不易察觉的区域例如头部接缝沿后脑勺中线走四肢接缝沿内侧走不要出现在脸部正中央或肩胛骨的轮廓线上。烘焙法线贴图的接缝处常出现硬边或黑缝这四条是高频踩坑点第一坑UV边界未加缝合边处理直接硬切导致法线方向断裂。解决方式是在DCC软件中把UV boundary设为Smooth或做好颜色编码。第二坑低模与高模的对应关系没对齐烘焙时低模的面片穿出或陷入高模。解决方式是检查包裹修改器的包裹距离参数通常在0.05到0.1厘米之间设置。第三坑共享UV空间导致两张贴图相互重叠烘焙结果出现“展示性花纹交错”。解决方式是给每个部件分配独立的UV象限区域避免两个对象共用一个棋盘格。第四坑法线贴图的绿色通道在Maya和UE之间翻转。现象是角色身上出现“内凹式高光”原因是OpenGL与DirectX对法线Y轴方向的定义不同。解决方式是导出时在Substance Painter里设定目标平台格式而不是等到引擎里再手动翻转。我在规范里通常会直接要求贴图输出时颜色、粗糙度、法线三张图必须从Substance Painter或同类软件中按预设模板导出法线以DirectX格式为默认UE用户无需额外翻转Unity用户也只需在导入设置里勾选对应选项即可。4. 材质命名与引擎落地从Substance Painter到Unity/UE的参数对应4.1 贴图命名规则一套能跨引擎迁移的通用后缀组合许多新人容易犯的一个错误是贴图命名与网格命名脱节。在规范中我固定了一种格式角色名_部件_贴图用途比如Knight_Head_BaseColor、Knight_Head_Normal、Knight_Head_Roughness。这套命名习惯能直接兼容Unity的自动材质识别和UE的资产命名约定。粘贴图时只要按规则重命名导入到引擎后就能自动匹配到正确的材质通道不需要每次手动指定。另外规范里要强调“禁止使用中文、空格和连续下划线”因为这些字符在某些引擎或中间格式下会出现无法预测的导入失败。用连字符-替代空格是可接受的。同时贴图规格也要在文档里写死身体部分的颜色贴图漫反射尺寸至少2048x2048px脸部可以升级到4096x4096px以保留面部细节法线贴图和粗糙度贴图使用与颜色贴图相同的分辨率金属度贴图通常合并进RMARoughness/Metalness/AO一张图里以减少纹理采样次数和内存占用。我一般会给出一个RMA打包方案R通道存粗糙度、G通道存金属度、B通道存环境光遮蔽。这套方法兼容性很广既适合Unity的Standard Shader也适合UE的PBR材质模型。4.2 材质球设置与PBR属性说明要让模型在引擎里呈现符合预期的质感仅靠贴图还不够材质球上的参数设置同样扮演关键角色。在Unity中我建议使用Universal Render Pipeline/Lit或HDRP/Lit材质把Smoothness设为从Roughness贴图的R通道反向输入Metallic设为金属度通道的G通道AO设为环境光遮蔽通道。UE中则是把Roughness、Metallic、Ambient Occlusion分别对应到对应贴图输入。这套映射关系既是PBR的物理基础也是后期调整光照时最容易反查的参数。如果没有这套统一规范在Substance里看着正常的材质一到引擎里就变成“塑料感”“油腻感”因为色彩空间和通道映射各自为政。4.3 引擎导入FBX时的参数预设引擎导入环节是整个链条里最容易“翻车”的地方原因是大多数DCC工具导出FBX时的默认设置并不适合实时渲染角色。我先给出一套可直接照抄的配置Unity中FBX导入参数按如下设置Scale Factor1单位切换File Scale Conversion已勾选时将Source源单位设为Centimeter厘米材质导入不勾选“Extract Materials”之前的自动创建材质规范做法是取消勾选“Use External MaterialsLEGACY”改用外部材质关联动画类型如果角色由动画系统控制选Humanoid如果只有骨骼层级需要保留选Legacy或Generic法线与切线保留原值不要勾选Swap UVs否则法线朝向会异常UE中导入FBX时骨骼层级关掉“Auto Generate Collision”避免多出额外物理形状法线导入选择Import Normals让引擎直接读取DCC中导出的法线而非重新计算材质导入UE默认会为每个材质插槽创建一个材质实例建议关闭“Create Materials”在引擎内部手动关联已配置好的材质资产这两套设置针对的是同一个角色资源差别在于引擎对坐标系Unity左手系、UE右手系和单位标准Unity默认米、UE默认厘米的处理方式。规范中应该固定一套“引擎侧导入参数表”作为引擎使用者的操作指南。这远比在文档里写“按默认设置导入”更有意义。5. 角色资产避坑清单5个高频返工现场5.1 坑位一模型在Maya里正常在引擎里变换位置偏移现象FBX导入引擎后角色枢轴点不在脚底而在世界坐标原点或模型中心导致动画位移时整个人物凭空抬高或漂移。这个问题的原因是模型师导出前忘了冻结变换模型上的平移、旋转、缩放数据仍然保留FBX导入后引擎读取了这些变换值导致坐标系翻转或位置偏移。解决方式是在规范中要求所有角色模型导出前执行“冻结变换、重置枢轴”并在导出后用一个简单的检查脚本或人工检查来确认枢轴位置。这一步写在文档里只是两句话但能省下大量后期手动修正的时间实际执行率超过八成的团队都在这里交过学费。5.2 坑位二贴图在Substance里正常引擎里发灰发暗现象角色进入引擎后材质整体灰蒙蒙高光区域几乎消失金属部分发暗。这个问题的根源通常是色彩空间设置不一致颜色贴图被当作线性空间数据Linear导入了而正确的操作是标记为sRGBGamma空间。在实时渲染管线里颜色贴图与法线/粗糙度贴图遵循不同的色彩空间规则一旦设置错整个PBR结果会偏移。解决方式是规范中明确“BaseColor/Diffuse贴图导入时勾选sRGB法线、粗糙度、金属度、AO贴图设为Linear”并允许TA或者技术美术在引擎里检查贴图导入选项避免人工反复尝试。5.3 坑位三动画和模型匹配不上动作错位现象动画师单独预览骨骼动画时动作正常但套到角色模型上之后手指、手腕或脚踝出现明显的偏移或穿透。原因一般是模型与骨骼的T-Pose不一致绑定师在A模型中设置了T-Pose动画师在B模型上编辑动作时使用的是另一个T-Pose导致骨骼旋转初值不同。解决方式是在规范中把“T-Pose必须是标准姿势手臂水平展开约45度、手掌朝下、两脚与肩同宽”写明并附带一张标准T-Pose截图和骨骼层级截图。这是文档里最不好用文字表达的部分但又是必须锁死的部分因为骨骼的重定向完全依赖T-Pose的初始匹配。实践里我们还会要求动画师在动捕之前先对模型的骨骼层级做一次对比测试确保两套骨骼的命名和结构完全一致。5.4 坑位四法线贴图方向不对角色出现“内凹式”高光现象角色身上受光后出现类似“凹陷”的奇怪明暗变化比如鼻子看起来像塌陷肌肉轮廓混乱。这个问题的原因是法线贴图的绿色通道Y轴在DCC与引擎之间存在方向差异这在OpenGL和DirectX格式之间是个典型坑。解决方式是在Substance Painter中统一使用DirectX格式导出法线贴图然后把UE默认的DirectX作为标准如果对接Unity则在导入设置里勾选“Flip Green Y”选项即可。规范中还需要补充一句法线贴图导入时不要与其他贴图一起勾选sRGB选项否则等于同时犯色彩空间和通道方向两个错误视觉效果会更加混乱。5.5 坑位五角色LOD时出现破面和闪烁现象远处角色切换LOD级别时边缘出现闪烁、破面和明显的轮廓跳变。原因是连续LOD之间顶点位置不一致或者说LOD减面时保留的轮廓顶点不统一。当游戏运行时LOD切换的一瞬间人的视觉会捕捉到轮廓变化。解决方式规范中要求制作LOD时不能只依赖自动减面工具必须把相邻LOD的关键结构点锁住例如下颌线、眼眶最高点、肩峰、指尖这些决定外轮廓的位置。如果发现有LOD衔接问题优先检查模型法线方向以及UV是否在减面过程中被重新投射。自动减面工具生成的LOD通常不会保留原UV但规范里要求“相邻LOD的UV必须完全一致”这样在切换时材质不会跳动光照也不会闪烁。6. 把规范从文档变成工具链用脚本自动校验资产命名与提交完整性6.1 用Python写一个基础命名检查脚本文档写得再好人肉核对永远是低效的。规范落地到项目的最终形态应该是一套版本的“自动检查工具”。我在实际项目管理中会写一个简单的Python脚本在角色资产提交前自动扫一遍目录检查命名格式、贴图后缀和FBX文件是否正确。下面的代码是一个可以套改的示例import os import re # 定义规范要求 PREFIX_RULES [mesh_, tex_, rig_] # 允许的前缀 ALLOWED_TEXTURE_SUFFIX [_BaseColor, _Normal, _Roughness, _Metallic, _AO] MESH_SUFFIX [_Low, _High, _LOD0, _LOD1, _LOD2] def check_asset_name(filename): # 检查是否符合命名规则返回 (布尔, 原因) if re.search(r[\u4e00-\u9fa5\s], filename): return False, 文件名包含中文字符或空格 if not any(filename.startswith(prefix) for prefix in PREFIX_RULES): return False, f缺少前缀应为 {PREFIX_RULES} if filename.endswith(.fbx): if not any(filename.replace(.fbx, ).endswith(suffix) for suffix in MESH_SUFFIX): return False, f网格文件缺少 LOD 或精度标识 {MESH_SUFFIX} if filename.endswith(.png) or filename.endswith(.tga): if not any(filename.replace(.png, ).replace(.tga, ).endswith(suffix) for suffix in ALLOWED_TEXTURE_SUFFIX): return False, f贴图缺少用途后缀 {ALLOWED_TEXTURE_SUFFIX} return True, OK if __name__ __main__: import sys asset_folder sys.argv[1] if len(sys.argv) 1 else . for root, dirs, files in os.walk(asset_folder): for f in files: result, reason check_asset_name(f) if not result: print(f[FAIL] {os.path.join(root, f)}: {reason}) else: print(f[ OK ] {os.path.join(root, f)})这段脚本的逻辑很简单遍历资产目录下所有文件根据后缀匹配前缀、名称中是否含中文/空格、以及贴图用途后缀是否齐全。注意它不检查文件内容只检查文件名。它的价值在于把“规范”变成“可执行的约束”让每个人在提交前先跑一遍而不是靠美术自己记着翻规范文档。你可以在脚本里加一个“白名单机制”例如Knight_Head_BaseColor.png之类的名称实际项目里那些按规矩命名却没有匹配上格式的名称可以通过白名单快速通过检查。6.2 关键校验点检查FBX网格体是否包含隐藏骨骼或多余节点除了命名FBX文件内容本身还需要一个检查脚本或引擎侧插件来做校验。最有效且最简单的校验方式之一是检查FBX中是否存在隐藏的、未使用的骨骼节点。隐藏骨骼通常源自建模软件里残留的辅助控制器或空物体导入引擎后可能会出现“模型漂浮着一根根骨骼线框”的现象虽然不影响渲染但会污染绑定层级拖慢运行时骨骼更新开销。解决方式是脚本用FBX SDK读取节点列表筛选出无蒙皮权重且无动画引用的节点进行记录。实际工作中这类问题常出现在外包交付的FBX里所以脚本的做法就是在提交前跑一遍列表把这些多余节点全部拉出来输出为纯文本清单提示美术在DCC里手动清理。6.3 最终验证打包提交前做可视化渲染对比在项目收尾阶段我习惯把最终角色放入一个标准的“验证场景”统一打三盏光主光、辅光、轮廓光并在引擎里截图对比角色在灰模状态、贴图完整状态下、以及LOD切换状态下的实时表现。这一步的目的是排除材质外观的“玄学因素”——光照环境一变角色质感就会变化不能只靠美术口口相传“看着没问题”。通过截图存档大家能够直观对比不同版本之间角色的视觉差异。这也是我在项目中比较坚持的习惯因为很多时候返工不是因为模型或贴图本身有问题而是因为不同人所处的光照环境不同导致对“是否达标”的判断不同。用一套固定验证环境定标准能极大减少这类争议。坦白说我从一开始也不习惯做这种“死板”的规范文档和检查脚本总觉得多做一步检查很麻烦。直到有一次外包交付了整套角色从命名到贴图通道全不符合规范我们整个组花了一周来手动调整和重新导入我才意识到规范文档的价值不在文档本身而在它能否成为团队共识并转化为自动检查的工具。一份好的3D角色资源制作规范.docx写完之后应该让人人都能照着做、做得一致而不是成为束之高阁的摆设。如果你也在带项目我的建议是先花一个下午把单位、命名和目录结构定好再花一天把验证脚本写出来其余内容可以随项目逐步补充。希望帮到你。本文还有配套的精品资源点击获取 3D角色资源制作规范全解析：从命名、UV到FBX导入的避坑指南
简介一份以《死神》为案例的三维角色资源制作规范文档面向游戏或动画项目的建模师、贴图师及美术团队管理者。内容完整覆盖从原画分析、模型重建、UV展开、贴图绘制到文件命名和后期检查的流程并给出关键参数人物角色与武器三角面控制在1500至2000面复杂角色放宽到2500面大型BOSS可在3000至5000面贴图采用tga格式先以1024分辨率绘制最终缩小到512并锐化角色与武器共用一张贴图命名规则如yihu_b.max、dongshilang_t.tga。文档还重点强调关节布线、多余点焊接、材质球统一命名、模型尺寸以厘米为单位、坐标轴归零以及光滑组设为1等优化细节能帮助读者建立规范意识、减少返工提高角色资产在建模、绑定、贴图等环节间的协作效率。压缩包内为1个docx文档整体约4.89MB便于查阅目前已有110人学习下载。1. 3D角色资源制作规范到底在管什么一份文档解决的三类返工在游戏、影视和实时渲染项目里3D角色资源是所有管线中最容易“翻车”的环节——不是因为建模难而是因为每个人对“做完”的定义不一样。模型师按自己的习惯建了高模绑定师发现骨骼命名对不上TA调材质时贴图后缀不统一程序侧加载进引擎发现缩放比例错了一百倍。这些问题的根源不是某个人的技术不行而是整个团队缺少一份可执行的3D角色资源制作规范.docx把“角色资产必须满足哪些硬性条件”写清楚、锁死。这份文档解决的从来不是单个角色的制作问题而是多人协作时反复出现的三类返工格式不统一导致的导入失败、命名混乱导致的流程断裂、以及精度标准缺失导致的视觉效果不一致。它本质上是一份跨角色分工的交接契约。适用对象也很明确小型独立团队在人数扩张后需要对外包提需求中型项目组要在Unity和UE之间统一资产标准以及任何被“为什么我导出的模型在引擎里灰了”这类问题反复折磨的人。接下来我按从文档内容到落地检查的顺序把这份规范拆开讲。2. 先把基础字段写死单位、命名与目录结构是后续一切的前提2.1 为什么“单位”和“缩放”是规范里最先要定的规则我见过最离谱的一次翻车是外包发来的角色模型在Maya里看是正常的导进Unity整个人物缩成了一粒芝麻。查了两小时发现对方场景单位是厘米我们约定的是米FBX导出时又勾选了“自动缩放”引擎按文件头里的单位信息做了二次换算。所以任何一份3D角色资源制作规范第一步必须锁死两件事场景单位和轴向。常见做法是统一使用厘米作为工作单位轴向设为Y轴向上因为这是Maya和3ds Max的默认取向也是FBX格式最稳定的姿态。规范里要明确写“所有DCC软件中Grid Snap和Unit Snap必须为1单位 1厘米”并禁止在导出时勾选或依赖“自动缩放”选项——这个选项的存在本身就意味着“不同单位制之间的自动换算”而自动换算在两个不同单位制的软件之间传递时很容易把角色打断。轴向之外还有比例参考。角色身高、肩宽、臂长这些骨骼比例数据应该由项目组在规范附件里给出一份“角色体型参考表”哪怕是简单的“身高180cm肩宽45cm臂展80cm”。因为角色模型师在缺乏参考时很容易按审美把比例拉长或压扁绑定师拿到手才发现手臂长度影响骨骼旋转半径动画师调动作时又发现重心位置不对。规范中我一般会给出三档模板写实男性、写实女性、卡通Q版每档明确身高和比例系数。这样模型师拿到手就能对位而不是靠经验和感觉。2.2 命名规范前缀、后缀与“禁止使用”清单命名是整份文档里最朴素但也最容易被无视的章节。没有命名规范等于把资产追溯变成了“手动翻文件夹猜是谁做的”。我在规范里一般把命名拆成三段式资产类型前缀_角色名_部件/用途后缀。比如写实角色“Knight”的头部网格就是mesh_Knight_Head它的高模是mesh_Knight_Head_High低模是mesh_Knight_Head_Low。贴图命名在下一章细说这里先强调网格和骨骼。骨骼命名更要严格因为它直接影响蒙皮数据和动画重定向。规范中要交代“所有骨骼必须使用Biped_或Joint_作为前缀控制器使用Ctrl_末尾加_L/_R区分左右”比如Joint_Shoulder_L、Ctrl_Hand_R。同时要有一个明确的“禁止使用”清单禁止使用默认的Bone001/Joint1这类名称禁止使用中文或带空格的名字禁止改名后不更新蒙皮数据。如果你还允许骨骼在建模软件里随意移动绑定阶段一定会因此翻车。2.3 目录结构文件路径分层决定项目后期好不好维护文件结构本身直接决定管理和交接效率。规范里需要固定一个“资产根目录”的骨架团队所有成员提交文件时遵循同样层级Assets/Characters/ └── Knight/Warrior/... 角色名 ├── Model/ # 原始模型文件 .ma/.max/.blend ├── Mesh/ # 导出用网格 .fbx ├── Textures/ # 贴图输出目录 ├── Materials/ # 材质预设或 .mat 文件 └── Rig/ # 绑定文件 .fbx/.rig这段目录结构对应的核心逻辑原始文件与导出文件分离。Model里的.ma是工作档案.fbx是交接给上下游的产物。如果两者混放就会出现“改了模型但导出的FBX还是旧版”的低级错误这在多人协作项目里已经反复发生过多次。我的建议是规范文档中除了文字描述还要配一张目录树截图作为“标准答案”放在附录中因为文字描述远不如一张图直接外包和新人进来对照着摆放即可。3. 网格与UV规范拓扑、接缝和贴图密度直接决定角色在屏幕上的质感3.1 三角形预算移动端和PC端的标准差异角色好不好看很大程度由网格的三角形面数预算决定。规范里必须针对目标平台给出不同档位的参考值而不是笼统地说“能用就行”。我常写的一组参数是移动端主角色低模不超过30000个三角形次角色不超过15000个PC端主角色低模可以给到50000到80000个三角形。但要注意“低模”在这里是相对高模而言不等于“可以随意加线”。高模用于细节烘焙一般在百万三角面以上但最终进引擎的一定是低模加法线贴图。规范里要强调高模只用于离线烘焙永远不要直接导出进入引擎否则不仅渲染压力大而且顶点数超标的资产还会拖慢整个场景的加载与裁剪。顺便一提现在许多角色直接从ZBrush雕刻出来带了大量细分网格如果不做减面处理直接丢进引擎效果等同于场景里塞了一颗噪点炸弹。规范中我建议附上减面工具类的操作备注保留五官轮廓与服装边缘的走线减掉手指之间不可见的区域、口腔内部、以及背部大平面的多余分段。这样写的目的是让模型师明白减面不是“无脑删点”而是要有目的地规划。3.2 拓扑结构规范哪里能三角化哪里必须保持环形边拓扑本身没有绝对正确但有“更适合动画和绑定”的结构。规范中需要特别注明几个关键部位的拓扑要求肩部、胯部、膝盖、手肘这些关节处必须保持环形边因为环形边能在蒙皮权重计算时提供更平滑的形变过渡。而如果这些位置出现不规则的三角面绑定时权重分配会受牵制动画时容易产生“肩部塌陷”或“膝盖起角”的形变问题。另一个经常被忽略的是“无限Z轴3D打印机”那种面向打印的场景类型但在我们当前讨论的实时渲染角色资源里需要补充的是非可视区域三角面。比如口腔内部、牙齿背面、眼睑内侧如果不需要特写镜头这些区域要么删除、要么用简单的平面代替即可。规范中写明“眼睛与口腔内部在不参与特写镜头的前提下允许使用低精度平面或直通面”直接为模型师省去不必要的细分工作量。这一步做的越清楚渲染和烘焙时出现“模型闪面”的概率就越低。3.3 UV布局与接缝规则烘焙法线贴图时的四个边界坑UV布局看似简单实则是最容易发生“烘焙出黑线、接缝处偏色”等玄学问题的源头。规范中我要求每个角色道具的UV必须展开在0到1象限内并在原本第2象限保留一个“用于光照贴图”的空白通道以兼容部分引擎需要Lightmap UV的情况。纹素密度TEXEL必须按平台设定移动端控制在1024px/mPC端控制在2048px/m以上。UV接缝要尽可能藏在角色的内侧或视线不易察觉的区域例如头部接缝沿后脑勺中线走四肢接缝沿内侧走不要出现在脸部正中央或肩胛骨的轮廓线上。烘焙法线贴图的接缝处常出现硬边或黑缝这四条是高频踩坑点第一坑UV边界未加缝合边处理直接硬切导致法线方向断裂。解决方式是在DCC软件中把UV boundary设为Smooth或做好颜色编码。第二坑低模与高模的对应关系没对齐烘焙时低模的面片穿出或陷入高模。解决方式是检查包裹修改器的包裹距离参数通常在0.05到0.1厘米之间设置。第三坑共享UV空间导致两张贴图相互重叠烘焙结果出现“展示性花纹交错”。解决方式是给每个部件分配独立的UV象限区域避免两个对象共用一个棋盘格。第四坑法线贴图的绿色通道在Maya和UE之间翻转。现象是角色身上出现“内凹式高光”原因是OpenGL与DirectX对法线Y轴方向的定义不同。解决方式是导出时在Substance Painter里设定目标平台格式而不是等到引擎里再手动翻转。我在规范里通常会直接要求贴图输出时颜色、粗糙度、法线三张图必须从Substance Painter或同类软件中按预设模板导出法线以DirectX格式为默认UE用户无需额外翻转Unity用户也只需在导入设置里勾选对应选项即可。4. 材质命名与引擎落地从Substance Painter到Unity/UE的参数对应4.1 贴图命名规则一套能跨引擎迁移的通用后缀组合许多新人容易犯的一个错误是贴图命名与网格命名脱节。在规范中我固定了一种格式角色名_部件_贴图用途比如Knight_Head_BaseColor、Knight_Head_Normal、Knight_Head_Roughness。这套命名习惯能直接兼容Unity的自动材质识别和UE的资产命名约定。粘贴图时只要按规则重命名导入到引擎后就能自动匹配到正确的材质通道不需要每次手动指定。另外规范里要强调“禁止使用中文、空格和连续下划线”因为这些字符在某些引擎或中间格式下会出现无法预测的导入失败。用连字符-替代空格是可接受的。同时贴图规格也要在文档里写死身体部分的颜色贴图漫反射尺寸至少2048x2048px脸部可以升级到4096x4096px以保留面部细节法线贴图和粗糙度贴图使用与颜色贴图相同的分辨率金属度贴图通常合并进RMARoughness/Metalness/AO一张图里以减少纹理采样次数和内存占用。我一般会给出一个RMA打包方案R通道存粗糙度、G通道存金属度、B通道存环境光遮蔽。这套方法兼容性很广既适合Unity的Standard Shader也适合UE的PBR材质模型。4.2 材质球设置与PBR属性说明要让模型在引擎里呈现符合预期的质感仅靠贴图还不够材质球上的参数设置同样扮演关键角色。在Unity中我建议使用Universal Render Pipeline/Lit或HDRP/Lit材质把Smoothness设为从Roughness贴图的R通道反向输入Metallic设为金属度通道的G通道AO设为环境光遮蔽通道。UE中则是把Roughness、Metallic、Ambient Occlusion分别对应到对应贴图输入。这套映射关系既是PBR的物理基础也是后期调整光照时最容易反查的参数。如果没有这套统一规范在Substance里看着正常的材质一到引擎里就变成“塑料感”“油腻感”因为色彩空间和通道映射各自为政。4.3 引擎导入FBX时的参数预设引擎导入环节是整个链条里最容易“翻车”的地方原因是大多数DCC工具导出FBX时的默认设置并不适合实时渲染角色。我先给出一套可直接照抄的配置Unity中FBX导入参数按如下设置Scale Factor1单位切换File Scale Conversion已勾选时将Source源单位设为Centimeter厘米材质导入不勾选“Extract Materials”之前的自动创建材质规范做法是取消勾选“Use External MaterialsLEGACY”改用外部材质关联动画类型如果角色由动画系统控制选Humanoid如果只有骨骼层级需要保留选Legacy或Generic法线与切线保留原值不要勾选Swap UVs否则法线朝向会异常UE中导入FBX时骨骼层级关掉“Auto Generate Collision”避免多出额外物理形状法线导入选择Import Normals让引擎直接读取DCC中导出的法线而非重新计算材质导入UE默认会为每个材质插槽创建一个材质实例建议关闭“Create Materials”在引擎内部手动关联已配置好的材质资产这两套设置针对的是同一个角色资源差别在于引擎对坐标系Unity左手系、UE右手系和单位标准Unity默认米、UE默认厘米的处理方式。规范中应该固定一套“引擎侧导入参数表”作为引擎使用者的操作指南。这远比在文档里写“按默认设置导入”更有意义。5. 角色资产避坑清单5个高频返工现场5.1 坑位一模型在Maya里正常在引擎里变换位置偏移现象FBX导入引擎后角色枢轴点不在脚底而在世界坐标原点或模型中心导致动画位移时整个人物凭空抬高或漂移。这个问题的原因是模型师导出前忘了冻结变换模型上的平移、旋转、缩放数据仍然保留FBX导入后引擎读取了这些变换值导致坐标系翻转或位置偏移。解决方式是在规范中要求所有角色模型导出前执行“冻结变换、重置枢轴”并在导出后用一个简单的检查脚本或人工检查来确认枢轴位置。这一步写在文档里只是两句话但能省下大量后期手动修正的时间实际执行率超过八成的团队都在这里交过学费。5.2 坑位二贴图在Substance里正常引擎里发灰发暗现象角色进入引擎后材质整体灰蒙蒙高光区域几乎消失金属部分发暗。这个问题的根源通常是色彩空间设置不一致颜色贴图被当作线性空间数据Linear导入了而正确的操作是标记为sRGBGamma空间。在实时渲染管线里颜色贴图与法线/粗糙度贴图遵循不同的色彩空间规则一旦设置错整个PBR结果会偏移。解决方式是规范中明确“BaseColor/Diffuse贴图导入时勾选sRGB法线、粗糙度、金属度、AO贴图设为Linear”并允许TA或者技术美术在引擎里检查贴图导入选项避免人工反复尝试。5.3 坑位三动画和模型匹配不上动作错位现象动画师单独预览骨骼动画时动作正常但套到角色模型上之后手指、手腕或脚踝出现明显的偏移或穿透。原因一般是模型与骨骼的T-Pose不一致绑定师在A模型中设置了T-Pose动画师在B模型上编辑动作时使用的是另一个T-Pose导致骨骼旋转初值不同。解决方式是在规范中把“T-Pose必须是标准姿势手臂水平展开约45度、手掌朝下、两脚与肩同宽”写明并附带一张标准T-Pose截图和骨骼层级截图。这是文档里最不好用文字表达的部分但又是必须锁死的部分因为骨骼的重定向完全依赖T-Pose的初始匹配。实践里我们还会要求动画师在动捕之前先对模型的骨骼层级做一次对比测试确保两套骨骼的命名和结构完全一致。5.4 坑位四法线贴图方向不对角色出现“内凹式”高光现象角色身上受光后出现类似“凹陷”的奇怪明暗变化比如鼻子看起来像塌陷肌肉轮廓混乱。这个问题的原因是法线贴图的绿色通道Y轴在DCC与引擎之间存在方向差异这在OpenGL和DirectX格式之间是个典型坑。解决方式是在Substance Painter中统一使用DirectX格式导出法线贴图然后把UE默认的DirectX作为标准如果对接Unity则在导入设置里勾选“Flip Green Y”选项即可。规范中还需要补充一句法线贴图导入时不要与其他贴图一起勾选sRGB选项否则等于同时犯色彩空间和通道方向两个错误视觉效果会更加混乱。5.5 坑位五角色LOD时出现破面和闪烁现象远处角色切换LOD级别时边缘出现闪烁、破面和明显的轮廓跳变。原因是连续LOD之间顶点位置不一致或者说LOD减面时保留的轮廓顶点不统一。当游戏运行时LOD切换的一瞬间人的视觉会捕捉到轮廓变化。解决方式规范中要求制作LOD时不能只依赖自动减面工具必须把相邻LOD的关键结构点锁住例如下颌线、眼眶最高点、肩峰、指尖这些决定外轮廓的位置。如果发现有LOD衔接问题优先检查模型法线方向以及UV是否在减面过程中被重新投射。自动减面工具生成的LOD通常不会保留原UV但规范里要求“相邻LOD的UV必须完全一致”这样在切换时材质不会跳动光照也不会闪烁。6. 把规范从文档变成工具链用脚本自动校验资产命名与提交完整性6.1 用Python写一个基础命名检查脚本文档写得再好人肉核对永远是低效的。规范落地到项目的最终形态应该是一套版本的“自动检查工具”。我在实际项目管理中会写一个简单的Python脚本在角色资产提交前自动扫一遍目录检查命名格式、贴图后缀和FBX文件是否正确。下面的代码是一个可以套改的示例import os import re # 定义规范要求 PREFIX_RULES [mesh_, tex_, rig_] # 允许的前缀 ALLOWED_TEXTURE_SUFFIX [_BaseColor, _Normal, _Roughness, _Metallic, _AO] MESH_SUFFIX [_Low, _High, _LOD0, _LOD1, _LOD2] def check_asset_name(filename): # 检查是否符合命名规则返回 (布尔, 原因) if re.search(r[\u4e00-\u9fa5\s], filename): return False, 文件名包含中文字符或空格 if not any(filename.startswith(prefix) for prefix in PREFIX_RULES): return False, f缺少前缀应为 {PREFIX_RULES} if filename.endswith(.fbx): if not any(filename.replace(.fbx, ).endswith(suffix) for suffix in MESH_SUFFIX): return False, f网格文件缺少 LOD 或精度标识 {MESH_SUFFIX} if filename.endswith(.png) or filename.endswith(.tga): if not any(filename.replace(.png, ).replace(.tga, ).endswith(suffix) for suffix in ALLOWED_TEXTURE_SUFFIX): return False, f贴图缺少用途后缀 {ALLOWED_TEXTURE_SUFFIX} return True, OK if __name__ __main__: import sys asset_folder sys.argv[1] if len(sys.argv) 1 else . for root, dirs, files in os.walk(asset_folder): for f in files: result, reason check_asset_name(f) if not result: print(f[FAIL] {os.path.join(root, f)}: {reason}) else: print(f[ OK ] {os.path.join(root, f)})这段脚本的逻辑很简单遍历资产目录下所有文件根据后缀匹配前缀、名称中是否含中文/空格、以及贴图用途后缀是否齐全。注意它不检查文件内容只检查文件名。它的价值在于把“规范”变成“可执行的约束”让每个人在提交前先跑一遍而不是靠美术自己记着翻规范文档。你可以在脚本里加一个“白名单机制”例如Knight_Head_BaseColor.png之类的名称实际项目里那些按规矩命名却没有匹配上格式的名称可以通过白名单快速通过检查。6.2 关键校验点检查FBX网格体是否包含隐藏骨骼或多余节点除了命名FBX文件内容本身还需要一个检查脚本或引擎侧插件来做校验。最有效且最简单的校验方式之一是检查FBX中是否存在隐藏的、未使用的骨骼节点。隐藏骨骼通常源自建模软件里残留的辅助控制器或空物体导入引擎后可能会出现“模型漂浮着一根根骨骼线框”的现象虽然不影响渲染但会污染绑定层级拖慢运行时骨骼更新开销。解决方式是脚本用FBX SDK读取节点列表筛选出无蒙皮权重且无动画引用的节点进行记录。实际工作中这类问题常出现在外包交付的FBX里所以脚本的做法就是在提交前跑一遍列表把这些多余节点全部拉出来输出为纯文本清单提示美术在DCC里手动清理。6.3 最终验证打包提交前做可视化渲染对比在项目收尾阶段我习惯把最终角色放入一个标准的“验证场景”统一打三盏光主光、辅光、轮廓光并在引擎里截图对比角色在灰模状态、贴图完整状态下、以及LOD切换状态下的实时表现。这一步的目的是排除材质外观的“玄学因素”——光照环境一变角色质感就会变化不能只靠美术口口相传“看着没问题”。通过截图存档大家能够直观对比不同版本之间角色的视觉差异。这也是我在项目中比较坚持的习惯因为很多时候返工不是因为模型或贴图本身有问题而是因为不同人所处的光照环境不同导致对“是否达标”的判断不同。用一套固定验证环境定标准能极大减少这类争议。坦白说我从一开始也不习惯做这种“死板”的规范文档和检查脚本总觉得多做一步检查很麻烦。直到有一次外包交付了整套角色从命名到贴图通道全不符合规范我们整个组花了一周来手动调整和重新导入我才意识到规范文档的价值不在文档本身而在它能否成为团队共识并转化为自动检查的工具。一份好的3D角色资源制作规范.docx写完之后应该让人人都能照着做、做得一致而不是成为束之高阁的摆设。如果你也在带项目我的建议是先花一个下午把单位、命名和目录结构定好再花一天把验证脚本写出来其余内容可以随项目逐步补充。希望帮到你。本文还有配套的精品资源点击获取