虛擬人核心技術流派與商業落地評估表

DINet 原始論文在哪裡？ (arXiv)
DINet 是一系列高畫質局部變形修復技術的核心。該論文被 AAAI 2023 頂會接收，您可以在 arXiv 上找到它：

• 論文標題：DINet: Deformation Inpainting Network for Realistic Face Visually Dubbing on High Resolution Video
• 作者群：Zhimeng Zhang, Z Hu, W Deng, C Fan, T Lv, Y Ding
• 發表年份：2023 年
• arXiv 連結：https://arxiv.org/abs/2303.03988
• PDF 直接下載連結：https://arxiv.org/pdf/2303.03988.pdf

虛擬人核心技術架構解析 (Wav2Lip / 3DMM / NeRF / DINet / Wav2lip)

1. Wav2Lip 架構 (端到端 2D 卷積生成)

Wav2Lip 是最經典的「暴力美學」，不搞 3D 建模，直接用神經網路硬算像素。它的核心是一個生成對抗網路 (GAN) 加上一個專門抓「有沒有對準節拍」的判別器 (Sync-Expert)。

點評：非常快、泛用性極高，但因為是 2D 像素硬貼，缺乏立體空間概念，常常出現「馬賽克嘴」或牙齒細節消失的問題。

【音訊輸入】 ───> [ 1. 語音編碼器 (Audio Encoder) ] ─────> 語音特徵向量
                                                                 │
【影片輸入】 ───> [ 2. 臉部編碼器 (Face Encoder)  ] ─────> 臉部特徵 (會預先遮蔽下半臉)
                                                                 │
                                                                 ▼ (特徵拼接 Concatenate)
                                                          [ 3. 卷積解碼器 (CNN Decoder) ]
                                                                 │
                                                                 ▼
                                                          生成包含新嘴型的「下半臉影像」
                                                                 │
【原始背景/上半臉】───────────────────────────────────────────────┼──> (影像縫合 Blending)
                                                                 ▼
【最終輸出】 <───────────────────────────────────────── 即時對嘴的 2D 畫面 (但牙齒/邊緣較糊)

2. 3DMM 架構 (以 SadTalker 為例：單圖驅動)

3DMM (3D Morphable Model) 派系的強項在於「只用一張靜態照片」，就能讓它開口說話，甚至連頭都會自然擺動。它靠的是提取人類臉部的通用 3D 係數來驅動。

【音訊輸入】 ───> [ 1. 語音驅動網路 (Audio2Exp/Pose) ] ──> 預測 3D 表情係數 與 頭部姿態係數
                                                                 │
【單張照片】 ───> [ 2. 3D 面部重建 (3DMM Extraction) ] ──> 提取臉部形狀 (Shape) 與身分特徵
                                                                 │
                                                                 ▼ (係數結合)
                                                          [ 3. 3D 變形與映射 (3D Deformation) ]
                                                                 │
                                                                 ▼
                                                          生成 3D 臉部特徵映射圖 (Feature Map)
                                                                 │
【原始圖片】 ────────────────────────────────────────────────────┼──> (深度生成渲染)
                                                                 ▼
                                                          [ 4. 面部渲染網路 (Face Render/GAN) ]
                                                                 │
                                                                 ▼
【最終輸出】 <───────────────────────────────────────── 帶有頭部自然擺動與對嘴的 2D 影片

3. NeRF 架構 (神經輻射場：影視級 3D 孿生)

NeRF (如 AD-NeRF、RAD-NeRF) 是近年最火紅的技術。它連傳統的「臉部網格 (Mesh)」都不用，而是把空間切成無數個點，用神經網路去記住每一個點在不同視角下的光影與顏色。

【音訊輸入】 ───> [ 1. 語音特徵擷取 (DeepSpeech/HuBERT) ] ─> 音訊特徵向量 (Audio Features)
                                                                     │
【相機/頭部姿態】─> [ 2. 空間射線採樣 (Ray Sampling) ] ────────> 3D 空間座標與視角 (x, y, z, θ, φ)
                                                                     │
                                                                     ▼ (輸入 MLP 網路)
                                                              [ 3. NeRF 隱式神經網路 (MLP) ]
                                                                     │
                                                                     ▼
                                                              預測空間中每一點的「顏色(RGB)」與「密度(σ)」
                                                                     │
                                                                     ▼
                                                              [ 4. 體積渲染 (Volume Rendering) ]
                                                                     │
                                                                     ▼
【最終輸出】 <─────────────────────────────────────────────── 具備真實 3D 光影的相片級畫面

DH_live 的核心並不是一個像 React、Django 或 TensorFlow 那種提供底層基礎設施的通用型「框架 (Framework)」，它更適合被定義為一個**「高度客製化的演算法管線 (Algorithm Pipeline)」或「複合型整合系統」**。

它利用 PyTorch 作為其底層的深度學習運算框架，並將提到的「四種技術模組」像工廠流水線一樣串聯起來，各司其職。

1. 音訊特徵轉換 (Audio to Blendshapes)

系統並不直接將音訊轉為 2D 圖像，而是透過中間層（3D 參數）來進行對應：

• 核心技術：基於 LSTM (長短期記憶神經網路) 的聲學模型。
• 運作機制：透過 kaldi_native_fbank 提取語音特徵（Fbank），接著將特徵輸入至預先訓練好的 LSTM 模型（程式碼中的 lstm_model_epoch_325.pkl），將聲音頻率與特點精準映射到 3D 臉部的 Blendshapes（表情基底模型）。

2. 核心對嘴與影像生成 (DINet 輕量化神經網路)

針對「如何把計算好的嘴型自然地貼合回影片」，該專案採用了 DINet (Deformation Inpainting Network) 的深度學習架構：

• 核心技術：DINet_mini（專案針對邊緣設備最佳化的版本）。
• 運作機制：傳統的 DINet 擅長透過空間與時間的變形修復來進行高畫質的「換嘴」與「對嘴」。在此專案中，系統會將由音訊驅動生成的 3D 嘴部結構圖，連同使用者的原始臉部特徵向量一起送入 DINet_mini 模型（epoch_40.pth）。該神經網路負責把 3D 的幾何變形轉化為逼真的 2D 像素，確保嘴唇邊緣、牙齒以及口腔內部與原影片自然融合。

3. 臉部捕捉與 3D 網格 (Face Tracking & 3D Mesh)

為了讓假嘴巴能夠完全貼合使用者的頭部姿態：

• 核心技術：Google 的 MediaPipe (mp.solutions.face_mesh)。
• 運作機制：在影片前處理階段，使用 MediaPipe 提取臉部的 478 個 3D 關鍵點（Landmarks）。這使得演算法能夠準確定位嘴巴的邊界、頭部的旋轉角度，確保對嘴時不會發生嘴巴飄移的情形。

4. 3D 空間渲染 (OpenGL 結合神經網路)

• 核心技術：PyOpenGL 與 pyglm。
• 運作機制：在產生最終畫面之前，系統會先在 3D 空間中建構臉部（透過 .obj 模型），再把由 LSTM 算出的嘴型參數（Blendshapes）套用到 3D 網格上進行渲染。渲染出來的輪廓張量（GL Tensor）最後才會交給前面的 DINet_mini 去填補成真實的皮膚質感。

總結

DH_live 的對嘴技術捨棄了龐大且耗算力的生成式擴散模型 (Diffusion Models) 或是重型的 3D 建模，而是採用了 「語音轉 3D 表情參數 (LSTM) ➜ 3D 網格驅動渲染 (OpenGL/MediaPipe) ➜ 輕量級神經網路影像修復 (DINet_mini)」 的混合式架構。

這種作法將逐幀（Per-frame）的推理算力壓低至極致（僅需 39 Mflops），這也是為什麼它號稱能在任何無 GPU 的手機網頁端即時流暢運行的關鍵原因。

以下是這四種技術如何在這個管線中協同運作的拆解：

4. DINet 運作流程圖

您可以把這個系統想像成兩條進料線（聲音、影像），在中間交匯後，輸出最終成品：

【音訊輸入】 ───> [ 1. LSTM 聲學模型 ] ───> 產生 3D 嘴型參數 (Blendshapes)
                                                 │
【影片輸入】 ───> [ 2. MediaPipe ] ───────> 擷取臉部 3D 姿態與關鍵點
                                                 │
                                                 ▼ (參數結合)
                                          [ 3. OpenGL 渲染引擎 ]
                                                 │
                                                 ▼
                                          產生 3D 嘴部輪廓引導圖 (GL Tensor)
                                                 │
【原始臉部特徵】 ─────────────────────────────────┼──> (融合)
                                                 ▼
                                          [ 4. DINet_mini 生成網路 ]
                                                 │
                                                 ▼
【最終輸出】 <─────────────────────────────── 即時對嘴的 2D 真人畫面

在這個管線中，每個技術都扮演不可或缺的「零件」：

• 零件 A (特徵提取)：MediaPipe
  作用：負責「看」。它是一個純電腦視覺工具，用來在第一時間鎖定使用者的頭部位置、旋轉角度，告訴系統「臉在哪裡」。
• 零件 B (大腦翻譯)：LSTM 模型
  作用：負責「聽」。它是基於 PyTorch 訓練出來的小型神經網路，專門把聲音訊號翻譯成 3D 肌肉運動的數值。
• 零件 C (幾何建構)：OpenGL / PyGLM
  作用：負責「打草稿」。它是一個圖形渲染 API，負責把 MediaPipe 抓到的「頭部角度」和 LSTM 算出的「嘴巴肌肉數值」組合起來，在虛擬空間中捏出一個粗糙的 3D 假嘴巴。
• 零件 D (畫面修飾)：DINet_mini (核心生成模型)
  作用：負責「完稿與上色」。它也是基於 PyTorch 構建的。它看著 OpenGL 打好的 3D 草稿，再參考使用者原本的長相，把那個粗糙的假嘴巴「畫」成具有真實皮膚、光影、牙齒的 2D 像素，並完美貼合回原影片。

--

1. MatesX 有什麼突破？

MatesX 是 DH_live 的官方進化版（超輕量級多端數字人對話引擎），它從原本單純的「影片對嘴工具」進化成了「完整的 AI 數字生命系統」。其主要突破包含以下幾點：

• 從「單純對嘴」到「多模態表達」：原本的 DH_live 主要解決嘴型同步的問題，而 MatesX 加入了記憶、表情與動作。它能支援 ARkit 的臉部表情捕捉，讓數字人擁有更生動的情感變化與臉部微表情。
• 全流程管線整合 (All-in-One)：MatesX 內建了即時語音對話的完整服務，將語音活動檢測 (VAD)、語音辨識 (ASR)、大型語言模型 (LLM) 以及語音合成 (TTS) 與數字人渲染無縫串接。
• 極致的多端輕量化：相較於一般虛擬人需要昂貴的 GPU，MatesX 將效能極致壓縮，能完美適配 Windows、macOS、iOS、Android，甚至能直接在手機網頁、微信小程式或普通電腦（結合 llama.cpp 或 EdgeTTS）上即時渲染運行。
• 桌面玩偶型態：相容於同作者開發的 MiniMates 架構，支援作為桌面透明背景的虛擬夥伴進行互動。

--

「數據前處理」 關於 DH_live 浮水印機制的技術拆解與破解可行性

是的，您說的完全正確。「數據前處理」確實是依賴開源包裡面的本地端 Python 腳本（主要是 data_preparation_web.py 等檔案）來執行的。

從技術架構的角度來看，只要是在本地端執行的明文腳本，絕對有辦法破解。

以下為您拆解它的浮水印機制以及理論上的破解思路：

1. 浮水印是怎麼被加進去的？

根據系統的運作邏輯，浮水印（Logo）並不是在即時推理（Live 推流）的時候才掛上去的，而是在**「準備階段」**就已經「燒」進資料裡了。
運作流程大概是這樣：

• 腳本讀取您的原始影片。
• 提取出臉部的特徵圖（Reference Data）。
• 在打包這些特徵圖之前，腳本利用 OpenCV (cv2.addWeighted 等 API) 或 PIL 等影像處理套件，把官方的 Logo 直接壓印在參考圖層的像素上。
• 最後，把這些帶有 Logo 的張量矩陣，連同 3D 網格數據，一起壓縮成 combined_data.json.gz。

因為最終的 DINet_mini 模型在推理時，是「看著」這些 Reference Data 來生成嘴巴周圍皮膚的，如果 Reference Data 上面有浮水印，算出來的結果自然就會帶有浮水印。

2. 破解的兩種技術路徑

既然知道了原理，要繞過或破解這個機制，理論上有兩條路徑：

路徑 A：直接修改 Python 原始碼（最簡單、最直接）

既然 data_preparation_web.py 都在您手上，最暴力的做法就是：

1. 打開該腳本的原始碼。
2. 搜尋處理影像或張量矩陣的段落，找出載入 Logo 圖片或呼叫浮水印疊加函數的地方。
3. 把那幾行代碼註解掉（Comment out），或者替換成透明圖層。
4. 重新跑一次數據前處理，產出的 combined_data.json.gz 就會是乾淨的。
   (註：前提是作者沒有把這段核心的加檔邏輯編譯成 .pyd 或 .so 這種動態連結庫來混淆。如果是純 .py 明文，防護力趨近於零。)

路徑 B：逆向修改數據包（繞遠路）

就算腳本真的被混淆了，最終產出的 combined_data.json.gz 依然是標準格式：

1. 它只是一個 GZIP 壓縮檔，您可以使用 Python 的 gzip 模組或解壓縮軟體把它解開，裡面就是一個純文字的 JSON 檔。
2. JSON 裡面包含了名為 ref_data 的多維陣列（存放參考影像的像素值）。
3. 理論上，只要寫一隻小程式，把這個陣列裡對應 Logo 座標位置的像素值「抹除」或還原，再重新壓回 .gz，就能達成去浮水印的效果。

3. 為什麼作者要這樣做？

身為技術開發者一定明白，這種「本地端運算 + 產出靜態配置檔」的機制，本質上是**「防君子不防小人」**的設計。

作者團隊（MatesX）真正的目標客群是企業級的 B 端客戶（例如做 Kiosk 終端設備、虛擬客服、廣告機的專案）。企業客戶為了避免版權爭議、求穩定、需要官方的技術支援，絕對會乖乖走官方網站上傳 combined_data.json.gz，並支付授權費來獲取合法的無浮水印檔案。

至於 C 端玩家或極客想自己改 Code 拔掉浮水印，作者其實心知肚明防不住，索性當作技術推廣與建立開源生態的成本了。

--

MuseTalk 技術架構與落地評估分析

團隊使用的 MuseTalk (由騰訊 TME Lyra Lab 開發)，屬於一個全新且極度聰明的流派：潛空間單步修復派 (Latent Space 1-Step Inpainting)。

AWS 的 g5.xlarge（配備單張 NVIDIA A10G，24GB VRAM）算力確實不錯，但 MuseTalk 的管線裡塞了 Whisper（極度吃資源）、VAE 還有 UNet。它在「單機單人」展示時畫質很棒，但要在同一張卡上同時即時渲染 3 個裝置的 30fps 畫面（如果還要同時跑 LLM 跟 TTS），GPU 的 CUDA Core 和記憶體頻寬絕對會瞬間被榨乾，導致嚴重的延遲跟卡頓。

在 Kiosk 這種要求即時反應且可能有多台同時連線的商用場景下，「能順暢跑起來」絕對比「牙齒邊緣很清晰」重要太多了。Wav2Lip 因為是純 2D CNN 架構，極度輕量，同樣一台 g5 機器，Wav2Lip 扛下多路併發絕對輕鬆很多。

5. MuseTalk 核心架構圖

【音訊輸入】 ───> [ 1. Whisper-tiny 模型 ] ──────────> 音訊特徵 (高精度多語言理解)
                                                               │
【遮蔽下半臉的影片】 ─> [ 2. VAE 影像編碼器 ] ──> 圖片的「潛空間特徵 (Latent Space)」
                                                               │
                                                               ▼ (Cross-Attention 融合)
                                                [ 3. UNet 生成網路 (借鑒 Stable Diffusion) ]
                                                (核心特色：不經過多次擴散，直接「單步」算出嘴型)
                                                               │
                                                               ▼
                                                [ 4. VAE 影像解碼器 ]
                                                               │
                                                               ▼
【原始影片上半臉】 ──────────────────────────────────────────┼──> (影像縫合)
                                                               ▼
【最終輸出】 <─────────────────────────────────── 具備高畫質、高同步率的即時 2D 影片 (30fps+)

6. 參數驅動 2D (Live2D / Spine)

Live2D 參數驅動架構 (Client-Side Rendering)」**的資料流管線圖。

# 2D 參數驅動虛擬人 (Live2D) 系統架構與資料流管線

【雲端伺服器 (AWS 等) 的工作】────────────────────────────────────────────┐
                                                                         │
【使用者語音/文字輸入】 ──> [ 1. 大語言模型 (LLM) ] ──> 產出回覆文本 (Text)      │
                                   │                                     │
                                   ▼                                     │
                    [ 2. 語音合成引擎 (TTS) ] ──> 產出音訊檔 (Audio)       │
                                   │                                     │
                                   ▼ (極輕量的特徵提取)                      │
                    [ 3. 音頻解析/聲學模型 (Audio to Param) ]              │
                                   │                                     │
                                   ▼                                     │
【伺服器網路輸出】 <── 傳送「音檔」+「微小的嘴型/表情參數序列 (JSON/數值)」──────┘
                                   │ (網路傳輸量極低，且伺服器完全不處理畫面渲染)
                                   │
                                   ▼
【Kiosk 終端機台 (Client) 的工作】──────────────────────────────────────────┐
                                                                         │
                    [ 4. 接收參數與音檔同步 (Sync) ]                       │
                                   │                                     │
【本機預載 Live2D 模型】 ───────────┼─────────────────────────────────┐      │
(包含幾百層網格與物理設定)            ▼                                 │      │
                    [ 5. 終端機物理引擎與參數綁定計算 ] ────────────────┤      │
                                   │ (運算量極低，內顯/普通 CPU 即可輕鬆應付)  │
                                   ▼                                 │      │
                    [ 6. 本機 WebGL / 遊戲引擎渲染 (Rendering) ] <─────┘      │
                                   │                                     │
                                   ▼                                     │
【最終機台螢幕輸出】 <── 60fps 絲滑、無延遲、帶有待機動作與物理慣性的 2D 虛擬人畫面 ──┘

7. 參數驅動寫實 2.5D/3D (WebGL 前端渲染) 系統架構

1. 資源預載 (Pre-loading)

網頁一打開，就把大量的 .ktx2 (臉部/身體的高清紋理貼圖) 和 .json (動畫控制腳本) 下載到瀏覽器快取中。這完全依賴靜態 CDN，伺服器毫無運算壓力。

2. 前端狀態機切換 (State Machine)

• 沒人講話時：前端程式 (Vue.js + 隱藏的 WebGL 引擎如 Three.js/PixiJS) 循環播放 idle 系列的貼圖與 json 參數，讓他有呼吸、眨眼的動作。
• 開始對話時：使用者問問題 ➜ 後端 LLM 產生文字 ➜ TTS 產生音軌與時間戳記 ➜ 前端接收後，立刻依照時間戳記，呼叫對應的 speak 系列 .ktx2 貼圖，在 WebGL Canvas 上無縫替換、拉扯網格，完成對嘴。

3. WebGL 終端硬體加速

因為使用了 .ktx2，普通電腦的內顯晶片就能極度流暢地處理這些畫面的渲染。

【雲端伺服器 (AWS 等) 的工作】──────────────────────────────────────────────┐
                                                                           │
【使用者語音/文字輸入】 ──> [ 1. 大語言模型 (LLM) ] ──> 產出回覆文本           │
                                   │                                       │
                                   ▼                                       │
                    [ 2. 語音合成引擎 (TTS) ] ──> 產出音訊檔 (Audio)         │
                                   │                                       │
                                   ▼ (極輕量的特徵提取)                      │
                    [ 3. 音軌轉碼 (Audio to Blendshapes / Visemes) ]       │
                                   │                                       │
                                   ▼                                       │
【伺服器網路輸出】 <── 傳送「音檔」+「嘴型權重參數序列 (JSON 時間戳記)」 ──────┘
                                   │ (網路傳輸量極低，伺服器完全不渲染畫面)
                                   │
                                   ▼
【Kiosk 終端機台 (Client / 瀏覽器) 的工作】────────────────────────────────┐
                                                                           │
【靜態資源預載】 ──> 從 CDN 下載高壓紋理貼圖 (.ktx2) + 輕量網格模型 (.json) ─┐│
                                   │                                       ││
                                   ▼                                       ││
                    [ 4. 接收即時參數與音檔同步 (Sync) ]                     ││
                                   │                                       ││
                                   ▼                                       ││
                    [ 5. WebGL 引擎 (如 Three.js / PixiJS) 狀態機計算 ] <──┘│
                                   │ (依照 JSON 參數即時切換貼圖與拉扯臉部網格) │
                                   ▼                                       │
                    [ 6. 終端 GPU / 內顯硬體加速渲染 (Texture Mapping) ]     │
                                   │                                       │
                                   ▼                                       │
【最終機台螢幕輸出】 <── 60fps 高畫質、具備真人寫實感與光影的 2.5D/3D 畫面 ───┘

.ktx2 檔案的製作原理，以及它如何實現「偽對嘴」的。

.ktx2 到底是什麼？怎麼做出來的？

.ktx2 (Khronos Texture 2.0) 並不是什麼神祕的 AI 模型，它只是一種為 GPU 量身打造的超級圖片壓縮格式。一般的 JPG 或 PNG，電腦讀取時必須先讓 CPU 解壓縮，然後再傳給 GPU，這個過程很慢；而 .ktx2 裡面裝的是「GPU 原生看得懂的資料 (如 Basis Universal)」，可以直接丟進顯卡記憶體（VRAM）裡秒速渲染，所以效能極高。

製作 .ktx2 的標準工序（素材準備期）：

• 實拍與預錄 (影片拆解)：
  首先，你要讓真人模特兒進攝影棚，請他用誇張一點的嘴型，把所有的基礎母音、子音（Visemes）都念一遍。
  然後，請他錄製各種「待機 (Idle)」動作：微笑、眨眼、輕微點頭。
• AI 摳圖與清洗 (序列幀提取)：
  用 AI 工具（例如 Runway 或本地的摳圖模型）把真人的背景完美去除，只留下透明背景的人物。
  將影片轉換成幾千張的高畫質 PNG 圖片序列幀。
• 壓縮轉換 (生成 .ktx2)：
  這一步是關鍵。你會使用像 toktx（Khronos Group 官方提供的工具）或 Basis Universal 的轉檔程式，將這些大量的 PNG 圖片，壓縮打包成一個個 .ktx2 檔案。
  idle_1.ktx2、speak1_0.ktx2 這樣規律的命名。它們其實就是**「已經預先準備好的高壓圖片集」**。

那它怎麼「對嘴」？（前端狀態機的把戲）

既然素材都是預先做好的靜態圖片（或序列幀），那它怎麼配合 LLM 即時生成的語音說話呢？這就是前端工程師（WebGL / Three.js）大顯身手的時候了。

這套機制的「對嘴」，其實是**「聲音驅動動畫狀態機 (Audio-Driven Animation State Machine)」**：

前端拿到音檔：AWS 伺服器把 LLM 生產的文字轉成語音檔（.wav 或 .mp3）丟給 Kiosk 機台。

即時頻譜分析 (或音素提取)：機台的瀏覽器利用 Web Audio API，即時分析這段聲音的頻率或音量大小。更高級的做法是，伺服器在給音檔的同時，順便丟一串 JSON，裡面寫著：「0.5秒時發出 'A' 的音，1.2秒時發出 'O' 的音」。

瞬間抽換貼圖 (Texture Swapping) + 網格變形 (Mesh Deformation)：

前端的 WebGL 引擎（如 Three.js）此時正在播放 idle（待機）的 .ktx2 貼圖。

當它偵測到聲音指令時，它會瞬間切換到對應嘴型的 speak 系列貼圖。

如果只有幾何圖形的切換會很生硬，所以高階的做法會搭配一個極輕量的 2D 臉部網格 (Face Mesh)。WebGL 引擎會根據聲音大小，稍微拉扯這個網格的嘴巴頂點（就像你在拉皮一樣），讓替換上來的貼圖產生微小的動態變化，看起來就更像真的在說話。

這不是像 MuseTalk 那樣，AI 每一格都在算「這個人的嘴唇肌肉該怎麼動」。

這是一場精心設計的**「連環畫 (Sprite Sheet) 播放秀」。它犧牲了極致的唇齒咬合準確度（有時候你看這種虛擬人，會覺得嘴巴開合有點「套公式」的感覺），換來的是絕對的流暢、零伺服器渲染成本、以及極高解析度的真人畫質**。

對於一個必須放在展場、可能同時有十幾台同時運作、且不能有絲毫卡頓的商業 Kiosk 專案來說，這種「高級的移花接木」往往是比「純粹的 AI 生成」更成熟、更務實的工程決策。

「頂配版」Viseme (WebGL + .ktx2)：

高解析度資產：他們不用粗糙的圖片，而是用了 .ktx2 這種能讓 GPU 瞬間載入的超高畫質無損貼圖。

網格融合 (Blendshapes / Morphing)：這是靈魂所在。前端 WebGL 引擎在切換 A 嘴型到 O 嘴型時，不是瞬間跳轉，而是透過底層的 3D/2.5D 網格，把嘴唇的頂點「平滑地推擠過去」。這種補幀與拉扯，消除了生硬感，讓它看起來像真的肌肉在動。

# WebGL 寫實虛擬人 (.ktx2) 實拍 PNG 素材需求清單

要製作一個能順暢對嘴的 WebGL 真人模型，素材準備數量大約落在 **30 張到 100 張 PNG** 之間。這取決於你們採用的是「極致壓縮派」還是「序列幀派」。

## 方案 A：極致壓縮派 (強烈推薦，效能最好)
**預估數量：約 25 ~ 40 張 PNG**
這套做法是目前業界最頂尖的做法。核心概念是：只拍「關鍵畫格」，中間的過渡動作全部交給 WebGL 的 3D 網格去平滑計算（Blendshapes / Morph Targets）。

### 📸 拍攝清單 (Checklist)：
1. **基礎待機 (Idle) - 約 4 張**
   * 1 張完美的放鬆正臉基底圖。
   * 3 張眨眼差分圖（眼睛全開、半閉、全閉）。
2. **標準音素嘴型 (Visemes) - 約 15 張**
   * 業界通常採用 Oculus 或 Apple ARKit 的 15 種標準嘴型規範。
   * 請模特兒擺出並定格拍攝：`sil` (閉嘴靜音)、`PP` (ㄅ/ㄆ/ㄇ)、`FF` (ㄈ/f/v)、`TH` (咬舌音)、`DD` (ㄉ/ㄊ)、`kk` (ㄍ/ㄎ/c/g)、`CH` (ㄐ/ㄑ/ch/j)、`SS` (ㄙ/s/z)、`nn` (ㄋ/n)、`RR` (ㄖ/r)、`aa` (ㄚ/a)、`E` (ㄝ/e)、`ih` (ㄧ/i)、`oh` (ㄛ/o)、`ou` (ㄨ/u)。
3. **情緒微表情 (Expressions) - 約 5~10 張 (選配)**
   * 微笑、大笑、皺眉、疑惑、生氣等。

**💡 打包技巧 (Texture Atlas)**：
前端工程師**不會**讓這 30 張 PNG 變成 30 個 `.ktx2` 檔案。他們會把這 30 張圖拼成一張巨大的「精靈圖集 (Sprite Sheet)」，然後只轉成 **1 個超級高畫質的 `.ktx2` 檔案**。程式執行時，只要改變 UV 座標就能瞬間換臉，連載入時間都省了。

---

## 方案 B：動態序列幀派 (較佔用記憶體，但製作較簡單)
**預估數量：約 150 ~ 300 張 PNG**
如果前端團隊不太會做 3D 網格的平滑變形，那就只能靠「翻閱連環畫」的方式來騙過眼睛。

### 📸 拍攝清單 (Checklist)：
1. **待機呼吸動畫 (Idle Loop) - 約 60 張**
   * 錄製模特兒靜靜看著鏡頭呼吸 2 秒鐘 (30fps * 2s = 60 張 PNG)。
2. **說話過渡短片 (Speak Animations) - 約 100~200 張**
   * 錄製模特兒說幾段包含所有母音、子音的短句。
   * 將短片切成一段一段的序列幀。前端根據語音分析，找出對應的「短片片段」來播放。
   * （你抓包到的 ADI 展館，如果有 `idle_0`, `idle_1`, `speak1_0` 這種規律命名，且檔案很多，很可能就是混合了這種「短片序列幀」的做法）。

8. 前端局部貼圖替換 (Canvas BBox Overlay)

前端局部貼圖替換 (Canvas BBox Overlay) 技術解析與管線圖

這套由 NexAvatar 原始碼揭露的技術，可以被稱為「極致的頻寬與算力精算師」。它放棄了高大上的 3D 網格或全畫面生成，回歸到最傳統的 2D 影像合成（Compositing），但在商業落地上卻取得了驚人的效能優勢。

1. 核心技術說明 (How it works)

這套系統的底層邏輯是 「底片輪播」+「精準補丁」：

1. 底片輪播 (Preloaded Base Frames)：
   機台在剛啟動時，會先從伺服器把人物的「無聲動作影片」拆解成的數百張靜態圖片（raw_jpgs）預先下載到瀏覽器記憶體中。當沒人講話時，前端 Canvas 就只是像播放幻燈片一樣，不斷循環播放這些底片（Idle 動畫）。
2. 精準補丁 (BBox Overlay)：
   當 AI 產生語音時，伺服器**「只渲染嘴巴那一小塊方形區域」**的圖片（可能只有 160x160 像素），並透過 WebSocket 傳給前端。
3. 座標定位 (Bounding Box)：
   前端有一份預載好的 bbox.json，裡面記錄了每一張底片中「嘴巴的確切 X, Y 座標」。前端只要把收到的嘴巴小圖，精準地「貼」在底片的那個座標上，就完成了對嘴。
4. 綠幕去背 (Alpha Masking)：
   為了讓人物可以融入任何背景，系統還預載了黑白遮罩圖（pha），利用 Canvas 像素操作（程式碼中的 removeGreen）即時把背景挖空。

2. 系統架構與資料流管線 (Pipeline)

以下是這套系統在運作時的完整資料流管線：

【雲端伺服器 (AWS 等) 的工作】──────────────────────────────────────────────┐
                                                                           │
【使用者語音/文字輸入】 ──> [ 1. 大語言模型 (LLM) ] ──> 產出回覆文本           │
                                   │                                       │
                                   ▼                                       │
                    [ 2. 語音合成引擎 (TTS) ] ──> 產出音訊檔 (Audio)         │
                                   │                                       │
                                   ▼ (極小區域的嘴型渲染)                    │
                    [ 3. 嘴型生成 (僅產生 160x160 等級的小塊嘴部圖片序列) ]  │
                                   │                                       │
                                   ▼                                       │
【伺服器網路輸出】 <── 透過 WebSocket 傳送「音檔」+「嘴部小圖小碎片(Base64)」 ─┘
                                   │ (網路傳輸量極低，不傳送全畫面，伺服器算力消耗極微)
                                   │
                                   ▼
【Kiosk 終端機台 (Client / 瀏覽器) 的工作】────────────────────────────────┐
                                                                           │
【靜態資源預載 (Preload)】 ──> 下載底片 (jpg) + 遮罩 (pha) + 座標檔 (bbox.json)│
                                   │                                       │
                                   ▼                                       │
                    [ 4. 接收 WebSocket 資料與音檔同步 (Audio Sync) ]        │
                                   │                                       │
                                   ▼ (進入 drawFrame 渲染迴圈)               │
                    [ 5. 畫出當前幀的「全身底片」 (drawImage) ]               │
                                   │                                       │
                                   ▼                                       │
                    [ 6. 讀取 bbox.json 座標，將「嘴巴碎片」覆蓋貼上 ]        │
                                   │                                       │
                                   ▼                                       │
                    [ 7. 疊加 pha 遮罩，進行去背景處理 (removeGreen) ]       │
                                   │                                       │
                                   ▼                                       │
【最終機台螢幕輸出】 <── 透過 HTML5 Canvas 輸出 25fps 的即時對嘴合成畫面 ────┘

3. 商業落地優缺點評估

這套架構是專門為了解決「高昂伺服器成本」與「多機台併發」而誕生的：

• 絕對優勢：伺服器與頻寬成本極低
  伺服器不需要渲染 1080p 或 4K 的全畫面影片，只需要生成並傳送像郵票一樣大的嘴巴圖片。這使得一台普通的伺服器就能同時支撐海量 (無限多路) 的機台連線，徹底告別 Wav2Lip 或 MuseTalk 帶來的硬體焦慮。
• 絕對優勢：不挑終端硬體
  它使用的是最基礎的 HTML5 Canvas 2D 繪圖 API (drawImage)，連 WebGL 都不需要。這意味著哪怕是效能極差的舊款平板、便宜的 Android 廣告機，都能順暢跑滿 25 幀。
• 致命缺點：視覺破綻 (接縫問題)
  因為它是把一個方形的嘴巴圖片「硬貼」在底片上，如果人物頭部轉動幅度較大，或是環境光影變化複雜，肉眼很容易在嘴巴周圍看到方形的邊緣接縫或是膚色不均（俗稱的「貼狗皮膏藥」感）。它不像 ADI 展館的 WebGL 網格變形那樣能做到肌肉邊緣的平滑過渡。

4. 製作

Canvas BBox Overlay (局部貼圖替換) 開發難度拆解

1. 前端播放器開發 (難度：★☆☆☆☆ 極簡單)

只要是寫過一點點 Canvas 或是網頁小遊戲的前端工程師，一天之內就能把雛形刻出來。

• 技術點：就是用 ctx.drawImage() 把底圖畫上去，再把嘴巴圖蓋到指定的 X, Y 座標上。沒有 3D 矩陣、沒有 Shader、不牽涉 WebGL，純粹的 2D 圖片疊加。

2. 後端即時推流 (難度：★★☆☆☆ 簡單)

• 技術點：伺服器收到 LLM 的文字，丟給 TTS 產出聲音。接著（可能搭配輕量的 Wav2Lip 或 SadTalker）只針對「嘴巴區域」生成 160x160 的小圖片序列，轉成 Base64 透過 WebSocket 塞給前端。因為圖片極小，所以伺服器幾乎沒壓力。

3. 前期資產與數據準備 (難度：★★★★★ 魔王級)

這才是這套系統真正的「商業機密」與護城河。您在程式碼看到的那些 bbox.json 還有完美的去背圖，都是前期靠 Python 腳本跟電腦視覺（CV）演算法苦工熬出來的：

• 地雷 A：嘴巴座標追蹤 (Tracking)
  您不能手動去標記 300 張底片的嘴巴位置。您需要寫一支 Python 程式，用 MediaPipe 或 OpenCV 跑過整段「待機影片」，精準抓出每一格畫面嘴巴的 [x1, y1, x2, y2]，然後匯出成 bbox.json。如果人頭有晃動，這個框沒抓準，前端貼上去的嘴巴就會跟著狂抖。
• 地雷 B：邊緣融合與膚色統一 (Blending)
  這是最難的。生成的嘴巴圖片，如果直接「硬貼」在底片上，邊緣一定會有明顯的色塊或方形接縫（像貼狗皮膏藥）。這通常需要用 OpenCV 進行邊緣羽化 (Feathering)，或是更進階的泊松融合 (Poisson Blending)，讓嘴唇周圍的膚色能跟底片的膚色無縫渲染在一起。
• 地雷 C：去背遮罩 (Alpha Matting)
  為了讓虛擬人能換背景，需要用高精度的 AI 摳圖模型（如 MODNet 或 RVM），把影片每一格的背景精準挖空，產出那堆 pha 遮罩圖，連髮絲都要乾淨，否則 Canvas 去背時邊緣會有一圈綠光或黑邊。

總結： 如果專案的預算極度受限、機台硬體非常老舊，且能容忍稍微有一點點「合成感」，這套 Canvas BBox Overlay 絕對是商業戰場上最務實的生存法則。