綜合避難所

https://coveredge.cover-corp.com/lｉst/3037

降低溝通成本：提升工作室3D直播的3D模型實裝效率

#直播技術
#技術部落格
2025/9/25

大家好，我們是Cover Corporation創意製作本部技術開發部！

在本文中，我們將介紹我們如何透過開發 Unity Editor 擴充功能，來提升工作室 3D 直播中 3D 模型實裝效率的相關舉措！

目錄

背景

欲解決的課題

解決方案：設計師自行實裝機制的工具 「GimmickEditor」

獨特的設計考量

目前的營運狀況

未來展望

結語：我們正在招募工程師！

1. 背景

在 Cover，我們利用內部開發的 「工作室應用程式 (Studio App)」，來進行旗下藝人的紀念直播和大規模活動的 3D 演唱會的直播與錄製。例如，以下演唱會就是使用工作室應用程式進行的直播：

https://www.youtube.com/watch?v=E2D_YFRHFG8
【#兎田ぺこら6周年記念LIVE】周年3D LIVE！ぺこらRUSH！！！！！！！ぺこ！【ホロライブ/兎田ぺこら】

https://www.youtube.com/watch?v=k8Jjwu3YwPo
hololive production COUNTDOWN LIVE 2024▷2025

在這些演唱會製作中，我們會根據每次直播的概念，新建或修改 3D 模型，包括舞台、服裝和道具。這些 3D 模型中內建了將燈光顏色更改、舞台裝飾切換、效果觸發等功能與 UI 連結的機制。操作人員透過操作 UI，來創造現場表演的視覺效果。我們在公司內部將這些機制統稱為 「Gimmick（機制/機關）」。

每年需要實裝 3D 模型的 3D 直播多達 80 場以上，隨之而來需要實裝的「機制」數量也十分龐大。

2. 欲解決的課題

由於 3D 模型實裝工作量不斷增加，我們確立了 「盡量避免因 3D 模型實裝工時成為瓶頸而無法滿足藝人要求」 的目標，並著手解決以下課題：

課題一：設計師與工程師之間的溝通成本高

設計師的負擔： 必須將詳細規格（例如要操作哪個物件、哪個參數、以及如何操作）整理成 文件。

工程師的負擔： 需要解讀設計師建立的文件，並對照 Unity 上的實際物件來理解規格，以便實裝機制。

這種 「透過文件傳達資訊」 的方式，除了實裝本身的工時外，還導致了為確保雙方理解一致而產生的 溝通成本 大幅增加。

課題二：因實裝結果與預期不符而產生「重做」

▼ 具體案例

著色器（Shader）控制認知差異

設計師的意圖： 希望操作參數 A。

工程師的實裝： 錯誤地實裝了操作參數 B 的機制。

物件顯示範圍誤解

設計師的意圖： 隱藏物件 A、B、C。

工程師的實裝： 錯誤地設定為隱藏物件 A、B、C、D。

雖然這些問題會在 QA 檢查中被發現，確保了直播品質，但後續的 回饋和修正處理 耗費了大量的工時，成為阻礙整體製作速度的一個原因。

3. 解決方案：設計師自行實裝機制的工具「GimmickEditor」

「溝通成本」 和 「重做」 這兩個課題，其根本原因在於負責構思機制規格的 設計師 與負責實裝的 工程師 之間存在職責分離。

當時，機制的實裝是透過手動組合現有元件來完成的。然而，要判斷該使用哪些元件、如何使用，需要非工程師的設計師去解讀控制這些元件的程式碼。這對他們來說是一個 很高的門檻。

為了解決這個問題，我們決定採取 「設計師自行實裝機制」 的方針，並開始開發專用工具 「GimmickEditor」。

什麼是 GimmickEditor？

工作室應用程式使用的 3D 模型實裝流程為：3D 模型創建 → 機制實裝 → AssetBundle 打包 → 工作室應用程式載入。

GimmickEditor 是一個 Unity 編輯器擴充功能，旨在讓設計師能夠負責 「機制實裝」 這個步驟。

設計師只需像下圖左側所示，在 GimmickEditor 中輸入最少的必要資訊，即可設定 3D 直播所需的機制。當工作室應用程式載入設定了這些機制的 3D 模型 AssetBundle 後，它們就會像下圖右側所示，作為可由工作室應用程式控制的機制顯示出來。

這個「顯示/隱藏切換」僅為其中一個例子。 目前，我們針對超過 20 種 標準化的機制（例如著色器值更改、效果播放、動畫控制等），分別提供了專用的 客製化視窗。

GimmickEditor 帶來的效果

透過導入這個工具，我們旨在針對前述兩個課題達成以下效果：

削減溝通成本 (針對課題一的效果)

過去必要的 「向工程師傳達規格」 工作將部分不再需要。由於設計師可以自己實裝機制，我們希望減少規格文件製作和實裝委託會議等溝通環節，從而降低成本。

實現「符合意圖」的實裝 (針對課題二的效果)

設計師可以直接在 Unity 編輯器上嵌入機制，並即時確認外觀和行為。我們希望藉此達成以下狀態：

杜絕實裝錯誤： 不會發生「與預期不符」的實裝偏差。設計師所見、所意圖的，就是最終的成果。

高速回饋循環： 設計師可以一貫地完成規格構思、實裝和確認，從而實現創意試錯的快速迭代。

4. 獨特的設計考量

非工程師也能操作

GimmickEditor 以使用者為非工程師為前提進行開發。

操作 UI 和功能設計上，重視直覺性的理解。

完善的操作手冊與示範影片

為每個機制準備了說明文件。

附上操作示範影片，使難以用文字傳達的行為更容易被視覺化理解。

流程重構

改善前： 設計師向工程師委託實裝，並在回饋時需要不斷溝通。

改善後： 實裝到確認都由設計師自行完成，從而抑制溝通成本和認知差異的發生。

整備詢問環境

提供了工具內直接向工程師詢問的功能。

自動獲取使用者的程式碼儲存庫 (Repository) 和分支 (Branch)，並支援手動輸入專案名和場景名，盡可能跳過重現環境的詢問環節。