People of Note = 音乐剧式回合制 RPG。
a turn-based RPG set in a world with music as its very lifeblood
一个回合制 RPG，设定在一个"音乐就是生命血液"的世界里
DSLR = digital single-lens reflex camera
shutter speed = 快门速度
影响运动模糊、进光时间。快门慢，画面更容易亮，也会产生拖影/长曝光效果。
aperture = 光圈
影响进光量和景深。光圈大，背景更容易虚化；光圈小，前后都更清楚。
ISO = 感光度
影响亮度和噪点。ISO 高，画面更亮，但真实相机里噪点也可能更多。
white balance = 白平衡
控制画面偏冷还是偏暖。比如让白色在不同光源下仍然看起来像白色。
exposure comp settings = 曝光补偿设置
在自动/半自动曝光逻辑上，让画面整体更亮或更暗。
long-exposure effect = 长曝光效果
模拟真实相机长时间曝光时出现的视觉效果，比如车灯拉成光轨、水流变丝滑、移动物体留下残影。
that I believe is the first of its kind in Unreal
= 我认为这是 Unreal 里同类中的第一个。
不是说 Unreal 第一次有相机，也不是说 Unreal 不能做长曝光；他说的是他做的这个 游戏内可控的长曝光模拟效果，他认为在 Unreal 项目里比较首创。
console porting 里的 console 是：
游戏主机 / 家用游戏机平台
比如 PlayStation、Xbox、Nintendo Switch 这类。
porting 是：
移植
所以 console porting = 主机平台移植，意思是把原本可能主要在 PC / Unreal 开发环境里运行的游戏，适配到主机平台上。
UEFN 確實很像一個 Fortnite 專用版 UE / 類 Ark DevKit 。它不是完整自由的 Unreal Engine，而是被綁定到 Fortnite 規則、Fortnite 發布管道、Fortnite 玩家入口、Fortnite 資產與審核系統裡的創作工具。Epic 官方也把 UEFN 定義為「用來設計、開發並直接發布遊戲到 Fortnite 的 PC 應用」。Epic Games Developers
但它和 Ark DevKit 的本質差異在這裡：
Ark DevKit 是「某個遊戲的 Mod 工具鏈」。它的中心仍然是 Ark。你做的是 Ark 這個遊戲的內容擴展、地圖、模組、玩法修改。它像是：一個已存在遊戲開放了部分編輯權限。
UEFN/Fortnite 的方向是「把 Fortnite 變成內容平台」。它的中心不再只是 Battle Royale，而是 Discover、Creator Portal、島嶼發布、玩家流量、 engagement payout、Verse、IP 資產、商務、跨平台運行。官方說 UEFN 給你的是 build、launch、grow your game in Fortnite；Fortnite 開發者頁也明確說可以用 UEFN、Verse、Creative 工具在 PC、mobile、console 上 build、launch、publish games in Fortnite。Epic Games Store+1
所以你的困惑來自兩個視角衝突：
玩家視角：Fortnite = 一個遊戲。
創作者視角：Fortnite = 一個可以發布作品的容器。
Epic 戰略視角：Fortnite = 下一代遊戲/社交/品牌/IP/創作者經濟的平台入口。
跨遊戲的數位資產互通，是元宇宙敘事裡的一個技術/商業功能；元宇宙是更大的容器概念。
Metaverse / 元宇宙 說的是「這些互通世界共同形成的持續性空間」。
它不只是資產流通，還包括玩家身份、社交關係、內容發布、經濟系統、世界入口、平台治理、伺服器運行、內容審核、IP 授權、支付分潤。
Epic 真正想要的是把 Fortnite 變成某種「遊戲世界瀏覽器」。The Verge 對 2025 年 Unity/Fortnite 合作的報導也把它描述成 Fortnite 逐步成為 social and gaming hub，讓不同開發者的遊戲能在 Fortnite 裡被發現與參與經濟系統。
在 Epic Games Store 買某個第三方遊戲，獲得 Fortnite 物品。這是 Epic 現在推的重點，目的是讓 EGS 的購買行為和 Fortnite 的身份/外觀系統綁起來。Epic 官方的「Gift-with-Purchase」頁面也列出這類購買後可獲得 Fortnite 物品的活動。
未來的開發者既可以用 UE6 製作傳統的 3A 獨立大作，也能同時讓這些內容無縫接入元宇宙生態。
《Rocket League》（火箭聯盟）可以粗暴理解成：用火箭車踢足球的競技遊戲。
它的基本玩法是：
兩隊玩家各自開一台可以加速、跳躍、飛起來的車，在一個封閉球場裡撞一顆巨大足球，把球打進對方球門。官方自己稱它是 "arcade-style soccer and vehicular mayhem"，也就是街機足球 + 車輛混戰。
公開報導指向 Rocket League 會成為第一個被拿來展示/轉向 Unreal Engine 6 的 Epic 遊戲案例，而不是 Fortnite。原因很合理：Rocket League 現在技術底座很老，長期仍基於 Unreal Engine 3，所以它需要一次大遷移；拿它做 UE6 示範，比拿已經升到 UE5 的 Fortnite 更有「代際轉換」意義。
Epic 多遊戲生態整合層 ：部分是。
Rocket League 本身有車、外觀、競技、跨平台帳號、live-service 經濟，這些都適合被納入 Epic 的大平台生態。它可以成為 Epic 測試「一個既有大型遊戲如何被新版引擎、外觀經濟、Fortnite 生態、帳號系統重新連接」的案例。
Open Metaverse 完整落地層 ：還不是。
完整 Open Metaverse 應該意味著跨遊戲身份、資產、商務、發布、社交、治理都能互通。現在 Rocket League 更像是「第一個 UE6 化的代表遊戲」，不是「第一個完整開放元宇宙世界」。目前更明確的 Open Metaverse 落地信號反而是 Epic × Unity 合作：Unity 遊戲將能進 Fortnite，並參與 Fortnite Creator Economy；Unity 商務平台也會支援 Unreal Engine。這才更直接對應「不同引擎、不同開發者、同一入口、同一經濟系統」的互通方向。
單機老遊戲重製 = 把舊內容用新技術重新做一遍。
Rocket League 遷移 = 把一個仍在運轉的線上經濟體、競技體系、外觀資產庫，搬到 Epic 下一代技術棧裡。
所以它和生態有關，不是因為「換 UE6」這件事本身神聖，而是因為它會測試幾個生態級問題。
舊資產如何繼續活下去。Rocket League 有大量車身、輪胎、貼花、尾焰、特效、品牌聯動物品。如果遷移到新 UE 後，這些資產能被保留、升級、標準化，那就說明 Epic 有能力把老遊戲的資產庫轉成新平台可承認的資產系統。這和未來跨遊戲資產互通直接相關。
玩家身份和經濟如何不斷裂。你不是重開一個新遊戲，而是要讓玩家的庫存、排名、帳號、購買歷史、賽季進度、好友關係盡量延續。這就是平台能力，不是普通重製能力。
「樂高積木城堡」對應的是 Fortnite 生態裡的 LEGO Islands / LEGO Fortnite / UEFN LEGO 工具 。Epic 和 LEGO Group 有長期合作，LEGO 官方在 2023 年宣布《LEGO Fortnite》上線，並說雙方會把大量實體 LEGO 元件做成 digital twins，提供給 Fortnite 生態中的 UEFN 和 Fortnite Creative 創作者使用。LEGO Store
所以它和 Fortnite 的關係不是「Fortnite 裡剛好有個像樂高的材質包」，而是：
Fortnite 主程式 = 玩家入口。
LEGO Fortnite = Fortnite 裡的一組 LEGO 主題遊戲/體驗。
UEFN / Fortnite Creative = 創作者做 LEGO 島嶼的工具。
LEGO Brick Editor = 在 UEFN 裡一塊一塊搭 LEGO 的工具。
α 测试通常由用户或潜在用户在开发方控制的环境下进行。β 测试才更接近真实用户环境。
センター
center。MMD 里常见的中心骨，通常控制躯干整体位置，位置大概在骨盆/身体中心附近。
真正能在重定向里修改骨骼姿势的是 IK Retargeter 的 Retarget Pose Edit Mode。
还在 Asset Settings 模式。这个模式只是设置 Source IK Rig、Target IK Rig、Preview Mesh、Offset、Root Lock 等资产参数，不是姿势编辑模式。
当前 Retargeter/IK Rig 配置处在不稳定状态，你一移动骨骼触发重算，UE 访问到异常骨骼数据或空 root，于是直接崩。
IK Retargeter could not find source root bone
这不是普通警告。它说明 Retargeter 在运行时找不到 Source 侧的 Retarget Root。IK Retargeter 的正常前提是：Source IK Rig 和 Target IK Rig 都要有 Retarget Root，并且 Retargeter 要绑定这两个 IK Rig。官方的 IK Retargeter 流程也是先定义 Source/Target IK Rig，再进入 Edit Retarget Pose 做姿势校准。Epic Games Developers+1
你一移动骨骼时，系统会重新计算 Retarget Pose、chain mapping、root transform、post-process animation blueprint。现在 source root 为空，target 又是 MMD/PMX 这种带 全ての親 / 操作中心 / センター / IK親 / IK 的非 UE 标准骨架，崩溃概率就会变高。
不让 Manny 的后处理蓝图、Control Rig、IK 修正逻辑参与。Post Process ABP 会在预览阶段继续改 pose，你移动骨骼时它也可能参与求值，增加崩溃面。
打开 Manny/Mannequin 的 Source IK Rig。不要在 Retargeter 里修，去源 IK Rig 资产里修。Hierarchy 里选 Manny 的 root/pelvis。一般 UE Manny 有 root 和 pelvis 两层：如果官方 IK Rig 已经有 root 设置，沿用官方资产；如果你自己建的 IK Rig，通常先选 pelvis 或 root 测试，但必须保证它被设置成 Retarget Root。设置后保存。
WWDC26 是 Apple 的 2026 年 Worldwide Developers Conference，中文通常叫「苹果全球开发者大会」。
它不是普通发布会，而是 Apple 每年给开发者看的核心大会，主要公布下一代系统、开发工具、API、框架和平台方向。2026 年的 WWDC26 时间是 2026 年 6 月 8 日到 6 月 12 日 ，线上免费举行，开幕当天 Apple Park 也有线下特别活动。Apple Developer+1
对普通用户来说，WWDC26 重点通常是：
iOS、iPadOS、macOS、watchOS、tvOS、visionOS 的新版本；
Apple Intelligence / Siri / AI 功能的更新；
开发者工具，比如 Xcode、Swift、App Store、SDK、框架变化；
可能但不保证会有硬件发布。
对股民来说，WWDC26 的重点不是「今天卖了多少 iPhone」，而是看 Apple 有没有拿出能让市场相信的 AI 路线。Reuters 也提到，Apple 这次会展示平台更新、AI 进展和新的软件/开发者工具；背景是市场一直质疑 Apple 在 AI 上落后，尤其是 Siri 升级延迟。Reuters
所以 WWDC26 对 AAPL 股价的意义大概是：
如果 Apple 展示出可信的 AI、Siri、开发者生态升级，市场可能重新给 Apple AI 叙事估值。
外包适合做：
兼容性测试：大量手机、显卡、系统版本、分辨率。
重复性功能测试：安装、登录、支付、升级、卸载、基础流程。
本地化测试：多语言 UI 溢出、翻译上下文、文化问题。
Playtest 招募：找一批真实玩家玩，收集反馈。
压力/规模测试：多人房间、服务器负载、网络波动。
回归测试执行：按测试用例反复跑。
所以在 UE 项目里，工作对话可能是：
"技能距离是 0～1000cm，测一个 500 的正常值，再测 1000、1001。负距离理论上不会出现，但数据表里也加个非法值检查。"
这句话背后的测试术语就是：
500：有效等价类代表值。
1000：边界值。
1001：无效等价类代表值。
非法负数：异常输入 / 防御性测试。
他们更可能说：
"等级范围 1～90，正常值测一个，0 和 91 也测一下。"
而不是说：
"请覆盖一个有效等价类和两个无效等价类。"
他们会说：
"这个输入分三类：合法、太小、太大。"
而不是说：
"这里有一个 valid partition 和两个 invalid partitions。"
所以答案是：概念会用，术语不一定天天挂在嘴边。
超大企业，例如金融、电信、车载、医疗、政企软件，可能会更重流程。它们可能采用规模化敏捷框架。SAFe 官方定位就是帮助组织成为 Lean Enterprise、获得 Business Agility；IBM 对 SAFe 的解释也提到大型企业用 Agile Release Trains 协调多个小团队朝共同目标工作。Scaled Agile Framework+1
所以行业不同，答案不同：
| 公司类型 | 更像什么 |
|---|---|
| 互联网 App / SaaS | Agile + CI/CD + DevOps/SRE |
| 大型游戏公司 | 里程碑制 + X式迭代 + 独立 QA + 内容管线 |
| 金融/政企/医疗 | W/V + 审批合规 + 自动化测试 + 部分敏捷 |
| 底层系统/芯片/车载 | V/W 更重，验证更严格 |
| 超大多团队平台 | SAFe/自研规模化敏捷 + Release Train |
| 创业公司 | 粗糙 X 模型，快速做、快速测、快速改 |
静态测试：不运行程序，通过阅读、审查、分析发现问题。
这就是白盒测试的语言。资料里的设计题要求画控制流图，并按语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖、路径覆盖设计用例，
决策表的价值是：
把一堆 if/else 组合摊平，让你知道每种业务规则有没有测试。
但公司里它不是废话，它解决的是一个管理问题：
一个 Bug 从被发现到被真正解决，中间有很多状态。如果没有状态，就没人知道它现在到底归谁管。
比如 QA 发现一个问题：
"角色闪避后偶尔无法攻击。"
如果没有生命周期，可能会变成：
测试说：我报了。
开发说：我没看到。
主程说：这不是我的模块。
策划说：这可能是设计。
测试说：修了吗？
开发说：我本地好了。
上线后又炸。
所以缺陷生命周期的真实作用是建立责任流转。
更完整的生命周期是：
New 新建 ：测试发现问题，提交。
Confirmed 已确认 ：确认这确实是 Bug，不是误报。
Assigned 已分配 ：分给具体开发。
In Progress 修复中 ：开发正在处理。
Fixed 已修复 ：开发提交修复。
Ready for Test 待验证 ：测试准备复测。
Verified 已验证 ：测试确认修复有效。
Closed 关闭 ：这个 Bug 生命周期结束。
Reopened 重新打开 ：复测失败或后续又出现。
Rejected 拒绝 ：不是 Bug。
Deferred 延期：是 Bug，但本版本不修。
Bug 不是一个人的记忆，而是团队资产。
QA：新角色大招后镜头无法恢复。
状态：New。
技术负责人确认：是 CameraManager 状态没有清理。
状态：Confirmed。
分配给玩法程序。
状态：Assigned。
开发修复并提交。
状态：Fixed。
QA 用同一测试用例复测。
状态：Verified。
再跑相关回归：切角色、死亡、过场、传送后镜头都正常。
状态：Closed。
如果修复后发现"死亡后镜头仍然卡住"，就 Reopened。
1. 需求来了
例子：技能释放必须满足"有目标、距离足够、能量足够、角色没被控制"。
2. 设计测试方法
用决策表列条件组合。
用等价类划分距离和能量输入。
用边界值测 SkillRange - 1、SkillRange、SkillRange + 1。
用覆盖标准确认每个条件 true/false 都测到。
3. 写测试用例
Case 1：全部满足，技能释放。
Case 2：无目标，释放失败。
Case 3：距离超出，释放失败。
Case 4：能量不足，释放失败。
Case 5：角色眩晕，释放失败。
Case 6：距离刚好等于最大范围，释放成功。
Case 7：距离超过 1cm，释放失败。
4. 执行测试
手工执行，或者自动化执行。
5. 发现缺陷
比如 Case 7 失败：超过 1cm 仍然能释放。
6. 缺陷进入生命周期
New → Confirmed → Assigned → Fixed → Verified → Closed。
7. 加入回归/自动化
以后每次改技能系统，都自动跑这些用例，防止再坏。
决策表确实可以理解成一种"覆盖表" ，但它覆盖的不是代码语句、代码路径，而是业务规则中的条件组合。
决策表 = 黑盒测试里的条件组合覆盖工具。
這套框架讓你直接用 C++ 代碼來撰寫「預期行為」。它不是去錄製螢幕畫面，而是直接呼叫你寫的 Class 或 API，並驗證結果是否正確。
-
Describe（描述） ：用來定義你要測試的對象或情境（例如：某個函式Execute()）。 -
It（它應該...）：定義具體的預期結果。文件提到一個好習慣是以 "should"（應該）開頭。
呼應你的說法，它的撰寫結構看起來就像這樣直接寫在代碼檔案（通常副檔名為 .spec.cpp）裡：
cpp
Describe("當玩家使用治癒藥水時", [this]()
{
It("生命值應該要增加 50 點", [this]()
{
// 直接呼叫代碼 API
Player->UseItem(HealingPotion);
// 驗證結果
TestEqual("生命值正確", Player->GetHealth(), 100);
});
});文件裡提到了幾個將測試直接寫在 API 層級的好處：
-
不輕易出錯（Less Brittle）：獨立的模擬軟體如果遇到 UI 介面改版、按鈕換位置，測試就會直接崩潰。但測試內部的 API 邏輯，只要公開的介面（Public API）沒變，測試就不會壞。
-
自我文件化（Self-documenting） ：因為用了
Describe和It的語意化結構，測試跑完後的報告讀起來就像人類的句子（例如：Execute() should return true when successful），不管誰來看都能一眼搞懂這段代碼的「規格」。 -
獨立性高 ：每一個
It都是一個獨立的測試案例，失敗時能精準定位是哪行代碼、哪個邏輯出錯，而不是只告訴你「外部模擬點擊時卡住了」。
3. 它還支援哪些進階功能？
雖然是寫在代碼裡，但它為了模擬複雜的遊戲運行環境，提供了很強大的擴充：
-
BeforeEach/AfterEach：在每個測試開始前初始化資料（如生成一個玩家），結束後清理乾淨。 -
非同步與延遲執行（Async / Latent） ：遊戲裡很多行為需要跑好幾影格（Frame）或等待網路回傳（例如查詢資料庫）。它支援
LatentIt，可以等代碼執行完並呼叫Done.Execute()後才結束測試，這在處理多執行緒或需要時間的遊戲邏輯時非常方便。
-
Debug Log（被動記錄器） ： 就像是飛機的「黑盒子」或行車紀錄器。它本身不會主動去測試 任何東西，只有當你啟動遊戲、實際去玩、觸發了某行代碼時，它才會在畫面上或日誌裡印出一行字（例如：
"Player health is 100"）。你必須用肉眼去檢查這些 Log 是不是你想要的。 -
Automation Spec（主動斷言檢查器） ： 它是一個主動出擊的監測系統 。你不需要真的打開遊戲去玩，測試框架會自己模擬出代碼運行的環境，直接呼叫那個 API，並用
TestTrue或TestEqual這類「斷言（Assertion）」去強行驗證結果。如果結果不對，它會直接亮紅燈報警。
2. 為什麼說它是「深度 UE 綁定」？
你說得非常對，它確實是「深度 UE 綁定」。Web 開發（例如 JavaScript/Jest）的測試框架只能測試純粹的邏輯資料；但 UE 的 Automation Spec 除了能測試純 C++ 邏輯外，還深度整合了 Unreal Engine 的底層特性：
-
影格與時間綁定（Latent Actions） ：遊戲裡很多事情不會在 1 毫秒內結束（例如角色放技能、生成特效、UI 淡出）。UE 的 Spec 支援
LatentIt，可以讓測試代碼「等待幾個影格」或「等待特定秒數」後，再檢查 API 的狀態。 -
執行緒與任務圖（Task Graph）綁定：它可以指定某個測試區塊要在遊戲主執行緒（Game Thread）跑，還是要在渲染執行緒、甚至後台異步執行緒（Render/Worker Thread）跑，這是一般網頁測試軟體做不到的。
-
編輯器與遊戲世界綁定 ：它可以命令引擎在後台偷偷生成一個虛擬的
UWorld、塞入幾個AActor（例如怪物和玩家），讓它們互相施放技能，測試完後自動把這個虛擬世界銷毀，完全不著痕跡。
速度極快（省去載入地圖的時間）
在正常開發中，如果你要測試「怪物會不會被牆壁擋住」，你得：打開 UE 編輯器 \\rightarrow 點擊 Play \\rightarrow 等待場景、UI、特效載入 \\rightarrow 把怪物拉到牆壁前 \\rightarrow 觀察結果。這可能要花上好幾十秒甚至幾分鐘。
但在 Automation Spec 裡，因為這個 UWorld 是純代碼在記憶體裡建立的，沒有圖形渲染、沒有沉重的地圖資產、沒有音效 。執行這整個測試可能只需要幾毫秒（0.001 秒）。你可以一秒鐘跑完幾百個這種世界級的測試。
自動化與持續整合（CI/CD）
因為這個過程不需要真的開起遊戲視窗，它可以在「命令列模式（Command Line）」下默默執行。這意味著你可以把它部署在公司的伺服器上。每天晚上半夜，伺服器會自動拉下最新的代碼，在後台瘋狂創建幾千個虛擬 UWorld 來測試各種戰鬥、技能、AI 邏輯，隔天早上直接把「亮紅燈」的錯誤報告寄給工程師。
解决的是一个宿主渲染差异问题：PMX/MMD 的材质系统不是 Blender 的节点材质系统。MMD 里一个材质通常由这些东西组成：
普通贴图：base texture / diffuse texture
toon texture：模拟卡通阴影阶梯
sphere texture：类似环境反射、MatCap、叠加高光的效果
材质参数：diffuse、specular、ambient、alpha、edge、double-sided 等
节点逻辑：在 MMD 里是固定渲染器解释，不是 Blender Shader Node Graph
但 Blender 5.1 里，材质主要通过节点表达。官方文档里 Principled BSDF 是一个把多层材质属性合到单个通用 shader 节点里的模型，可以表达大量常规材质。也就是说，Blender 的标准入口是 Material Output ← Principled BSDF ← 贴图/参数 这一套节点体系。
Subsurface：转换时给 Principled BSDF 的 Subsurface 一个值，通常用于皮肤半透感；你这里是 0，等于不加皮肤 SSS。
普通图形学的角色资产通常是：
Mesh 网格 → Material 材质 → Skeleton 骨架 → Skin Weight 蒙皮 → Animation 动画 → Renderer 渲染
MMD/PMX 角色多出来的特殊层是：
MMD Bone 语义 → IK 规则 → Morph 表情/材质变形 → Rigid Body 刚体 → Joint 物理约束 → Toon/Sphere 非 PBR 材质 → Helper/Temporary 转换对象
所以你看到的这些不是"一个模型的一部分"这么简单，而是 MMD 生态为了让角色在 MikuMikuDance 里直接跳舞、甩头发、飘裙子、动表情而设计的完整角色运行时结构。
Rigid Body 刚体
传统图形学里，刚体是物理模拟概念：一个不会变形的碰撞对象，有质量、碰撞形状、阻尼、摩擦、反弹等。MMD 的特殊点是：它不是为了真实物理，而是为了角色二次元表演服务。头发、裙摆、袖子、饰品通常不是布料模拟，而是一串串小刚体加约束。也就是用"很多小硬块 + 关节限制"伪装出柔软运动。
这和 UE/Unity 里的 Ragdoll、Physics Asset 很像，但 MMD 的目标更窄：让头发和裙子在舞蹈动画里便宜、稳定、可控地摆动。
Joint 约束
Joint 是刚体之间的限制关系。它规定两个刚体之间能不能拉开、能不能旋转、旋转角度范围是多少、有没有弹簧回弹。传统物理里这就是 constraint / joint solver。MMD 特殊点在于它大量用在头发、裙子、飘带上，而不是用真实布料网格求解。
mmd_tools 手册里还提到，Blender 和 MMD 的刚体碰撞组逻辑不同：Blender 更偏"哪些组互相碰撞"，MMD 是"哪些组不碰撞的 mask"。mmd_tools 为了模拟 MMD 的非碰撞逻辑，会生成 temporary/ncc* 约束来禁用某些刚体之间的碰撞，因此会比 Blender 普通刚体模拟更慢。MMD & Blender Wiki
MMD 的设计目标更窄：它主要服务于"角色舞蹈模型"。它关心的是头发、裙子、胸部、袖子、飘带、身体这些部件之间怎么避免穿模、怎么保留二次元角色的表演稳定性。所以 PMX 里的刚体组逻辑很自然地变成：
"这个刚体属于某组；它不应该和哪些组发生碰撞？"
也就是排除表 。这对角色很方便，因为一个角色模型里常见需求是：裙子内部刚体彼此不要撞，头发链条内部不要互相炸，身体/腿/手和衣物要有选择地互动。很多时候，默认是"大家可以碰"，然后局部标记"不许碰"。LearnMMD 对裙子物理的解释也是这种思路：某些裙子刚体设置成同一类非碰撞组，因此它们彼此不互动，但身体刚体不在它们的非碰撞排除里，所以腿碰到裙子时裙子仍会动。Learn MikuMikuDance
Blender 的设计目标更宽：它不是专门为了 MMD 角色物理做的，而是一个通用 DCC。刚体系统要服务积木、建筑倒塌、道具、碎片、机械、抽象动画、物理摆拍等。Blender 的 Rigid Body World 本质上是一个场景级物理世界，文档里也说它保存一组参与同一刚体模拟的对象，并提供统一设置。Blender Documentation 这种系统更倾向于问：
"这个对象参与哪些碰撞组？"
也就是包含表 / 允许表 。Blender 手册旧版说明中也把 Collision Groups 描述为把刚体碰撞分配到不同组，最多 20 组。Blender Documentation
这两个表达在数学上看似可以互相转换，但在软件工程上不是同一个东西。
假设有 16 或 20 个碰撞组。
MMD/PMX 的逻辑像这样：
对象 A 属于组 3。
A 的 mask 勾掉组 5、组 8。
意思是：A 不和 5、8 碰；其他默认可以碰。
Blender 的逻辑更像：
对象 A 被放入某些可碰撞组。
只有组关系允许时才参与碰撞。
看起来只是"取反"而已，但问题在于：MMD 的 mask 是每个刚体自己的排除关系；Blender 的碰撞组是物理系统提供的组过滤能力。两者不是同一粒度。
MMD 是"每个刚体携带一张黑名单"。
Blender 是"物理世界根据组来决定谁可能相互作用"。
这就像权限系统里：
MMD：默认允许，逐项 deny。
Blender：默认按组 allow。
做通用 3D 动画/VFX/motion graphics 的人。
他们经常不是在维护一个"角色内部物理格式"，而是在做一段效果：
一堆方块掉下来。
一面墙被撞碎。
一串机械零件互相铰接。
几个道具在桌面上滚动。
物体受风场、力场、动画关键帧、约束共同控制。
对这类用户来说，最自然的是：
"我先选一批对象，把它们加入模拟。"
"我再把某些对象设为 Active，某些设为 Passive。"
"我再用约束控制它们之间的关系。"
Blender 的刚体约束也正是这种通用物理/机械连接语义：Fixed、Point、Hinge、Slider、Piston、Generic、Generic Spring 等类型，都是面向"两个刚体之间如何连接/限制"的通用物理关系。Blender Documentation+1
第三类是做道具、机械、关卡原型、物理摆拍 的人。
他们通常关心的是对象作为"场景物体"的行为，而不是角色资产内部的 PMX mask 规则。比如：
门铰链。
吊灯摆动。
箱子堆叠。
机关滑轨。
弹簧连接。
小球碰撞。
破碎物件。
这种人群的习惯是"按对象/collection/约束组织场景"。Blender 的 collection 体系本来就是组织场景对象的核心工具，所以刚体世界也顺着这个体系走：把参与模拟的对象放进 RigidBodyWorld collection，把约束放进 Constraints collection。Blender Documentation
第四类是 Blender 传统用户，也就是先有场景对象，再给对象加物理 的人。
这和 MMD 的逻辑不同。
MMD/PMX 更像：
"这是一个角色模型文件。"
"角色里面已经有骨骼、刚体、joint、碰撞组 mask。"
"导入后应该保持角色内部物理关系。"
Blender 更像：
"这里有一堆 mesh object。"
"我给某些 object 加 rigid body。"
"我把它们放入某个 Rigid Body World。"
"它们作为场景对象参与模拟。"
所以 Blender 的 rigid body 不是先问"这个角色部件禁止和谁碰撞"，而是先问"哪些对象进入这套模拟世界"。这更顺 Blender 用户对 scene / object / collection 的操作习惯。
第五类是Bullet/通用物理引擎思维的人 。
Blender 的刚体系统历史上基于 Bullet 物理。Bullet 这类通用物理引擎的常见抽象是：
collision object
collision shape
world
constraint
activation
filter group / filter mask
simulation step
这套语言服务的是"物理世界里有很多对象，逐步求解它们的运动和碰撞"。它不天然服务"角色模型内部的裙子/头发/身体排除表"。所以 Blender 的 UI 最终会更接近通用物理引擎的组织方式，而不是 PMX 的角色资产格式。
在 Blender 中使用 mmd_tools 外掛時，Separate by Materials（依材質分離模型）功能位於 3D 視圖的側邊欄（Sidebar）中。
你可以按照以下步驟找到它：
📌 尋找步驟
-
在 3D 視圖（3D Viewport）中，按下鍵盤上的
N鍵打開右側的側邊欄。 -
在側邊欄的分頁標籤中，點選
MMD。 -
找到
MMD ‣ Model Setup（模型設定）面板。 -
展開下方 的
Mesh（網格） 子項目，你就能看到Separate by Materials按鈕了。
💡 提示與注意事項
-
使用前準備： 點擊該按鈕前，請先在場景或大綱視圖（Outliner）中選取你的 MMD 模型（通常是選取網格物件），否則該功能將無法對正確的物件作用。
-
功能效果： 預設情況下，匯入的 MMD 模型是一個單一物件。點擊 Separate by Materials 後，外掛會自動將模型依不同的材質拆分成多個獨立的網格物件。
-
如何復原： 如果之後你想把拆分好的網格重新合併回去，可以點擊同一個位置下方的
Join按鈕。