零件與共用介面¶

本檔是建模參數的分冊 authority；穩定總入口與既有章節錨點見建模參數.md。

1. 欄位約定¶

欄位	說明
`name`	UI 中文顯示名稱
`field`	GLB extras / Blender Custom Property key
`desc`	用途 / 物理意義
`required`	上鏈時是否必有值（不論玩家填還是 auto 算）
`auto`	是否由 Stage 2 / 3 自動產生
`edit`	編輯器內玩家是否可改

required 與 auto 是正交維度：

required	auto	語意	範例
✅	❌	玩家必填	`material`、`type`
✅	✅	系統一定算得出	`auto_volume_m3`、`auto_mass_g`
❌	❌	玩家可選	`magnet_source_strength_n`（預設 0）
❌	✅	系統可能算不出 / 不適用	`auto_inferred`（沒推斷就空）、`auto_thermal_limit`（全 sub-mesh null 就 null）

required 三類表達：本檔 required 欄位可能寫為 ✅（無條件必填）/ ❌（可省）/ <條件> 必填（如「active 必填」、「actuator 必填」、「多材質 part 必填」、「rain/snow 必填」— 滿足條件時必有值、否則欄位可省）。「必有值」與值的來源（玩家手填 / Stage 2-3 auto 算 / auto 後手動覆寫）無關。

共通鐵則（GLB 上鏈後不可修改）：所有欄位的 ✏️ 編輯權限僅限上鏈前（Stage 1 / 2）。GLB 一旦上鏈，所有 extras、mesh、Mount transform 全部 immutable（CID 鎖死，見 §10）。

2. GLB Root Extras — 玩家宣告欄位（零件 + 場地共用）¶

name	field	desc	required	auto	edit
schema 版本	`open4wd_version`	此 GLB extras 符合的 schema；開發期只接受版本規範.md §15 的 current marker 與 current PhysicsManifest（含 projectile LaunchExit、場地／車輛純視覺碎片 descriptor、逐實際 intact collider 六向接觸面積、逐 tire region wear capacity、mW／mJ 能量契約、能量域熱、六軸 aero、typed weather／track entity topology），所有 Open4WD GLB 共用	✅ 必填	canonical finalizer 寫入	🔒 系統寫入、不可改
部件類別	`type`	`chassis / body / tire / motor / battery / roller / chip / weapon`（零件）/ `track`（場地，欄位見 §8）	✅ 必填	UI 先選後上傳	🔒 編輯器內不可改；type 於 Stage 1–2 定案（見 §10.1）
主材質	`material`	從材質表.md 選 enum；main-mesh 預設材質（sub-mesh 無對應 `materials[]` 覆寫時的 fallback；零件 + 場地皆必填）	✅ 必填	❌	✏️ Stage 2
多材質清單	`materials[]`	每個 sub-mesh 各自的材質覆寫（`{ mesh_node, material }` 陣列）；單 sub-mesh 零件 / 單材質場地可留空（fallback 到 `material`）	多 sub-mesh part / 場地 sub-mesh 有不同材質需求時必填	Stage 2 從 GLB sub-mesh 解析	✏️ Stage 2

open4wd_version + type 是統一識別 marker（零件與場地共用）。current marker 以版本規範.md §15 為唯一數值權威；無 marker 視為待正規化的一般外部 glTF，其他 marker 直接拒絕。type === "track" 走場地解析，其餘走精確零件類型解析。current marker 的精確 type 是重開／fork 的身分權威，不得由 fresh-import UI 覆寫。本機儲存與上鏈共用 canonical finalizer 產生的已標記 bytes；可編輯匯出檔會移除 marker、manifest 與衍生快取，重新匯入時一律視為一般外部來源。 material 與 materials[] 分層：material 是 main-mesh 層的預設材質（always 必填）；materials[] 是 sub-mesh 層的 per-slot 覆寫（單 sub-mesh 或全 sub-mesh 同材質時不需填）。任何 sub-mesh 未在 materials[] 出現 → fallback 到 material。場地 §8 表不再列 material，沿用本表（不重複）；場地的 sub-mesh 覆寫見 §8.5 materials[]。 physics: "visual_only" 不在此表：純視覺無 collider 標記為場景 entity 專用（見 §9.1 / §9.2 與材質表.md §10）。車輛部件所有 mesh 一律有 collider，不適用此設定。 零件每個 sub-mesh 都必須有材質：零件所有 mesh 皆有 collider，未指派材質的 sub-mesh 自動預設為主 material（§11「有值用值，沒值給預設」）；Stage 3 斷言「無任何 collider sub-mesh 缺材質」。不允許「只指派部分 sub-mesh、其餘無材質」（否則可用未指派 sub-mesh 規避碰撞 / 損壞）。與場地差異：場地有 visual_only（無 collider）mesh，sub-mesh 仍 fallback 到主 material、但 visual_only mesh 不影響物理。 node 名稱必須全 GLB 唯一（Stage 1 拒收重名）：全系統以節點名稱為 key（materials[].mesh_node、weapon_main_mesh_node、Mount_* 配對、Axis / Pivot、track.route[] / track.checkpoints[] 引用、entity node 等），glTF 本身不保證名稱唯一 → 重名即解析歧義，一律 Stage 1 拒收。 材質宣告優先序：node-level extras material（entity §9.2 / bullet §3.7.3）為該 node 的權威宣告；同一 node 同時出現在 root materials[] → Stage 3 拒收（禁雙重宣告）。

3. 各 Part type 專屬欄位¶

3.1 chassis 專屬¶

name	field	desc	required	auto	edit
底盤 Mount 結構	`auto_chassis_mounts`	4 類 mount 表：tire / roller / body / single	✅	Stage 2 自動產生（自訂位置 mount 帶玩家拖放結果）	✏️ 9 個自訂位置 mount 可拖放；9 個 canonical 固定 mount 不可改位置

3.2 motor 專屬¶

name	field	desc	required	auto	edit
扭力比例	`torque_ratio`	0–100%，玩家宣告扭力 vs 速度分配	✅ 必填	❌	✏️ Stage 2
輸入功率上限	`auto_input_mw`	`= round(volume_m3 × K_MOTOR_INPUT_W_M3 × 1000)`（整數 mW）	✅（volume 必算得出）	✅ Stage 2	🔒

3.3 battery 專屬¶

name	field	desc	required	auto	edit
輸出功率	`configured_output_w`	玩家宣告 ≤ `volume_m3 × K_BATTERY_OUTPUT_W_M3`（K 預估 80,000,000 W/m³）	✅ 必填	❌	✏️ Stage 2
總電量	`auto_energy_capacity_mj`	`= round(volume_m3 × K_BATTERY_ENERGY_MJ_M3)`（整數 mJ；初始 90 GJ/m³）	✅（volume 必算得出）	✅ Stage 2	🔒

〔PART-R-001〕 Battery 的 configured_output_w 必須大於 0，且不得超過實際 canonical 幾何 volume_m3 × K_BATTERY_OUTPUT_W_M3；canonical finalizer、首次 ledger admission 重建與 runtime typed manifest boundary 都必須 fail-closed 執行同一限制。

3.4 tire 專屬¶

name	field	desc	required	auto	edit
Hinge 標記	`auto_hinge`	標記需要 hinge constraint（對應 chassis mount 軸）；tire 恆轉動，必為 true	✅（tire 必轉動）	✅ Stage 2	🔒

3.5 roller 專屬¶

name	field	desc	required	auto	edit
Hinge 標記	`auto_hinge`	同 tire；roller 恆轉動，必為 true	✅（roller 必轉動）	✅ Stage 2	🔒

3.6 晶片（chip）專屬¶

name	field	desc	required	auto	edit
Skill slot 數	(隱含)	由 `volume_m3` 算 1–4 個（玩家不可宣告）；階梯門檻 `CHIP_SLOT_VOLUME_THRESHOLDS_M3` = [0.0000015, 0.000003, 0.000006] m³（等同 [1.5, 3, 6] cm³）：依序升為 2／3／4 槽（初估，protocol.md §3）	—	✅ Stage 2	🔒
Skill 槽位	`skill_slots[]`	`[{ skill, allocation_pct }]`，長度 ≤ auto slot 數;skill 內容禁重複;總 allocation_pct ≤ 100%;`allocation_pct` 物理意義 = 該 skill 分配到 SOC 降額後的 `battery.available_output_w` 比例(影響技能 / 武器強度,見算式表.md §3 / §5)	✅ 必填	❌	✏️ Stage 2;上鏈後全部 immutable（skill + allocation_pct 皆鎖死）

Skill enum（8 種）：boost / brake / swerve_left / swerve_right / jump / slam / stabilize / weapon。詳見遊戲機制.md §1 晶片技能。

〔PHYS-R-001〕 每個 allocation_pct 必須為 1–100 整數，同一 chip 全槽總和不得超過 100； canonical finalizer、首次 ledger admission 與 runtime typed manifest boundary 都必須拒絕超配，且 runtime 計算必須除以 100、不得按實際總和重新正規化。

3.7 weapon 專屬¶

name	field	desc	required	auto	edit
被動標記	`passive`	`true` = 純物理被動（常駐生效、不主動觸發，仍占一個 chip `weapon` 槽）、`false` = active（由 chip `weapon` 槽觸發）	✅ 必填	❌	✏️ Stage 2
機制類型	`weapon_mechanism`	`general / magnet / launch`	active 必填	❌	✏️ Stage 2
主物件 mesh node	`weapon_main_mesh_node`	依 weapon_mechanism 解釋：general = 不轉本體 / 基座（actuator pivot 掛其上；如螺旋槳的中心 hub）；magnet = 磁場原點；launch = launcher_body	active 必填	❌	✏️ Stage 2 下拉選 GLB 內 node
驅動單元	`weapon_actuators[]`	`general` 機制的多個獨立驅動 pivot（每項 = 一個剛體轉子或一條鏈條基座；schema 見下）；空 / 不填 = `general_push`（純直線推、無旋轉）	`weapon_mechanism: general` + 有驅動動作時必填	❌	✏️ Stage 2

weapon_mechanism: general 兩型態（由 weapon_actuators[] 有無衍生）：

有 actuator：general_actuated（揮擊 / 連旋 / 多臂 / 鏈條）—— 每項 actuator 是一個繞自身 pivot_node 的驅動單元，可剛體可鏈、彼此獨立運動、共用一個 chip weapon 觸發。

無 actuator：general_push（直線推 / 戳）—— 無旋轉 / 無自運動 mesh / 無角度 / 速度參數；觸發（Hold）時沿 Axis +Z 對接觸中的目標施加前推衝量（力度 ∝ applied_energy、由 allocation_pct 決定），chassis 同步反向反衝（見算式表.md §4）。

weapon_actuators[] 每項 schema（payload mesh_node 與 chain 二選一）：

子欄位說明

pivot_node 該驅動單元旋轉軸心 empty（名唯一）

rotation_axis pivot local 旋轉軸（normalize、§9.2 慣例）

weapon_max_angle_deg 1–360：360 = 連旋 / < 360 = 揮擊

speed_weight 預設 1；正規化權重 → 各 actuator 分配共用功率（不設 = 均分 1/N；轉速式見算式表.md §3）

phase_offset_deg 預設 0；相位偏移角度 0–360（360 = 一個完整運動週期：連旋 = 起始轉角、揮擊 = 揮動週期內相位）；定義為角度故與功率脫鉤、多 actuator 相對相位恆定（不隨 ω 浮動），純做錯開

motion_curve < 360 揮動曲線 sin / linear（無 step）

mesh_node（payload A） 剛體轉子：繞 pivot 剛性旋轉的 mesh

chain（payload B）鏈條：掛在 pivot 的 Chain_Segment_* 節點名稱歸屬清單（鏈序由 GLB children 順序定、非此陣列順序，見 §3.7.2 / §5.3）；基座旋轉甩動、尾段物理 joint 擺動。清單所有項目須屬同一條實體鏈（auto_chain 一 actuator 一串、跨鏈無法表示）且須為已成鏈節段（同父 Chain_Segment_* 兄弟群成員——root 裸放掃不成鏈）；跨鏈或未成鏈 = Stage 3 拒收

驅動單元數 ≤ MAX_WEAPON_DRIVEN_PIVOTS（8）；全武器剛體轉子 + 鏈段總數 ≤ MAX_WEAPON_DRIVEN_BODIES（16）（protocol.md §3、body 預算帳 §2）。

特例：1 個 mesh_node actuator 表示單一轉動體；1 個 chain actuator 表示單一鏈條。

Axis / Pivot 們透過 empty node 宣告（非 GLB extras），見 §5.2。

武器 magnet = 僅 active（與「材質型磁源」是兩套獨立系統、不混用）：

active magnet 武器（weapon_mechanism: magnet）：強度動態 = battery.available_output_w × allocation_pct / 100（見材質表.md §8.2、算式表.md §5），N 極 = Axis +Z；不使用 magnet_source_strength_n。

無「passive magnet 武器」：passive 武器一律純物理被動（靠形狀 / 材質的碰撞動能，見零件與場景.md §9），不是磁鐵、不帶 magnetism_role: source 材質。

材質型磁源（source 材質 + magnet_source_strength_n、N 極 = sub-mesh 面積加權平均法向〔材質表 §8.3〕）是另一套系統、正常僅用於場地 entity / 地板（見 §9.4 / 材質表.md §8.2）；車輛部件（含 passive 武器）正常無 source 材質，異常出現即設定錯誤、僅 fallback 防護（材質表 §8.2）。

passive 武器仍占 chip weapon 槽且需填 allocation_pct：runtime 不消耗電池能量（被動物理由形狀 / 材質決定），此值＝ 被動武器加持的外層總量，計入 §3.6「總 allocation_pct ≤ 100%」預算（加持強度與技能能量競爭同一預算）；效果公式與組裝層分配見算式表.md §3・車輛組裝.md §3.5。

3.7.1 武器最終方向 = Mount transform 對接¶

武器裝到車上的最終位置 / 朝向由兩個 Mount_Weapon empty 的 transform 對接決定，組裝階段玩家不調整任何方向參數（組裝層完全 deterministic、無自由旋轉方向參數）：

來源	由誰決定	內容
chassis 端 `Mount_Weapon` empty transform	chassis 創作者（Stage 2 拖放）	接點位置 + 接點朝向
weapon 端 `Mount_Weapon` empty transform	weapon 創作者（Stage 2 拖放）	武器自身的安裝對齊方向

範例：

情況 A：chassis Mount_Weapon 朝上 + weapon Mount_Weapon 朝下：兩接點反向貼合（如插頭插座），武器姿態固定；同顆武器裝在不同 chassis 接點位置 / 朝向自然適配（單一 Mount_Weapon、無鏡像參數）
情況 B：chassis Mount_Weapon 朝側邊 + weapon Mount_Weapon 朝側邊：兩側向接點對接，創作者建模時的 transform 已決定「向後揮」或「向前揮」其一

想要多種方向 = 武器創作者出多顆 GLB 變體（或 chassis 創作者出多種 chassis 變體）。runtime / 組裝層完全 deterministic、無自由旋轉角度參數。

3.7.2 Scene Graph 結構範例¶

weapon GLB（root）
├── Mount_Weapon (empty)          ← 與 chassis 對接
├── Axis (empty)                  ← +Z = 整體動作方向 / 反作用力基準
├── Pivot_1 (empty)               ← actuator 1 旋轉軸心
├── Pivot_2 (empty)               ← actuator 2 旋轉軸心（多臂時）
├── main_weapon_mesh (mesh)       ← weapon_main_mesh_node（不轉本體 / launcher）
│   └── (launch 子彈情境) bullet_1, bullet_2, ... (mesh, 子節點)
├── rotor_mesh_1 (mesh)           ← actuator[0].mesh_node（剛體轉子 payload）
└── (鏈條 payload，掛某 actuator 的 pivot)
    ├── Chain_Segment_1 (mesh)
    ├── Chain_Segment_2 (mesh)
    └── ... (全武器剛體轉子 + 鏈段總數 ≤ `MAX_WEAPON_DRIVEN_BODIES`（16，[protocol.md §3](../程式參數/protocol.md#3-protocolugcugc-規格約束)），convert 自動推 Revolute / Spherical joint)

general_actuated：每個 actuator 的 payload 繞其 pivot_node 旋轉到 weapon_max_angle_deg（剛體 payload = mesh 剛性轉；鏈條 payload = 基座轉 + 尾段 joint 甩）
launch：bullet sub-mesh 為 weapon_main_mesh_node 的子節點，發射順序 = 子節點 array 順序
鏈條 payload：鏈節須為同一父節點的兄弟節點，鏈序 = children 陣列相對順序（比照 bullet 先例；名稱僅需唯一，慣例 Chain_Segment_<n>）；joint 鏈錨定於該 actuator 的 pivot_node

3.7.3 Launch 武器子彈標記¶

每個 bullet sub-mesh 為 weapon_main_mesh_node 的子節點，子節點 extras：

name	field	desc	required	auto	edit
子彈材質	`material`	bullet 材質（可與 launcher 不同；落地行為由材質的 deploy_behavior 決定）	✅ 必填	❌	✏️ Stage 2

發射方向：所有 bullet 統一沿 Axis empty 的 +Z 軸飛行（見 §5.2）。子節點 transform 僅決定發射起點位置（多顆連發從不同點出），不影響飛行方向。

LaunchExit 幾何離膛：current PhysicsManifest 為每顆 projectile 保存 exitDistanceUm（source weapon local、從該 projectile 初始位置沿 Axis +Z 到出口平面；不保存 rotation）。Stage 3 以 launcher 的 canonical convex proxies 驗證完整 projectile outward sweep：正向、未任意超出必要最外界、不可受阻，抵達出口時全形狀須已在平面外；特殊、雙管、叉形、環形或開放造型皆逐 projectile 處理，不退回 AABB／橢圓／方形／圓形。 發射順序：= 子節點 array 順序。 bullet 數上限：≤ LAUNCH_AMMO_COUNT_MAX（8，protocol.md §3；body 預算帳見該檔 §2 註），超過 Stage 3 拒收。 彈藥消耗：彈藥有限——weapon 技能 Hold 期間每 LAUNCH_FIRE_INTERVAL_MS（250ms，protocol.md §7）依子節點序發射 1 顆，打完即空（一回合就這麼多、用完沒了）；下一回合換上新車 = 滿彈（每回合新車 + 新場地世界、非「回滿」流程，見算式表.md §11）。 落地後：fluid bullet 第一次接觸合法固定場地或 Track Entity 表面時，移除 bullet 物理並啟用同索引預配置圓形薄 sensor；純視覺 fragment 沒有 collider，不能成為接觸面；碰車不部署。面積由 clamp(volume_m3 / FLUID_PROJECTILE_SPREAD_THICKNESS_M × FLUID_PROJECTILE_SPREAD_COEFFICIENT, FLUID_PROJECTILE_AREA_MIN_M2, FLUID_PROJECTILE_AREA_MAX_M2) 推導，特殊外形只影響飛行接觸，不改用外觀投影。固定表面用 world anchor，移動 entity 用 local anchor 跟隨，entity 退役即移除；未部署而越過 fall-limit 者回收，其他 zone 存續至回合結束。固體 bullet → 永久留場成障礙物（Dynamic body，依其材質走 fatigue / 一擊重傷可被破壞，破壞後轉純視覺淡出、釋放 body）。全場 projectile ≤ 8 車 × LAUNCH_AMMO_COUNT_MAX = 64 顆、回合內打完即空（每車至多 8）→ 累積有界（飛行、落地與預配置 sensor 同一批索引，已計入 protocol.md §2 body 預算帳）。

4. GLB Root Extras — 系統自動算出欄位（auto_*）¶

Stage 2 與 Stage 3 由 convert script 計算嵌入 GLB extras；全部 auto = ✅、edit = 🔒。

required 慣例：幾何 / 質量類（auto_volume_m3 / auto_mass_g / auto_bbox_m / auto_aabb_min_m / auto_aabb_max_m / auto_centroid_m / auto_surface_area_m2 / auto_contact_area_m2）恆算得出 = ✅；auto_empties 與 auto_feature_deviations 亦恆寫入。auto_thermal_conductivity／auto_specific_heat／auto_thermal_limit 是可編輯衍生檔與 UI 的 authored cache，可能為 null；runtime 熱權威是 current PhysicsManifest 的 heatCapacityJPerC／ambientConductanceWPerC／thermalLimitC 與 per-proxy thermal 欄位，不讀這三個 auto_*。其餘可能缺席者 = ❌：auto_volume_estimated、auto_inferred。auto_fragments 於 Stage 3 對所有零件預烘焙 = ✅。

4.1 所有 part 共用¶

field	desc
`auto_volume_m3`	體積（watertight 合成；驗證失敗則跑 voxelization 備援路徑取近似值，並記入 `auto_volume_estimated: true`）
`auto_mass_g`	`volume × density`（多材質：Σ sub_volume × sub_density）
`auto_bbox_m`	AABB 尺寸 `[x, y, z]`（相容顯示與尺寸檢核；不得據此假設 local min 為原點）
`auto_aabb_min_m`	精確 part-local AABB 最小點 `[x, y, z]`；runtime collider 唯一位置來源之一
`auto_aabb_max_m`	精確 part-local AABB 最大點 `[x, y, z]`；各軸必須嚴格大於 `auto_aabb_min_m`
`auto_empties`	所有合法 Mount empty 的 `{ pos_m, rot }` 快取；runtime 與 viewport 共用，免 traverse GLB
`auto_centroid_m`	質心 [x, y, z]
`auto_surface_area_m2`	原始幾何總表面積（UI／authoring cache）；ambient 熱導另由 manifest bake 排除同 part 內被其他水密 region 完整包覆的三角面
`auto_contact_area_m2`	六向投影：`{ front, back, left, right, top, bottom }`（part local 軸對應：front = −Z / back = +Z / right = +X / left = −X / top = +Y / bottom = −Y，同 §5 速查）
`auto_thermal_conductivity`	多材質質量加權 authored cache；runtime 不讀取
`auto_specific_heat`	多材質質量加權 authored cache；runtime 不讀取
`auto_thermal_limit`	多材質 weakest non-null sub-mesh pre-bake 合成的過熱閾值（所有 sub-mesh thermal_limit 皆 null 時為 null）
`auto_fragments`	Stage 3 預烘焙版本化純視覺碎片：`{ version, count, method, total_volume_loss_pct, fragments[{fragment_index, seed_m, volume_m3}] }`；count ≤ `VORONOI_FRAGMENT_COUNT_MAX`（8，protocol.md §3）。canonical PhysicsManifest 必須保存完整穩定 descriptor，不能只留 count 摘要；runtime 不做即時幾何切割。零件 broken 後本體物理退出，碎片無 mass／collider／sensor／damage／magnet／checkpoint，並由 `vehicleId + partIndex + breakFrame + descriptor version` 重建呈現。
`auto_volume_estimated`	watertight 失敗時為 `true`，提示玩家 mesh 不封閉、體積為近似
`auto_feature_deviations`	canonical 介面偏差診斷陣列（見 §7.3）；結構 `[{ feature, interface_kind, unit, deviation, tolerance }]`。合格 canonical 成品必為 `[]`；超限量測只存在拒收 finding／診斷輸出，不得進入鏈上成品

4.2 body 專屬 aero¶

field	desc
`auto_aero.axes`	六個 signed cardinal 軸（`positiveX / negativeX / positiveY / negativeY / positiveZ / negativeZ`），每軸含 `drag_area_m2` 與 `center_of_pressure_m`；車頭 = −Z、高 = +Y，見 §5
`auto_aero.lift_factor`	負 = 升力傾向；正 = 下壓力傾向；runtime 公式與 force cap 見算式表.md §10.3

六軸投影面積與各向壓力中心的預烘焙演算法屬 convert script 實作層。runtime 只讀 current PhysicsManifest typed aero；raw auto_aero 是 authored cache，不是賽中權威。

4.2.1 共用 part collider proxies¶

current PhysicsManifest 對每個水密 mesh node 烘焙一個 deterministic convex proxy：依 source node index 排序，每 part 最多 PART_COLLIDER_PROXY_COUNT_MAX = 32，每 proxy 以固定 26 方向取得最多 PART_COLLIDER_PROXY_POINT_MAX = 26 個微米量化 support points，並保存材質、質量份額、centroid、量化 thermalExchangeFactor=sqrt(k×densityKgM3×specificHeat) 與由 proxy 最小兩軸投影烘焙的 thermalContactAreaM2，以及 collider-local front／back／left／right／top／bottom 六向投影 contactAreasM2。後者由衝撞接觸法線平滑加權；root auto_contact_area_m2 僅供 UI／authoring 摘要，runtime 不讀。tire proxy 另必帶有限正值 wearCapacityJ，由該 region 自身水密體積與材質 ultimate strength 派生；其他 part 禁帶此分支。輪轂若要使用不同材質／用途，必須是不同 region，不得把其體積併入胎面 wear capacity。各 proxy 質量總和必須等於 part auto_mass_g；runtime 禁止退回 AABB／公版外觀猜形。

4.3 weapon 專屬¶

field	desc
`auto_empties`	除共用 Mount 快取外，weapon 另包含 Axis / 各 Pivot empty 的 `{ pos_m, rot }`；convert 階段從 GLB scene graph 抓出寫入 extras
`auto_inferred`	Fallback 推斷標記（例：玩家未填 Axis empty 時用 mesh 主軸推斷，本欄位記錄「哪些 empty 是推斷的而非玩家設定」），UI 提示玩家可選擇補標
`auto_chain`	各 `chain` payload actuator 的 segment 自動推導：`[{ actuator_index, segment_count, joints: [{ from, to, type }] }]`（多鏈各一筆）
`auto_launch_ammo`	launch 子節點掃描結果：`[{ node_name, material, volume_m3, local_transform }]`；順序、名稱與材質須逐枚對上 `auto_weapon_physics.projectiles[]`
`auto_weapon_physics`	versioned Stage 3 執行期拓撲：`{ version: 1, descriptor_hash, axis, fixed_proxies[], actuators[], projectiles[] }`。wire 以整數 `mass_ug`、`centroid_um`、`points_um`、`pos_um`、`anchor_um` 保存微克／微米量化值，runtime 驗證後轉回 gram／meter；rotation 與 root-space axis 保留有限 float。每個 proxy 帶具名節點、正式材質、質量、centroid 與 ≤26 個 deterministic convex support points；actuator 帶 pivot pose、root-space axis、角度／權重／相位／曲線、payload 與 joints；projectile 帶 child index、pose 與各自 proxy。節點不可重複、hull 不可退化、質量須大於 0、proxy 質量總和須等於 `auto_mass_g`，且內容 hash、`weapon_actuators[]` 與 `auto_launch_ammo[]` 必須交叉一致。特殊角度／非標準比例／搞怪形狀合法；runtime 不得按 builtin 外觀猜軸或退回替代 box／sphere。凹形需由創作者拆成多個 mesh node（每 node 一 convex child）

4.4 chassis 專屬¶

auto_chassis_mounts 結構（chassis 創作者建模時拖放，Stage 2 系統解析）：

{
  "tire":    [Mount_Tire_FL/_FR/_RL/_RR × 4],           // canonical 固定位置
  "roller":  [Mount_Roller_FL/_FR/_CL/_CR/_RL/_RR × 6], // 自訂位置
  "body":    [Mount_Body_F/_RL/_RC/_RR × 4],            // canonical 固定位置
  "single":  [Mount_Battery, Mount_Motor, Mount_Chip, Mount_Weapon]  // 4 個（各一）
  //         canonical:Battery / 自訂:Motor、Chip、Weapon
}

每個 mount 帶 { name, pos, axis or rot }。

5. Empty Node 命名約定¶

軸向慣例速查：全域框架 = runtime GLB（Y-up）：高 = +Y（預設重力 [0,-1,0] 的反向）、車輛車頭 = −Z（同 RoutePoint 前向慣例；§4.2 aero 六軸與整車 AABB「長 / 寬 / 高 = Z / X / Y」皆據此，protocol.md §3）。Axis（武器動作 / launch 朝向 / active magnet N 極）用 +Z（Blender 單箭頭 empty 的指向軸）；RoutePoint / RespawnPoint forward 與 entity conveyor_velocity 方向用 −Z（Blender 物件前向慣例）；tire / roller 的 hinge（轉動）軸 = chassis 端 mount empty 的 +X（見 §6.4）。各為其用途最直覺的軸、刻意不統一；材質型（靜態）磁源 N 極另由 sub-mesh 面積加權平均法向決定（見 §9.4 / 材質表.md §8.3；passive 鐵磁無 N 極）。創作者在 Blender（Z-up）建模即可，glTF exporter 匯出自動轉 Y-up、無須自行換算。

鏡射禁令（Stage 3 拒收）：本章所有 Empty（Mount_* / Axis / Pivot* / RoutePoint_* / Checkpoint_* / KillZone_* / RespawnPoint_*）不得處於鏡射（負縮放、世界變換行列式 < 0）之下——鏡射無法以旋轉 / 四元數表示，auto_empties 的 rot 與上述全部軸向語意（+Z / −Z / +X）會靜默反向。左右對稱建模請在建模軟體 apply scale 後匯出；純 mesh 鏡射（含 Chain_Segment_* 等 mesh 節點）合法（幾何頂點照常變換）；雙軸鏡射 = 180° 旋轉（行列式 > 0）不在此限。

5.1 裝配點（`Mount_*`，PascalCase）¶

完整清單見 §6 Mount 表。

5.2 動作參考點（單字 PascalCase，無 `Mount_` 前綴）¶

Active 武器專用：

name	field	desc	required	auto	edit
方向向量	`Axis`	empty 的 +Z 軸 = 武器動作方向 / active magnet 武器的磁鐵 N 極 / launch 發射朝向（passive 磁鐵 N 極改由 sub-mesh 法向決定，見 §9.4）	active weapon 必填	Fallback 推斷 → mesh 主軸（標 `auto_inferred`）	✏️ Stage 2 玩家可重標
支點	`Pivot`（每 actuator 一個、名唯一如 `Pivot_1`）	各 `weapon_actuators[]` 項的旋轉軸心（§3.7）；無 actuator = `general_push`、不需 Pivot	每個有旋轉的 actuator 必填	❌	✏️ Stage 2

5.3 鏈條 / 鞭 / 雙節（獨立機制）¶

name	field	desc	required	auto	edit
鏈節	`Chain_Segment_<n>`	某 `weapon_actuators[]` 項的 `chain` payload；命名唯一（`<n>` 顯示慣例）；鏈序 = 同父節點 children 陣列相對順序（§3.7.2，比照 bullet、不由名稱後綴承載）；全武器剛體轉子 + 鏈段總數 ≤ `MAX_WEAPON_DRIVEN_BODIES`（16，見 protocol.md §3；body 預算帳）	❌（無鏈條的武器不需）	`auto_chain` 由 convert script 從 segment 自動推導 joint	✏️ Stage 2 玩家命名 / 排序

物理：convert script 自動建立相鄰 segment 的 RevoluteJoint（單軸轉動）或 SphericalJoint（三軸轉動）；型別推導規則屬 convert script 實作層，結果烘焙進 auto_chain、各 peer 讀同一份（不影響 determinism，比照 §4.2 aero 演算法）。joint 鏈錨定於所屬 actuator 的 pivot_node（§3.7）。

5.4 場地專用 Empty（PascalCase）¶

命名與順序分離：場地 Empty 名稱僅需全 GLB 唯一（§2）、<n> 後綴為編輯器顯示慣例；順序語義一律由 extras 陣列承載——route 順序 = track.route[]、checkpoint 通過順序 = track.checkpoints[]（§8.1），不由名稱後綴決定；KillZone / RespawnPoint 無順序語義。Stage 3 檢核陣列 ↔ empty 1:1（entry 無對應同名 empty、或 RoutePoint_ / Checkpoint_（含底線）前綴 empty 未列入對應陣列 = 孤兒 → 皆拒收）。

Empty 名稱	角色	scale 用途
`RoutePoint_<n>`	跑道有序點（open / fixed 共用）：RP1 = 起點、RPn = 終點；每點 position 貼 mesh 表面（±0.005m，`ROUTEPOINT_SURFACE_TOLERANCE_M`，Stage 3 檢核），自訂 forward 切線（在該點 surface 切線平面內、1 DOF 繞 normal）；route 為依各點 (position, forward) 插值的 Hermite spline	scale 不使用；rotation 用來表達 forward（empty -Z 軸慣例，up 取 surface normal 自動）；寬度寫 GLB extras `track.route[]`
`Checkpoint_<n>`	有序防抄近路關卡（可選；放了即強制依序通過，通過順序 = `track.checkpoints[]` 陣列（§8.1），見下方通過判定）	scale = trigger box 大小（min 0.1×0.1×1 m、max 場地 AABB 各軸 1/10；`TRACK_CHECKPOINT_TRIGGER_MIN_M` / `TRACK_CHECKPOINT_TRIGGER_MAX_AABB_RATIO`，見 protocol.md §3）；位置 + scale 必須完全在場地 AABB 內（Stage 3 嚴格檢核，同 KillZone——AABB 外的 Checkpoint 永遠無法點亮 → 全場無法完賽）
`KillZone_<n>`	死亡區 box trigger（chassis COM 掃掠進入時觸發掉出場地處理）	box scale = 死亡範圍；位置 + scale 必須完全在場地 AABB 內（Stage 3 嚴格檢核）
`RespawnPoint_<n>`	自定義 fade in 回位點	scale 不使用；empty 的完整 rotation 是回位 surface frame：−Z 軸（Blender 前向慣例，同 RoutePoint）= 車頭 forward、+Y 軸 = 車體 up；Editor 貼面新增時以命中面 normal 初始化 +Y，特殊場地可明確調整完整姿態；位置必須在場地 AABB 內

通過判定：

RP1（起點）：比賽開始時車輛初始位置
Checkpoint：有序防抄近路關卡。每個 fixed step 以 chassis 組合體質心 previous→current 線段（車輛位置基準，同算式表.md §4 反作用力基準點）對 trigger AABB 做 entry sweep；線段進入即「點亮」，但必須依 track.checkpoints[] 陣列順序（HUD 序號 = 陣列 index + 1）。跳序通過不算（須回頭補點）；teleport 會同步重設 previous COM，不產生 sweep 或觸發。已點亮狀態跨終點線（RPn）保留、不自動重置；HUD / mini-map 顯示點亮進度
KillZone：同樣以 chassis COM previous→current 線段對 box AABB 做 entry sweep；進入即觸發掉出場地處理。teleport 重設 previous COM，因此不會跨越 KillZone 誤觸發
RPn（終點）：以 RPn.position 為 origin、normalized RPn.forward 為 normal、RPn surface frame 的 right 為橫向軸，形成無高度上限的定向平面。每個 fixed step 以 chassis 組合體質心 previous→current 線段判定；須先離開起始容差帶並位於平面後方，再由負側掃掠至正側，且交點橫向距離不超過 width_m / 2 + FINISH_GATE_LATERAL_EPS_M，才是正向通過。正向由 displacement 證明，不讀步末速度；反向、側邊進入、共面移動與 teleport 均不算。另須全部 Checkpoint 已點亮才有效：
loop：有效通過 → 計 1 圈 + 重置所有 Checkpoint（進下一圈）；未全亮的正向通過 不計圈、不清除已點亮（可下次續補，例：已亮序號 1–18 → 下次直接從 19 續點）
linear / open：有效通過 → 完賽；未全亮 → 不算完賽（可回頭補點再通過一次）
無 Checkpoint 的場地：正向通過即有效（loop 計圈 / linear 完賽）
checkpoint 之間路徑不限：fixed 受 route 偏離（b-soft）軟約束、open 可走最短直線；兩者都須依序通過所有 Checkpoint

賽程時間上限（房間設定，預設 600s）擋住「卡關 / 不點關無限拖」：達上限強制依當前名次結算（見賽內機制.md §1.5）。

玩家上限自動推導：

玩家上限 = floor(RP1.width_m / START_GRID_CELL_WIDTH_M) clamp 至 `TRACK_MAX_PLAYERS_HARDCAP`（8）

寬度來源：RP1.width_m（open / fixed 共用，§8.2）。0.13 = 車輛 AABB 強制最大寬度（§7.1）、0.05 = safety margin（START_GRID_SAFETY_MARGIN_M，見 protocol.md §3）。起跑 cell width 固定 0.18m，N 車需求寬度為 N × 0.18m；slot 沿 RP1 right 同縱向左右置中，offset 為 (slot-(N-1)/2)×0.18m。8 玩家滿員需寬度 ≥ 1.44m。（Tamiya 0.105m 為軟性外形建議，起跑間距採 AABB 強制上限以容納最寬合法車。）

6. Mount 結構表（chassis × part 配對）¶

部件	必要性	Chassis 端 mount 數	Chassis 端命名	Chassis 端位置	Part 端命名	Part 端 mount 數
body	必須	4	`Mount_Body_F` / `_RL` / `_RC` / `_RR`	canonical 固定	同 4 個（嚴格相符）	4
battery	必須	1	`Mount_Battery`	canonical 固定	`Mount_Battery`	1
tire	必須	4	`Mount_Tire_FL` / `_FR` / `_RL` / `_RR`	canonical 固定	`Mount_Tire`（通用，前綴匹配 4 位置）	1
motor	必須	1	`Mount_Motor`	自訂	`Mount_Motor`	1
晶片	可選	1	`Mount_Chip`	自訂	`Mount_Chip`	1
roller	可選	6	`Mount_Roller_FL` / `_FR` / `_CL` / `_CR` / `_RL` / `_RR`	自訂	`Mount_Roller`（通用，前綴匹配 6 位置）	1
weapon	可選	1	`Mount_Weapon`	自訂	`Mount_Weapon`	1

6.1 Chassis Mount 編輯權限¶

未標記 chassis 首次匯入時，以縮放後 world AABB 的水平中心與底面為 anchor，自動建立完整 18 個 mount。canonical 9 個會校正至 96mm 軸距模板並鎖定；custom 9 個若來源已有唯一同名節點則保留 transform，只補缺少者。重複同名一律拒絕。current canonical 重開／fork 不重套模板。

類別	自動產生	可編輯位置
chassis canonical 固定（Body × 4 / Battery / Tire × 4 = 9 個）	✅ Stage 2 依 type 自動放 canonical 位置	❌ 不可改
chassis 自訂位置（Motor / Chip / Roller × 6 / Weapon = 9 個）	✅ Stage 2 自動加標準命名 mount	✏️ Stage 2 玩家拖放

6.2 Part-side Mount 編輯權限¶

未標記非 chassis part 也必須自動建立表列 mount：body 使用與 chassis 相同四個 canonical world offset；battery / tire / motor / chip / roller / weapon 預設位於模型 world AABB 中心，tire / roller local +X 為轉軸。除 weapon 外均鎖定；current canonical 重開不重建。

類別	自動產生	可編輯位置
一般 part-side mount（body / tire / motor / battery / roller / chip）	✅ Stage 2 依 part type 自動放標準位置	❌ 不可改
weapon part-side `Mount_Weapon`	✅ Stage 2 自動加	✏️ Stage 2 玩家可拖放（武器外觀無法預知）

6.3 配對演算法（嚴格相符 + 前綴匹配）¶

function isMountCompatible(partMountName, chassisSlotName) {
  // 規則 1：嚴格相符（body / battery / motor / chip / weapon）
  if (partMountName === chassisSlotName) return true;
  // 規則 2：前綴匹配（tire / roller — part 用通用名，chassis 用具體位置名）
  if (chassisSlotName.startsWith(partMountName + "_")) return true;
  return false;
}

範例：part Mount_Tire 可裝到 chassis Mount_Tire_FL、Mount_Tire_FR...。

6.4 Mount 位置 / 軸向檢核¶

部件	拒收 🟥	軟警告 🟨
tire / roller mount 軸向（hinge）	`HINGE_AXIS_REJECT_SIN` 守門	`HINGE_AXIS_WARN_SIN` 至 reject 門檻
其他部件（motor / chip / weapon / body / battery）	不檢核軸向（物理計算固定，與角度無關）	—
Mount 在 chassis AABB 內	`MOUNT_AABB_REJECT_M` 守門	warn 至 reject 門檻
Mount 之間距離	`MOUNT_GAP_REJECT_M` 守門	reject 至 warn 門檻

「水平面」定義：= chassis local X-Z 平面（地面接觸面慣例，與 chassis 的 +Y up 對齊）。檢核 hinge 軸（empty +X 慣例）與此平面的夾角，不受場地重力方向影響（重力屬 runtime、建模屬車輛 local frame）。 hinge 軸來源：Mount 是帶完整 transform（pos + rotation）的 Empty，非單純的點。tire / roller 的 hinge（轉動）軸 = chassis 端對應 mount empty 的指定 local 軸（慣例 +X，auto_hinge 對應之）。tire mount 為 canonical 固定 → 軸由 chassis 模板預設、創作者無須也無法調（檢核對 tire 恆過）；roller mount 為自訂 → 創作者 Stage 2 拖放時連同朝向設定，此軸即 hinge 軸（夾角檢核實際只對 roller 有意義）。全部 mount／hinge 門檻值只由 protocol.md §3 的具名常數定義。 UGC 幾何邊界：part-side Mount 的完整旋轉參與 chassisMount × inverse(partMount) attachment；runtime 不會從 AABB 最短軸、mesh 外觀或公版原始姿態反推 hinge 軸。故零件本身可使用任意複合旋轉（例如同時帶 X／Z 旋轉）與刻意不對稱、特殊造型，只要 Mount frame 與既有安全／尺寸規則合法即不得因「不像標準輪胎」被拒收。

7. 約束限制（Stage 1 + Stage 3 嚴格檢核）¶

本節列整車層（§7.1）與場地層（§7.2）約束；零件層 canonical meter/world 幾何限制（PART_AABB_MIN/MAX_M、PART_VERTEX_COUNT_MAX / PART_TRIANGLE_COUNT_MAX、退化三角形閾值等）見 protocol.md §3。

7.1 整車約束¶

約束	值
整車總質量	50–500 g
整車 AABB	250 × 130 × 100 mm（長 Z × 寬 X × 高 Y，`VEHICLE_AABB_MAX_M`，軸向見 §5 速查）
整車最重 / 最輕零件質量比	≤ 300:1（`VEHICLE_PART_MASS_RATIO_MAX`）
Tire 數量	必須 4 個（不開放放寬）

註：此為整車層「零件質量比」（VEHICLE_PART_MASS_RATIO_MAX，loadout 檢核）；另有零件層「單一零件內多材質密度比」（PART_MATERIAL_DENSITY_RATIO_MAX，part-upload 檢核，見 protocol.md §3），兩者是不同約束。總質量與零件質量比皆以被動武器加持後的有效質量計算；與車輛組裝.md §3.5 同一次求和。Tamiya envelope 是軟性建議，不屬拒收條件。

7.2 場地約束¶

約束	值
場地 AABB	≤ 500 × 500 × 100 m（`TRACK_AABB_MAX_M`）
GLB 檔案大小	≤ 80 MiB（`TRACK_GLB_SIZE_MAX_MB`；強制 Draco 幾何 + KTX2 紋理壓縮，未壓縮拒收）
Visual 三角形	≤ 3,000,000（`TRACK_VISUAL_TRIANGLE_COUNT_MAX`）
Collider 三角形	≤ 500,000（`TRACK_COLLIDER_TRIANGLE_COUNT_MAX`）
Solid material regions	≤ 256（`TRACK_COLLIDER_REGION_COUNT_MAX`；依 material ID、source node index 穩定排序，每 region 一 collider）
主場地貼圖	≤ 16×1024 或 ≤ 4×4K（擇一；`TRACK_TEXTURE_BUDGET_1K_MAX` / `TRACK_TEXTURE_BUDGET_4K_MAX`）
總 entity 個數	≤ 100（`TRACK_ENTITY_COUNT_MAX`）
Destructible entity	≤ 50（進 savestate 上限；`TRACK_DESTRUCTIBLE_ENTITY_COUNT_MAX`）
天氣 patch 數量	≤ 50（`WEATHER_PATCH_COUNT_MAX`）
玩家上限	由 `RP1.width_m` 自動推導；`PLAYERS_PER_RACE_MIN`（2）≤ auto_player_max ≤ `TRACK_MAX_PLAYERS_HARDCAP`（8）（下限不足 = 永遠開不了房、Stage 3 拒收）
視覺密度	< 5 tri/m² 軟警告（不阻擋）

詳見 protocol.md §3。

7.3 Canonical 介面絕對公差（介面嚴、外形寬）¶

相容性只檢查會直接影響裝配或關節求解的 canonical 介面特徵。chassis canonical mount 仍是單一 96mm 軸距模板的 9 個固定位置（§6.1）；沒有「標準／寬軌／短軸距」等 chassis 類型分支。模板完整 18 個 mount offset 的機器權威是 CHASSIS_MOUNT_TEMPLATES（protocol.md §3）；量測表按 feature 明列 interface_kind、單位、期望值與絕對公差，不得從零件比例推導百分比門檻。

`interface_kind`	單位	適用介面量測	超出公差
`mount-center`	m	配對 mount 中心／固定 offset	Stage 3 拒收
`hinge-axis`	m	hinge 軸線相對配合位置	Stage 3 拒收
`hinge-radius`	m	軸孔／轉軸等真正旋轉配合半徑	Stage 3 拒收
`hinge-width`	m	hinge 配合寬度	Stage 3 拒收
`mating-normal`	degree	配合面法向角度	Stage 3 拒收

expected 與 tolerance 是逐 feature authored/canonical PhysicsManifest 欄位，不是依 part type 套一組隱藏全域數值；finalizer 量測 actual 並將合格結果封入 manifest，admission 重建後核對。tolerance 必須是有限正值；位置／半徑／寬度使用公尺，法向使用 degree。未知 kind、單位不符、NaN／Infinity 或非正公差一律以 interface-measurement-invalid 拒收；合法量測採 abs(actual - expected) <= tolerance。超限 finding 使用 interface-deviation-exceed，並帶 feature、deviation、limit 與 unit。Mount 與 hinge 的結構性安全門檻另由 §6.4 及 protocol.md §3 的具名常數治理，不與逐 feature 配合公差混為一談。

外形自由邊界：輪胎外徑、馬達總長、滾輪外徑、零件 AABB、外殼比例與純視覺輪廓均不得放入此量測 API，也不得因偏離公版半成品而拒收。公版尺寸只提供視覺／平衡起始值；真正相容性由 Mount frame 與上表介面決定。任何 schema-valid UGC 的極端但合法幾何，應由 runtime 的穩定積分、有限值檢查、clamp 與資源預算承擔，不以任意外形比例限制代替數值穩定性。

子欄位	說明
`pivot_node`	該驅動單元旋轉軸心 empty（名唯一）
`rotation_axis`	pivot local 旋轉軸（normalize、§9.2 慣例）
`weapon_max_angle_deg`	1–360：360 = 連旋 / < 360 = 揮擊
`speed_weight`	預設 1；正規化權重 → 各 actuator 分配共用功率（不設 = 均分 `1/N`；轉速式見算式表.md §3）
`phase_offset_deg`	預設 0；相位偏移角度 0–360（360 = 一個完整運動週期：連旋 = 起始轉角、揮擊 = 揮動週期內相位）；定義為角度故與功率脫鉤、多 actuator 相對相位恆定（不隨 ω 浮動），純做錯開
`motion_curve`	< 360 揮動曲線 `sin` / `linear`（無 `step`）
`mesh_node`（payload A）	剛體轉子：繞 pivot 剛性旋轉的 mesh
`chain`（payload B）	鏈條：掛在 pivot 的 `Chain_Segment_` 節點名稱歸屬清單（鏈序由 GLB children 順序定、非此陣列順序，見 §3.7.2 / §5.3）；基座旋轉甩動、尾段物理 joint 擺動。清單所有項目須屬同一條實體鏈（`auto_chain` 一 actuator 一串、跨鏈無法表示）且須為已成鏈節段（同父 `Chain_Segment_` 兄弟群成員——root 裸放掃不成鏈）；跨鏈或未成鏈 = Stage 3 拒收