第一次把 MMD 模型丢进 Blender、再到导出 FBX 给引擎用很多人都会经历同一个落差在 Blender 里看着挺正常镜头一转、动作一播头发乱飞、裙子穿模、贴图全白。这个流程里真正难的不是导出这个按钮而是把 MMD 那套为 MikuMikuDance 量身定做的数据结构翻译成 FBX 这种通用交换格式能表达的东西。这篇就按我自己的实际操作顺序把 Blender 里 MMD 模型导出 FBX 加烘焙动画的全流程拆开讲清楚包括每一步为什么这么做、参数怎么定、哪些东西注定导不过去只能绕路。适合已经会基本 Blender 操作、手上有 PMX/PMD 模型和 VMD 动作、想把它送进 Unity、UE 或者 Cocos 这类引擎里的朋友。1. 先把问题问对MMD 转 FBX 到底难在哪1.1 MMD 的数据模型和 FBX 的能力边界不是一回事很多人以为导出失败是因为插件装错了或者 Blender 版本不对其实大部分坑来自一个更根本的地方MMD 的模型和动作是一套自成体系的实现它有很多方言而 FBX 是一份通用的普通话词典词典里没有对应的词你就只能换一种说法。具体说MMD 的模型文件里除了顶点、UV、材质、骨骼权重这些常规内容还塞了物理刚体、物理关节、显示枠、追加变换、SDEF 权重、多种表情类型。这些在 MMD 自己的运行环境里都有明确的解释者但 Blender 的 FBX 导出器只认 Blender 原生数据网格、形态键、骨架、姿态关键帧、材质节点。凡是不能被翻译成这几样的导出的那一刻就静默消失不报错、不弹窗你只有在引擎里才会发现少了点什么。所以正确的心态是不要指望一键无损转换而是先想清楚哪些数据我需要保留、哪些我可以重建、哪些我干脆放弃。这个判断做在前面后面能省掉大量返工。1.2 SDEF、追加变换、物理——三个导不过去的特产有三个东西我建议一开始就盯着SDEF 蒙皮权重。MMD 为了在扭转关节处保持体积感用了 SDEF 这种球面变形方式它和 FBX 里通用的线性蒙皮不是一套算法。导入 Blender 之后mmd_tools 会把它处理成 Blender 能算的东西但导出到引擎后引擎只会按线性蒙皮算。结果就是手腕、肩膀、裙摆这些用 SDEF 的位置在引擎里转动时可能会塌陷、变细。这不是哪里设置错了而是算法差异要么接受要么在 Blender 里手动补权重刷回去。追加变换。MMD 里很多骨骼的旋转是跟随其他骨骼的比如部分模型的腕捻、手先、肩的联动mmd_tools 用追加变换约束来模拟这套链路。约束不会跟着 FBX 走必须烘焙成关键帧。物理刚体。头发、裙摆、袖口这类动态骨骼在 MMD 里是刚体加关节实时算出来的。FBX 里没有现场模拟这个概念它只有一组死关键帧。要么你在 Blender 里把模拟结果烘成关键帧带出去要么到了引擎里用引擎自己的弹簧骨、布料系统重建一遍。1.3 导出前先定三件事目标引擎、单位、动画用途这三件事没定参数就是瞎猜。目标引擎决定了坐标轴和贴图策略。Unity 和大多数 Web 引擎习惯 Y 轴向上、-Z 朝前UE 有自己的尺度和坐标习惯Cocos 在小游戏场景里对贴图长宽和格式更敏感。单位决定了模型是 1.6 米高还是 20 米高。MMD 模型的原始尺寸大概是一个 1.58 米高的角色占 20 个单位左右如果不缩放直接导进引擎就是一个二十米高的巨人相机、碰撞体、物理全部要重调。动画用途决定了你要烘多少东西。如果只是拿模型做静态展示物理骨骼完全可以冻结如果要做一段固定镜头的舞蹈演出物理烘死没问题如果这个角色后面要穿不同衣服、做不同动作那物理骨骼最好留给引擎侧处理不要在 FBX 里烘成死数据。我的习惯是先拿一个最简单的小模型骨骼少、没物理、表情少的那种跑一遍完整流程导入、清理、导动作、烘焙、导出、进引擎、播一遍。这条最小闭环跑通了再换复杂模型出问题的时候你才知道是新引入的变量还是流程本身的坑。2. 环境准备Blender 版本与 mmd_tools 的组合2.1 版本怎么选插件从哪来这里有一句实话Blender 和 mmd_tools 的版本搭配比后面所有参数设置都更能决定你这一天顺不顺。mmd_tools 是一个第三方插件它跟着 Blender 的 API 走Blender 跨大版本时改了不少接口插件通常要缓一两个小版本才跟上。所以我的建议是用你当前插件已经明确适配的 Blender 版本别追最新。如果导入 PMX 时直接抛异常或者面板点不动先怀疑版本搭配而不是模型有问题。插件安装走标准流程从项目发布页下载 zip 包不要解压直接在偏好设置里选择从磁盘安装装完在插件列表里搜到它、勾上启用。装好后文件菜单的导入里会多出 MMD 模型、动作这些入口。注意不要从多个来源装同名的不同版本插件残留的旧版本文件会导致面板出现重复按钮或者报奇怪的错误。换了版本就先把旧目录清干净。2.2 导入面板里的勾选项逐条说明导入 PMX 的时候会弹出一个面板不同版本字段名略有差异但核心就几块缩放。这是最关键的一项。这里的值决定模型导入后的物理尺寸常见做法是填一个能让角色落到 1.6 米左右的比例值。我的做法是在这一步就把尺寸定死后面不再用物体缩放去改原因在第三章展开。类型勾选。面板里通常可以分别控制要不要导入网格、骨架、材质、形态键、显示枠、物理刚体和约束。这里有一个实用策略第一次导入时我建议全部勾上先看看模型完整长什么样把物理和显示枠在视图里隐藏起来不碍事等你确认了模型没问题再决定导出时怎么取舍。清理类选项。有些版本提供清除多余顶点、合并重复材质之类的选项。模型来源干净的话可以不动如果这模型是别人二次改过的顶点冗余严重勾上清理能明显减小后面的文件体积。2.3 导入完成后的体检清单导入完不要急着往下走花三分钟做一遍体检。这几项任何一项不对后面都会放大成大问题。检查项怎么看不对的话会怎样骨架对象是否为唯一一个大纲视图里数骨架数量导出后引擎里出现两套骨骼动画对不上模型整体高度用测量工具量头顶到脚底引擎里比例全错相机和碰撞体都要重做朝向看角色面朝哪个轴引擎里角色背对相机或者躺倒材质是否都有贴图切换材质预览模式看导出后大面积灰白形态键数量属性面板形态键栏数量异常多说明可以裁剪是否存在独立描边网格大纲里看有没有反法线的重复网格引擎里出现黑色外壳或者 Z 冲突3. 把 MMD 骨架改造成能导出的骨架3.1 缩放与朝向在导入时定死别事后补为什么我反复强调要在导入时定尺寸因为 Blender 里对骨架做物体级缩放并应用变换虽然画面看着正常但骨骼的位置数据会被写进关键帧动作的插值方式会跟着变。你如果在导完动作之后再缩放骨架很容易出现动作整体漂移、脚底打滑、根骨骼偏移这些问题而且排查起来特别费劲。朝向同理。MMD 的坐标系和 Blender 不一样插件导入的时候已经帮你转过一次了。你要做的是确认转换结果符合预期而不是在导出面板里靠坐标轴设置去补回去。导出面板的轴设置应该是最后的微调手段不是主要手段。一个稳妥的顺序是导入时定好缩放和朝向先在 Blender 里播一段动画确认脚下站得住、转身方向对再动材质和骨骼结构。3.2 追加变换约束与 IK不烘焙就一定散架打开骨架的骨骼约束面板你会看到有些骨骼上挂着插件生成的约束一类是反向动力学一类是追加变换。这两类东西是 MMD 动作能正常播放的原因也是导进引擎后动作散架的原因。道理很简单这些约束是求解器它根据控制骨的位置实时算出目标骨的旋转。FBX 只保存结果不保存求解过程。如果你不做处理直接导出导出器要么忽略约束、把控制骨的原始旋转写出去看上去就是脚掌乱翻要么在导出瞬间采样但采样不完整出现抖动。所以在导出前必须把所有约束的结果固化成普通关键帧也就是烘焙。这一步不能省。3.3 骨骼命名、层数和 Only Deform 的取舍MMD 模型的骨骼名基本是日文数量经常两百根以上其中相当一部分是控制骨、显示用骨、物理骨真正参与蒙皮的只是一部分。命名上Blender 和主流引擎对非 ASCII 字符支持都不错但工具链上就不好说了打包脚本、批量处理工具、在线预览器里日文骨骼名引起的乱码和匹配失败我见过不止一次。如果你的项目会经过自动化流程尽早把骨骼名改成 ASCII 是个省心的选择。骨骼名可以在 Blender 里改只要网格的顶点组同步更新就行注意改完要检查顶点组是否一一对应。层数上插件通常会把不同用途的骨骼分到不同骨骼层这是个好东西用它可以快速选中所有变形骨或者所有物理骨。后面批量操作和烘焙的时候靠骨骼层来选比靠肉眼点选靠谱得多。导出时有一个常见开关叫仅导出变形骨骼它的作用是自动剔掉不参与蒙皮的控制骨。这个开关本身很好用但一定要在烘焙完成之后再打开。顺序反了你会把控制骨剔掉然后发现动作没了还以为是烘焙出错。4. 材质与贴图从 Toon 到 Principled BSDF 的转换路线4.1 MMD 材质的构成漫反射、球面贴图、Toon 贴图、描边MMD 的一个材质通常包含这些层次一张漫反射贴图、一个球面贴图用来做高光或环境反射、一张 Toon 贴图用来做阶梯式明暗还有描边和自阴影设置。这套东西是 MMD 自己的卡通渲染管线在解释Blender 的默认渲染器不认识。问题就在这里Blender 的 FBX 导出器只认标准节点也就是基础色、金属度、粗糙度、法线、透明度这几个输入。你在材质里挂的是卡通渲染专用节点导出时它读不到导出的结果就是材质丢了贴图引擎里一片灰白或者粉红。4.2 转换为 Blender 原生材质的操作与检查点插件在材质面板里一般提供一个转换按钮作用是把卡通材质重建为标准的物理材质把漫反射贴图接到基础色、把球面贴图接到高光或反射、把透明度接到 Alpha。不同版本的按钮位置和名字不一样有的叫转换为标准材质有的叫转换为循环渲染材质找不到就在材质属性面板的上半部分找。转换完之后必须自己过一遍因为自动化转换不可能百分之百准确。我一般检查这几项基础色是否接到了正确的贴图有没有接成 Toon 贴图导致整个人脸变成色阶图。Alpha 通道是否接上尤其是头发、睫毛、裙摆边缘这种半透明区域。法线方向是否被翻过MMD 有一部分材质是背面渲染的转换后可能出现内外翻转。材质的混合模式设成了什么这个直接决定导出后引擎怎么处理透明。转换有个副作用值得提前知道转换会生成新的材质和节点如果转换两次材质会翻倍。所以转换前先存一次盘转换后如果发现不对直接回退别硬着头皮往上堆。4.3 透明、双面与描边在 FBX 里的表达方式FBX 对材质信息的表达能力比较有限透明基本靠贴图 Alpha 加一个透明度标志双面靠一个布尔标志。所以你有三件事要处理透明区域。把材质的混合模式按用途分好头发、睫毛这种要么全透要么全不透的用 Alpha 裁剪模式并设一个阈值比混合模式更省性能也更不容易出现排序问题真正需要渐隐的比如半透明的纱裙才用混合。这个设置会影响导出的透明度标志引擎侧再确认一次最稳。双面问题。MMD 的模型很多面是单面的靠剔除背面来省性能。如果你的材质设成了双面引擎里可能出现两个面重叠互相闪烁。反过来如果该双面的边缘设成了单面从某些角度看就会出现空洞。我的做法是头发、睫毛、裙摆这类薄片结构设成双面人物的主体材质保持单面。描边。有些模型会带一份独立的描边网格本质是反法线的外壳。这东西在引擎里通常不需要而且很容易和主体产生 Z 冲突。我的处理是导出前把它删掉或者隐藏描边在引擎里用后期或者描边材质重做效果更可控也省一大坨顶点。5. 烘焙动画从 VMD 到引擎能读的关键帧5.1 为什么必须烘焙约束、IK、追加变换的求解结果前面说了约束不跟着走这里说说烘焙的本质。烘焙做的事情很简单在每一帧上读取骨架经过所有约束求解之后的最终姿态然后把这些姿态写成普通的关键帧覆盖掉原来那些依赖控制骨的关键帧。烘完之后骨架就不再需要约束了你可以把约束全部删掉动作照样能播。这一步做完FBX 导出才有意义因为导出的就是一堆纯姿态数据。顺便提一个验证方法我每次都会做烘焙并清除约束之后把时间轴从头播一遍肉眼看动作和烘焙前是否一致。这个断奶测试是判断烘焙是否成功最直接的手段。如果断奶之后脚飘了、手僵了说明烘焙参数哪里没设对回退重来比到引擎里排查便宜得多。5.2 Bake Action 的完整操作与参数解释烘焙的入口在物体菜单的动画子菜单里操作对象是骨架需要进入姿态模式。参数我通常是这么设的参数我的设置为什么起始帧 / 结束帧按动作实际范围填用默认范围会漏掉首尾帧动作开头结尾会跳步长1设成 2 以上等于抽帧快速动作会明显抖动仅选中骨骼勾上只烘变形骨控制骨不需要导出视觉关键帧勾上取的是约束求解后的结果这是能固化的关键清除约束勾上前提是先备份清错了要能回退清除父级视情况处理对象级的父子关系一般也勾覆盖当前动作看情况想保留原始动作就先复制一份动作再烘烘焙前一定先另存一份工程文件这不是过度谨慎。清除约束是不可逆操作而且 MMD 模型有几百根骨骼真清错了你想手动加回去会非常痛苦。烘焙完之后有两个检查点。一是看关键帧数量一个三百帧、两百根骨骼的动作烘出几万到十几万个关键帧是正常的如果数量少得离谱说明有骨骼没被选中。二是看有没有数值爆掉的情况偶尔会出现骨骼飞到极远处那种通常是某个约束在烘焙瞬间解算失败把对应骨骼的关键帧删掉重烘那一段即可。5.3 物理骨骼头发/裙摆/袖口的烘焙流程与误差说明物理是这一套流程里最麻烦的部分因为它是模拟结果不是确定性的数学解算。流程大致是这样先确保刚体和关节都正常导入把时间轴放到动作第一帧从头连续播放一遍让物理解算把动画缓存建起来。这里必须连续播不能直接拖到中间帧因为解算依赖前面帧的状态。缓存建好之后选中那些由物理驱动的骨骼头发、裙摆、袖子、饰带对它们做一次烘焙参数和上一节基本一致但不要勾清除约束因为它们是被刚体驱动而不是骨骼约束。插件本身通常也提供一个物理烘焙的按钮不同版本叫法和位置不同有的在物理面板里。如果版本支持直接用它的效率更高它的原理和手动烘焙一样只是把选择骨骼和采样这两步自动化了。找不到或者报错就退回手动流程。这里必须诚实说一句误差MMD 的物理和 Blender 的物理是两套解算器参数换算也不完全等价。同一个动作MMD 里头发飘得柔顺Blender 里可能更硬或者更飘。所以你在 Blender 里烘出来的物理效果只是接近而不是还原。如果客户对裙摆的形态有明确要求别指望靠物理自动跑出来该手 K 就手 K。还有一个更现实的问题烘死的物理只能对应这一条动作。角色换动作的时候裙摆还是按原来那条动作飘的穿模会非常明显。所以只要项目里角色会复用我的建议都是物理骨架保留在引擎侧用引擎的弹簧骨或者布料来处理FBX 里只导出骨架结构、不烘物理。5.4 表情形态键能带走的和带不走的MMD 的表情类型不止一种但从导出可行性看只分两类顶点表情和其他。顶点表情就是改顶点位置的这种在 Blender 里对应形态键而 FBX 是支持形态键的能带出去引擎里表现为混合形状。口型、眨眼这类最常用的表情通常都是顶点表情所以核心需求是能保住的。带不走的是材质表情、UV 表情、骨骼表情。材质表情在 MMD 里靠换贴图实现比如腮红、泪光、眼睛高光切换这些在 Blender 里转换材质的时候就丢了。UV 表情 FBX 也没有对应的通用表达。骨骼表情是改骨骼位置驱动的它本质上属于姿态动画需要单独烘到动画里。所以我一般的处理策略是导出前先把形态键筛一遍只保留真正会用到的比如十几个口型和几个眼型其余全部删掉。原因是 FBX 里每个形态键都是一整套完整顶点数据两百个表情能让文件体积翻好几倍引擎加载也慢。删完之后形态键的名字改成 ASCII避免引擎侧脚本匹配出问题。6. FBX 导出面板的逐项取舍6.1 Include 与 Transform先把不该导的剔掉导出面板的第一块是导哪些东西。场景里现在有骨架、网格、物理刚体、关节、可能还有辅助空物体和灯光相机。我的做法是把模型和骨架选中然后选仅导出选中物体把物理刚体和辅助物体全部排除在外。理由很直接那些东西导进引擎只会变成一堆无意义的节点有些引擎还会因为它们生成多余的碰撞体。变换这一块缩放填 1因为尺寸在前面已经定死了应用单位看目标引擎轴设置看目标引擎的习惯。Unity 和 Web 引擎通常用前向负 Z、上方向 Y 这一组进引擎之后角色正面朝向相机、站姿正常说明就对了。UE 需要根据导入的实际结果调整我会先用一个带方向的简单模型试一次确认无误再批量。注意这里的坐标轴设置是给导出文件贴标签不是给模型做变换。如果导出的模型躺着或者背对先回 Blender 检查骨架朝向而不是在这里乱改轴。6.2 Geometry 与 Armature三角化、切线、叶骨骼几何部分我常用的组合是平滑方式用面方式保持硬边和柔边的分界、勾上切线引擎做凹凸或各向异性效果时需要、勾上三角化引擎最终都会三角化提前做可以避免法线和 UV 在引擎侧被重新计算导致不一致、勾上清理松散点边把孤立顶点去掉省内存也避免报错。骨架部分有三个重点。叶骨骼的自动生成建议关掉那是给某些 DCC 工具做兼容用的MMD 骨架本来就有大量末端骨再加一层只会污染结构。仅导出变形骨骼这个开关在烘焙完成后打开可以自动过滤控制骨。骨骼轴向的两个选项除非引擎侧明确反馈朝向异常否则不要动它会影响绑定关系属于改错一次排查半天的类型。6.3 Animation 与采样双保险不冲突动画这块导出器的烘焙动画开关和手动烘焙是两回事但可以同时用。导出器的烘焙是在导出瞬间对场景采样一遍好处是连你没手动处理的驱动和约束也能被捕捉到坏处是这个过程你看不见出了问题没有中间状态能检查。手动烘焙的好处是结果落成关键帧你能播放验证、能删约束、能对比。我的做法是两个都开。采样率设 1不要简化曲线否则导出器会按容差把关键帧抽稀快速的动作会被抽得一顿一顿的。至于导出全部动作还是只导当前动作取决于项目需要场景里只有一条动作就无所谓有多条动作时要注意别一次全导出去引擎里会多出一堆用不上的动画剪辑。6.4 Path Mode 与贴图打包策略贴图路径这块两个思路。复制模式会把贴图拷到 FBX 旁边交付时需要把整个文件夹一起给出去嵌入模式把贴图塞进 FBX单文件好传但文件变大而且部分引擎对嵌入贴图的支持不一致Cocos 这类工具链上就比较容易出问题。我个人更倾向复制或者自动模式然后统一贴图命名。这里有一条可能反直觉但非常实用的经验贴图文件名和路径全用 ASCII 字符比你想象的更重要。我遇到过模型在 Blender 里贴图完全正常一进引擎就报贴图加载失败的案例最后定位到是贴图文件名里带了日文字符Blender 能读引擎的资源管线处理不了。统一成小写 ASCII用下划线分隔能规避掉一整类问题。另外顺手检查一下贴图的格式。PNG 通用性最好TGA 和 PSD 在部分引擎上要么不支持要么需要转换导出前批量转一次比事后补锅便宜。6.5 一套可复用的导出预设与批量思路模型多了之后逐个点面板是不可持续的。可以利用导出面板里保存预设的功能把一套调好的参数存下来下次直接选。更进一步用脚本批量导出。下面的例子是思路骨架实际跑之前一定先拿一个模型验证因为导出算子的参数名在不同 Blender 版本里改过import bpy, os OUT rD:/fbx_out os.makedirs(OUT, exist_okTrue) for arm in [o for o in bpy.data.objects if o.type ARMATURE]: meshes [c for c in arm.children if c.type MESH] bpy.ops.object.select_all(actionDESELECT) arm.select_set(True) for m in meshes: m.select_set(True) bpy.context.view_layer.objects.active arm bpy.ops.export_scene.fbx( filepathos.path.join(OUT, arm.name .fbx), use_selectionTrue, global_scale1.0, axis_forward-Z, axis_upY, mesh_smooth_typeFACE, use_tspaceTrue, use_mesh_modifiersTrue, add_leaf_bonesFalse, use_armature_deform_onlyTrue, bake_animTrue, bake_anim_step1.0, bake_anim_simplify_factor0.0, path_modeCOPY, embed_texturesFalse, )这个脚本有一个前提场景里每个模型的结构是规整的一格模型一个骨架、网格是骨架的子物体。如果场景里骨架和网格是平级关系选择逻辑就得换成按集合或者按命名规则来分组。所以真正省时间的不是脚本本身而是前面把工程结构整理干净。7. 导入引擎后的翻车现场与排查顺序7.1 贴图丢失、粉红材质的排查链路材质变粉红或者整片灰白原因有五六种排查要按成本从低到高排。先看引擎的导入日志里有没有贴图加载失败的记录有的话直接定位到具体文件。然后检查贴图是否被真的导出到了 FBX 旁边还是只写了个绝对路径指向了你的开发机。接着检查文件名和路径里有没有非 ASCII 字符这条踩中的概率比想象中高很多。再之后检查贴图格式引擎是否支持。最后才回 Blender 检查材质节点是否真的把贴图接到了基础色上。有一种情况特别容易被误判在 Blender 里材质预览用的是视口显示看起来有贴图但那可能是插件自定义节点画的导出器读的根本不是那条线。切换成渲染预览模式看一眼如果基础色的输入是空的那导出必然是灰白。7.2 比例、朝向、根节点错位尺寸问题通常只有两个来源导入时缩放没设或者导出时缩放置了非 1 的值两者叠加。排查方法是在 Blender 里量一下身高进引擎再量一次看差了几倍。朝向问题看角色是不是躺倒或者背对相机根因一般在骨架朝向。另外注意一个容易忽略的点有些引擎会在导入时自动给根节点加一层缩放或者旋转这时候看起来像是模型的问题其实是导入设置的问题。改引擎的导入设置比改模型便宜。7.3 动作抖动、脚滑、骨骼飞散抖动基本可以判断是采样率或者关键帧数不足检查导出时有没有开简化曲线检查烘焙步长是不是 1。脚滑是另一个维度的问题它是位移数据丢失或缩放不一致造成的。MMD 的动作里角色的位移是靠根骨骼或者中心骨实现的如果这根骨骼被过滤掉或者它的位移被缩放了两次脚下就不会跟着动。骨骼飞散是最严重也是最好定位的通常是某根骨骼在烘焙时解算失败关键帧里出现了极大或者极小的数值。在 Blender 里打开曲线编辑器找异常峰值删掉那几帧重烘。7.4 形态键与材质穿帮形态键在引擎里全丢多半是导出时形态键被删了、或者名字冲突被引擎合并了。检查 Blender 里形态键的名字是否唯一有没有空名字。材质穿帮主要看透明和双面。头发变成硬边黑块说明透明被裁掉了裙摆从里面看是空的说明该双面的材质导成了单面。7.5 一张排查顺序表现象最可能的原因先做什么全身粉红或灰白材质未转换成标准节点或贴图未随文件导出查导入日志再看材质基础色是否接了贴图模型巨大或极小导入缩放和导出缩放叠加两边各量一次尺寸角色躺倒或背对骨架朝向问题回 Blender 看骨架不要改导出轴动作抖动采样率过高或开了曲线简化关简化采样率设 1脚下打滑根骨位移丢失或被重复缩放检查根骨骼是否被过滤局部骨骼飞出去烘焙时解算失败曲线编辑器找异常峰值重烘头发透明失效混合模式设置不对材质改 Alpha 裁剪并设阈值表情全丢形态键被删或重名检查形态键列表8. 几个让我省下大量时间的做法8.1 中间产物策略一个文件只做一件事这套流程步骤多、不可逆操作多我强烈建议按阶段存文件而不是在一个工程里反复改。我的习惯是四份第一份是原始导入不做任何修改只用来对照。第二份做材质转换、清理、缩放定死这份文件是可交付的干净模型。第三份导入动作并完成烘焙所有关键帧都在这里。第四份是导出用的删掉物理刚体、辅助物体、描边网格只留骨架和网格。这么做的价值在出错的时候体现出来材质出问题回到第二份动作出问题回到第三份不用从头再来。而且每次修改都有明确的对照基准很容易看出是哪一步引入的问题。8.2 批量处理与命名规范模型一多命名就是生死线。我的命名规则是骨架叫 model_name_arm网格跟着骨架走贴图统一 模型名_部件名_贴图类型.png全小写 ASCII 加下划线。骨骼名如果不涉及后续脚本匹配可以保留日文但只要项目里会用到自动化流程就尽早改成拼音或英文。批量操作上有两个思路值得用。一个是利用骨骼层快速选择同类骨骼比如物理骨、控制骨、变形骨做完一次烘焙之后同类操作可以重复使用同一套选择。另一个是把重复劳动脚本化比如批量改骨骼名、批量改贴图路径、批量导出。写脚本的成本大概半小时但只要模型数量超过十个肯定回本。8.3 什么时候干脆别用 FBX最后说一句可能有点扫兴的话如果你最终的目标是网页端或者实时展示glTF 往往比 FBX 顺得多。FBX 是历史包袱比较重的格式坐标轴、材质表达、贴图打包这几块都是坑区而 glTF 对材质和贴图的处理更现代Web 引擎原生支持也更好。我现在的判断标准是目标引擎原生吃 FBX 且团队有现成管线就用 FBX如果只是想在网页里展示一个模型别硬走 FBX导出 glTF 会省掉这一整篇里至少一半的麻烦。但反过来说如果目标平台是主机、桌面引擎或者公司既有流程锁死了 FBX那上面这套流程就是绕不开的功课。做到最后你会发现真正决定成败的从来不是导出面板上那几十个勾选项而是导入之后的体检、材质转换是否干净、烘焙是否彻底这三件事。这三件做扎实了参数反而怎么调都能出活。