PMX骨骼名称对照:MMD动作移植与骨骼映射实战指南

📅 发布时间:2026/10/1 1:30:46
PMX骨骼名称对照:MMD动作移植与骨骼映射实战指南
PMX 骨骼名称对照这件事说白了就是把模型里那一堆日文假名、汉字、罗马音混排的骨骼名翻译成你自己看得懂、工具认得出、脚本匹配得上的统一体系。做过 MMD 模型改造、动作移植或者把动捕数据往回灌的人都知道骨骼名对不上动作就是零零散散掉一地脚在原地打滑手臂像脱臼一样扭着裙子该飘的时候纹丝不动。它解决的从来不是翻译这么简单的问题而是让动作数据、物理运算、IK 链、追加变形这四套机制能在同一个模型上正常对话。适合谁看如果你正在做模型改模、想把 A 模型的动作套到 B 模型、或者准备写脚本批量处理 PMX 文件这份对照表能帮你省掉大量反复试错的时间如果你只是好奇 MMD 模型内部长什么样看完也能大致明白那些日文骨骼名各自负责哪块身体。1. PMX骨骼命名到底乱在哪标准方言与三种写法并存骨骼名称混乱不是谁偷懒而是历史叠出来的。PMX 格式本身只规定骨骼有个名字字段但没规定这个名字必须叫什么。于是从 MMD 早期版本一路发展下来形成了官方标准骨、准标准骨、各家自制骨三层结构再加上日文、汉字、英文三种写法同时流通才变成了今天这个样子。理解这三层结构比死记硬背对照表有用得多因为你会知道遇到一个陌生骨名时该往哪个方向猜。1.1 官方标准骨骼与准标准骨骼的分层逻辑MMD 官方VPVP 相关规范给出的标准骨骼是最小可用集合包括全ての親、センター、上半身、首、頭、肩.L/R、腕.L/R、ひじ.L/R、手首.L/R、下半身、足.L/R、ひざ.L/R、足首.L/R以及各手指骨。这一层是所有模型都必须有的缺一个动作数据就会掉帧。准标准骨骼是在标准骨基础上扩展出来的一层用来弥补标准骨做不出精细变形的问题。典型成员包括グルーブ、腰、上半身2、肩P.L/R、腕捩.L/R、手捩.L/R、足D.L/R、ひざD.L/R、足首D.L/R、足先EX.L/R、両目、つま先.L/R。这些骨不是必须的但绝大部分动作数据作者会用到尤其是上半身2和腕捩少了它们上身弯曲和手臂扭转就会明显失真。第三层是模型的私有骨比如スカート_0_1、髪_1_2、胸.L、尻、リボン这类全看模型作者怎么起名。这一层没有统一标准也是移植动作时最容易出问题的地方——动作作者根本不可能知道你裙子分几节、每节叫什么。注意判断一个模型骨骼全不全不要看骨的总数而要看准标准骨缺了哪些。总数两百的模型可能缺腕捩总数八十的模型反而可能是精修过的标准骨集合。1.2 三种命名派系的由来与市场现状日文假名混汉字派是当前主流VPVP 标准模型和绝大多数现代模型都走这条路。特征是把ひじ肘、ひざ膝、つま先脚尖写成平假名而腕、首、頭、足首写成汉字。为什么不统一因为肘和膝这两个汉字在日文语境里容易被其他字形混淆早期作者为了区分就写成假名后来成了事实标准。全汉字派多见于旧模型和部分国人作者作品肘.L、膝.L直接写汉字。这类模型在 MMD 里用没问题但很多自动匹配脚本按标准名写死的字典就匹配不上需要额外做一层别名映射。英文名派通常在english_name字段里填arm_L、elbow_L这种本地名字段还是日文。真正把本地名也写成英文的模型多半是从 Blender 或 Unity 转过来的这类模型在 MMD 里加载后骨骼面板会显示英文编辑时反倒是件好事。1.3 PMX文件里其实存了两个名字字段这是很多人做了几年模型都没注意到的细节PMX 的每根骨骼有两个名称字段一个是本地名name一个是通用名english_name。MMD 本体读本地名部分导出工具和游戏引擎读通用名。所以你看到一个模型在 MMD 里骨骼显示日文导出到 Unity 后变成英文不是被自动翻译了而是换读了另一个字段。这个机制带来一个非常实用的技巧做模型改造时如果你不想动本地名怕破坏原作者的物理和动作兼容性可以只填通用名字段让下游工具链用英文名工作。反过来如果你想做一份跨语言的骨骼对照直接批量导出这两个字段就是一张现成的对照表比手工整理靠谱得多。2. PMX骨骼名称对照表按身体分区逐段拆解下面这几张表是我自己做改模时整理的版本覆盖标准骨和准标准骨中文叫法用的是圈子里比较通用的说法。有些叫法在不同群里会有差异我尽量选了歧义最小的那个同时在备注里说明了容易踩的误解点。2.1 躯干与头部区对照标准日文名中文习惯叫法常见英文名父骨备注与常见误解全ての親全部之亲 / 总父级all_parent无根骨模型唯一的顶层根骨整体位移、整体旋转都靠它センター中心center全ての親实际控制重心走位、转身用它而不是用根骨グルーブ节奏骨grooveセンター上半身和下半身的共同父级扭腰动作的关键腰腰waistグルーブ准标准骨缺它时某些动作的腰部扭动会变僵硬上半身上半身upper_bodyグルーブ脊柱下段弯腰用它上半身2上半身2upper_body2上半身准标准骨脊柱上段挺胸、侧弯靠它首脖子neck上半身2有些模型父骨直接是 上半身没有 上半身2頭头head首注意不是首日文里首是脖子目.L / 目.R左眼 / 右眼eye_L / eye_R頭不是所有模型都单独分左右眼両目双眼both_eyes頭由左右眼骨骼驱动控制视线朝向这里必须强调首和頭的区别我见过不止一个人第一次看到骨骼列表时把首当成头骨然后怎么调模型都不对。日文的首くび指的是脖子頭あたま才是脑袋。同理手首是手腕不是手足首是脚踝不是脚。2.2 手臂与手指区对照手臂区的坑主要在捩り骨和手指编号上。捩りねじり骨是扭转补偿骨靠追加变形机制把父骨的一部分旋转量传导过来让前臂在扭的时候不出现糖纸效应。标准日文名中文习惯叫法常见英文名父骨备注肩.L肩shoulder_L上半身2锁骨位置耸肩、含胸肩P.L肩Pshoulder_p_L上半身2准标准骨作为 肩.L 的父级避免肩部变形冲突腕.L上臂arm_L肩.L就是大臂日文腕泛指手臂腕捩.L上臂扭转arm_twist_L腕.L准标准骨有的模型会拆成 腕捩1/2/3ひじ.L手肘 / 小臂elbow_L腕.L汉字派写作 肘.L手捩.L手腕扭转wrist_twist_Lひじ.L准标准骨手首.L手腕wrist_Lひじ.L注意父骨是 ひじ 不是 手捩親指0.L拇指根thumb0_L手首.L只有拇指有 0 号其他手指从 1 开始人指1/2/3.L食指三节index1/2/3_L依次相连汉字派写作 人差指中指1/2/3.L中指三节middle1/2/3_L依次相连最稳定、最常被动作数据使用薬指1/2/3.L无名指三节ring1/2/3_L依次相连日文薬指即无名指小指1/2/3.L小指三节pinky1/2/3_L依次相连手指这一块有个很实际的问题动作数据里做抓握动作时通常只驱动中指1、人指1、薬指1、小指1和親指0靠权重和物理把剩下的关节带过去。所以如果你的模型手指骨命名对不上表现不是整只手不动而是手指伸得笔直、像在拍证件照。2.3 腿脚与IK区对照腿部是误解最严重的区域没有之一。日本语境的足在骨骼体系里指大腿ひざ虽然字面是膝盖但这根骨实际承担小腿的角色它一转整条小腿跟着走。标准日文名中文习惯叫法常见英文名父骨备注下半身下半身lower_bodyグルーブ髋部和 上半身 分家足.L大腿leg_L下半身不是脚是大腿根到膝盖ひざ.L膝盖 / 小腿knee_L足.L汉字派写作 膝.L足首.L脚踝ankle_Lひざ.Lつま先.L脚尖toe_L足首.L部分老模型没有这根骨足先EX.L脚掌前端toe_ex_L足首.L 或 つま先.L准标准骨用来做脚掌弯曲、脚趾抓地足.L脚IKleg_ik_L全ての親注意 是全角字符写成半角会匹配不上つま先.L脚尖IKtoe_ik_L足.L同样全角足D.L足Dleg_d_L下半身准标准骨的变形辅助骨配合追加变形用ひざD.L膝Dknee_d_L足D.L足首D.L踝Dankle_d_LひざD.L注意足.L里的是全角字母这是 VPVP 标准模型沿用的写法。我自己就踩过这个坑脚本里写足IK.L半角跑了半天IK 骨死活匹配不上最后逐字节对比才发现是全角半角的问题。2.4 辅助骨物理骨与表情相关骨这一层是最自由、最没有标准的部分但它在实际效果里占的比重反而最大。模型好不好看一半靠这些骨。物理骨主要通过刚体关节驱动骨骼本身往往被设为物理后变形。常见命名有髪头发、スカート裙子、胸胸部、尻臀部、リボン缎带、マフラー围巾。裙子通常按スカート_0_1、スカート_0_2这种部件_横排_竖排的方式命名也见过スカート1_L这种左右分家的写法没有任何统一规范。表情与视线相关骨比较固定的是両目、目.L/R、あご下巴、舌、涙眼泪。あご和舌只在少数高精度模型上出现做口型同步时用得上。显示用骨比如グルーブ其实在 MMD 的骨骼显示面板里默认是隐藏的它纯粹是逻辑上的中间层。类似的还有肩P、腕捩这些骨在 MMD 界面里手动摆姿势时基本用不到但物理和动作数据会驱动它们。我在整理对照表时有个小习惯给每根骨标注是否会被 VMD 动作直接驱动。标准骨和大部分准标准骨会被驱动物理骨和 D 骨基本只被内部机制驱动。这个标注在你排查为什么这个动作套上去以后裙子不动的时候特别省事。3. 对照表落地使用的三个实战场景整理出表格只完成了一半真正的价值在于把它用起来。下面三个场景是我这几年遇到频率最高的每个场景的处理思路都不太一样。3.1 场景一VMD动作在不同命名的模型之间移植把 A 模型的动作套到 B 模型上是骨骼对照最经典的使用场景。整个流程里最关键的一点是VMD 文件是按骨骼名称字符串匹配的不是按索引。也就是说哪怕两个模型的骨骼结构和顺序完全一致只要名字差一个字动作就套不上。更麻烦的是 VMD 格式对骨骼名有硬性限制——名称字段长度固定为 15 字节的 Shift-JIS 编码。一个日文假名占 2 字节所以上半身2占 8 字节没问题つま先.L占 12 字节也没问题但如果某个模型作者把骨骼名写成左手中指第1关节9 个汉字 18 字节超出部分会被截断动作数据就永远匹配不上。我的处理顺序是这样的先把目标模型的骨骼列表完整导出跟动作作者常用骨骼名做个差集。差异项里凡是结构相同只是叫法不同的直接改名对齐凡是结构不同的老老实实做映射。改名只在本地名上做通用名字段保持原样避免破坏导出到其他引擎的兼容性。改完先套一个包含走位、挥手、转身的测试动作确认センター、上半身2、腕捩这几根关键骨都动起来了。改名的原则是改模型迁就动作而不是反过来。原因很现实一份热门动作数据可能有几万个模型在用而你的模型只有一个。3.2 场景二写脚本批量生成骨骼对照表手工整理对照表在骨骼数超过一百的时候就彻底不现实了。用脚本读取 PMX 并导出骨骼名是我目前最推荐的做法。# 读取 PMX 文件导出骨骼索引、本地名、通用名 # 依赖 pymeshiopip install pymeshio import pymeshio.pmx.reader as pmx_reader model pmx_reader.read_from_file(your_model.pmx) print(f骨骼总数: {len(model.bones)}) print(f{索引:4} | {本地名:16} | {通用名:18} | 父骨) print(- * 60) for idx, bone in enumerate(model.bones): parent bone.parent_index parent_name model.bones[parent].name if parent 0 else ROOT # 用 utf-8 输出到控制台避免日文乱码 print(f{idx:4} | {bone.name:16} | {bone.english_name:18} | {parent_name})跑完这个脚本你会得到一份完整的骨骼清单。接下来把清单和标准名做个模糊匹配就能快速找出命名不一致的地方。我常用的匹配策略是分三级匹配级别判断依据处理方式完全匹配名称字符串完全一致直接可以用无需处理结构匹配父骨链和位置大致对应建立别名映射脚本自动替换无法匹配结构也对不上人工介入判断是否要新增骨骼# 别名映射表把模型里的方言名映射到标准名 # 键是模型里的名字值是标准动作数据里的名字 ALIAS_MAP { 肘.L: ひじ.L, 肘.R: ひじ.R, 膝.L: ひざ.L, 膝.R: ひざ.R, 足IK.L: 足.L, # 半角转全角 足IK.R: 足.R, 上半身1: 上半身, アッパーボディ: 上半身, } def normalize(name: str) - str: # 先做去空格和统一大小写再查别名表 key name.strip() return ALIAS_MAP.get(key, key)这段代码里足IK.L到足.L的映射就是上面提到的全角半角问题。韩国、国内和部分欧美作者做的模型经常写成半角套标准动作就会丢 IK。3.3 场景三外部动捕数据重定向到PMX用动捕设备或者从别的软件导出 BVH、FBX 数据再重定向到 PMX 模型上这个场景对骨骼命名对照的要求最高。因为动捕数据的骨骼命名体系跟 MMD 完全是两套东西像Hips、Spine、LeftUpperArm到センター、上半身、腕.L中间要经过一层完整的语义映射。我的建议是不要直接在 MMD 里操作先用 Blender 做中转。流程是导入动捕数据导入 PMX 模型用 MMD Tools 插件然后在 Blender 里做骨骼重定向最后导出 VMD。这里有一个必须注意的坐标系问题MMD 用的是左手坐标系Y 轴朝上、Z 轴朝前Blender 是右手坐标系Z 轴朝上大多数动捕数据是右手系。三套坐标系叠在一起如果不做轴变换重定向完的动作要么上下颠倒要么左右镜像。我一般在 Blender 里统一处理让 MMD Tools 负责最后的轴向转换这样比在 MMD 本体里硬调要可靠得多。重定向时的映射表建议按层级优先来组织先映射根骨链再映射四肢最后映射手指和辅助骨。根骨错了整体位置就全错先修根骨能避免后面反复返工。4. 常见坑与排查速查表这一节是我自己踩过、也看别人踩过的坑的汇总。骨骼名称对照这件事八成的问题都不在概念不理解而在字符和结构层面的细节。4.1 字符层面的三个隐形杀手第一个是全角半角。前面已经说过足.L的问题其实不止这一处。有些模型会把点号写成全角而不是半角.从视觉上看几乎分辨不出来但字符串比较直接失败。我的做法是脚本里加一层字符规范化把所有全角标点统一转成半角再比较。import unicodedata def normalize_width(s: str) - str: # 把全角字符统一转成半角保留假名和汉字 result [] for ch in s: code ord(ch) # 全角字母数字和标点区间 if 0xFF01 code 0xFF5E: result.append(chr(code - 0xFEE0)) else: result.append(ch) return .join(result)第二个是 VMD 的 15 字节截断。骨骼名超过 15 字节的模型在 MMD 本体里做动作没问题但一旦经过某些工具中转名字会被截断。对策是尽量把本地名控制在 7 个日文字符以内超出的用缩写。第三个是编码。VMD 用 Shift-JIS 存名字PMX 用 UTF-16 或 UTF-8取决于版本和作者中间转换一次就可能出现乱码。用脚本处理时读 PMX 一律按二进制路径读让解析库负责解码不要自己open(..., encoding...)硬读。4.2 结构层面的三个高频陷阱IK 骨被当成普通骨处理。足.L在 PMX 里是一根带 IK 设置的骨它的位置在脚尖附近但旋转它并不会让大腿跟着转——真正让腿动起来的是 IK 求解器驱动的足.L和ひざ.L。如果重定向脚本把 IK 骨当成普通骨直接写旋转数据腿会原地扭成一团。D 骨和捩り骨被遗漏。这类骨不参与动作数据的直接驱动但它们是追加变形的接收端。如果模型改造时把腕捩.L删掉了手臂扭转的效果就没了表现为前臂在旋转时出现明显的糖纸收缩。判断方法很简单手臂绕自身轴转 90 度看前臂有没有变细。根骨映射反了。全ての親和センター都像是根骨但它们在层级上是父子关系。把动捕数据的Hips映射到全ての親转身的时候就会变成整个模型绕脚底转而不是绕重心转。正确做法是把Hips映射到センター全ての親留给整体的世界位移。4.3 骨骼匹配问题排查速查表现象最可能的原因排查动作动作套上后完全不动骨骼名整体不匹配或 VMD 版本不兼容导出目标模型骨骼列表逐条比对只有某条腿不动该侧足全角半角不一致直接肉眼比对字符或用脚本做宽度规范化手臂旋转时变细腕捩或手捩缺失/未映射检查这两根骨是否存在且名称匹配裙子飘不起来物理骨名不在动作认可范围内正常或刚体关节设置丢失检查物理设置不要指望动作数据驱动物理骨转身时整体绕脚转全ての親与センター映射颠倒检查根骨层级确认父子关系手指僵直手指骨命名与动作数据的编号体系不一致检查親指0是否存在其余手指是否从 1 开始导入后骨骼名显示乱码编码不匹配用二进制方式读取交给解析库处理改名后物理失效破坏了刚体/关节对骨骼的引用改名要用 PMX Editor 的批量替换不要手工逐条改提示排查骨骼匹配问题时最快的办法不是看眼睛比字符串而是导出两份骨骼名列表丢进 diff 工具。人眼对ひじ和肘的差异不敏感对和I更是完全没有识别能力。5. 我在实际改名前会走的一套固定流程前面讲的都是理论和排查最后说一下我每次动骨骼名之前会走的固定流程。这套流程的核心目的是任何改名动作都必须可回滚、可验证、可批量。5.1 改名前必须确认的四件事第一件确认模型的本地名和通用名是否分家。如果通用名字段是空的说明原作者没考虑跨引擎使用改动空间比较大如果通用名有内容那本地名最好别动改通用名就够用了。第二件确认物理设置里的刚体、关节引用的骨是哪些。有些物理设置会直接引用骨骼索引改名不影响但如果你是用工具做的重命名工具可能顺手重建了骨骼列表索引一变物理就全乱了。稳妥的做法是用 PMX Editor 的名称检索替换功能它只改字符串不动结构。第三件确认模型有没有自定义表情Morph里绑定了骨骼。比如有些模型做了笑い表情实际是驱动口或者あご骨。改名后这些表情可能失效需要一并检查。第四件准备好一份测试动作。我常用的是自己攒的一个小文件只包含最基础的几帧抬手、抬腿、转身、下蹲。改完名直接套上去看十秒钟就能判断有没有大问题比全流程测一遍快得多。5.2 一套可以直接抄的批量改名方案在 Blender 里配合 MMD Tools 做批量改名比在 PMX Editor 里手点要快得多尤其是需要改几十根骨的时候。下面这段代码是我用了很久的模板import bpy # 键是模型当前的名字值是目标标准名 RENAME_MAP { 肘.L: ひじ.L, 肘.R: ひじ.R, 膝.L: ひざ.L, 膝.R: ひざ.R, アッパーボディ: 上半身, ロワーボディ: 下半身, } def rename_bones(armature_nameArmature): arm bpy.data.objects.get(armature_name) if arm is None: raise RuntimeError(找不到骨架对象请确认名称) changed 0 for bone in arm.data.bones: target RENAME_MAP.get(bone.name) if target is None: continue old bone.name bone.name target changed 1 print(f{old} - {target}) print(f共修改 {changed} 根骨骼) rename_bones()这段代码有两个地方值得说明。一是必须先切到编辑模式之外执行骨骼重命名在编辑模式下和物体模式下行为不一致容易出问题。二是重命名会连带更新所有引用该骨骼的地方顶点组、约束但不会自动更新自定义属性里存的字符串如果你的模型上有脚本驱动的自定义属性需要单独检查。改完名之后我会用 MMD Tools 导出一次 PMX再重新导入看骨骼列表是否稳定。这一步主要是验证有没有编码或者长度问题。如果重新导入后骨骼名出现问号或者被截断说明有字符超出了 PMX 或 VMD 的承载范围需要换更短的写法。最后分享一个小技巧把骨骼名对照表存成 CSV用脚本管理而不是硬编码在代码里。原因是模型太多了每个模型都可能有自己的方言硬编码的字典会越写越长、越来越乱。用 CSV 管理的话你可以按模型名分文件用的时候动态加载改起来也方便甚至能直接用表格软件筛选。我自己那份表已经积累了三百多行全靠 CSV 撑着换成代码里写死早就没法维护了。