GIF 轉精靈表工具 — 免費、在瀏覽器內完成、不必上傳

GIF 轉精靈表聽起來很簡單，親手做一次就知道不是。GIF 本身就是一串完整影格，帶著調色盤與逐格延遲，所以你真正需要的工具得能：解碼每一格、正確合成透明、再把这些影格排進同一張 PNG，而且排出來的網格要能用貼圖座標定址。Neta Studio 的轉換器把解碼這一步放在瀏覽器裡的 canvas 上做，檔案留在瀏覽器，不會碰到伺服器。你丟進 GIF，選好欄數、列數與 FPS，下載一張 PNG 圖集。

難的從來不是畫圖，而是調色盤、時間與網格數學。GIF 的透明是以色表索引的方式儲存，所以一格在看圖軟體裡看起來很乾淨，合成到 canvas 之後卻可能帶著黑邊或白邊。GIF 的影格延遲單位是百分之一秒，而且常常每格都不一樣；這也是天真的匯出方式會做出看了會卡的精靈表的原因。這一頁講的是真正關鍵的設定，還有我們在做這個工具時實際撞到的失敗模式。

把 GIF 轉成精靈表

轉換器就放在頁面最上面：一個拖放區、一條影格預覽列，加上四個控制項——欄數、列數、FPS，以及保留 alpha 通道的開關。檔案丟進去之後，瀏覽器會透過 GIF 解碼器為每一格建立一個 ImageBitmap，以來源尺寸畫到離屏 canvas 上，再照算好的儲存格位置 blit 進圖集 canvas。來源檔是用 File API 讀進來、放在記憶體裡的。不會有任何帶著你 GIF 的網路請求。

輸出一律是 PNG。PNG 有 8 位元 alpha 通道，這正是做角色需要的；JPEG 會把每一條柔邊壓成硬邊。如果你的 GIF 本來就沒有透明，圖集仍然是 RGBA，用不到的 alpha 位元只多佔一點檔案大小。如果 GIF 真的用了透明，解碼時必須取得套用 disposal 之後的完整影格，而不是局部更新，否則會動的元素會在整張表上拖出殘影。

精靈表要照引擎取樣的方式來排，不是照它在檔案總管裡看起來的樣子。4x4、每格 64x64 的網格就是 256x256 的貼圖，第 n 格的位置是欄 n mod 4、列 floor(n / 4)。目標引擎或著色器圖集要求 2 的次方時，就把尺寸做成 2 的次方；320x320 的表在某些路徑上會被補齊或重新取樣，精靈邊緣會糊掉。

VRChat 用的 GIF 轉精靈表

VRChat 的翻頁動畫（flipbook）著色器把貼圖當成一條橫向長條讀，不是網格。你給它 6x4 的表，它只會把第一列當長條重複播，因為它的 UV 計算是假設所有影格都在同一列、影格索引只在 U 軸上前進。把欄數設成影格數、列數設成 1：24 格動畫就變成一張 24x1 的表。

長條的總寬度要做成 2 的次方。24 格、每格 64 像素的長條寬 1536 像素，不是 2 的次方；下一個能被 64 整除的尺寸是 2048，可以放到 32 格。多出來的儲存格可以填透明像素，也可以放最後一格的複本。2 的次方之所以要緊，是因為非 2 次方貼圖在上傳路徑上經過 mipmap 生成或壓縮之後，取樣可能偏移半個 texel，而只有一像素寬的精靈馬上就看得出來。

alpha 在這裡處理，在精靈表上處理，不要丟給著色器。著色器裡的 cutout 或 alpha test 是很粗的工具；GIF 抗鋸齒輪廓留下的柔邊會依門檻值決定留下還是消失，而你不會想為每一隻 avatar 調那個門檻。把 PNG 匯出成帶真 alpha、邊緣對預乘安全的形式，著色器只要取樣就好。迴圈節奏要一致：VRChat 的翻頁動畫以固定時間步進推進，所以如果你的來源 GIF 每格延遲不規則，匯出前先把它們拉平，否則動畫會用一個和原始時間不一致的等速播完。

完整的參數清單與貼圖設定，請看翻頁動畫貼圖指南。

GIF 轉影格網格（「試算表」）

會搜 gif to spreadsheet 的人，幾乎都不是要找 .xlsx。他們要的是影格網格：影格照列與欄排好，每一格都能用索引定址。會用這個字，是因為網格乍看之下很像試算表。這個工具產生的就是那個網格，而網格和精靈表是同一件事——差別只在你怎么稱呼它。真正要緊的是排列要規則：儲存格尺寸固定、欄數固定、影格順序由左到右、由上到下。

另一種有人會試的做法，是在像素繪圖軟體裡一格一格畫，疊洋蔥皮疊到動畫看起來對為止。那個流程適合自己從頭畫角色，遇到手上已經有 GIF 就很糟。像素編輯器不會讀 GIF 的逐格延遲，手動把 24 格匯進 24 個圖層，時間資訊就整個不見了。來源本來就是動畫的話，轉成網格是比較短的路。像素工具值得用的時機是在創作，不是在轉檔。

如果要手繪影格，像素藝術那幾頁講的是繪製與調色盤的部分。

影格尺寸、網格與透明背景

大多數轉換會壞在四件事上。每一件都有明確的症狀。

GIF 的透明死在調色盤上。GIF 最多只能用 256 色，透明是用調色盤索引標記的。當某一格以 disposal method 2 解碼時，某一格原本透明的地方可能會被還原成前一格的背景色。解法是每一格都合成到透明緩衝區上，而不是合成到白色上。如果預覽裡精靈周圍出現黑或灰的形狀，那就是調色盤的背景索引，而且它現在已經是實際像素了。

最後一列不滿。如果影格數是 23、你選 6 欄，會得到三列滿的，加上最後一列只有五格而不是六格。圖集高度仍然會進位到完整的一列高。如果引擎的翻頁動畫計算是假設網格是滿的，用總影格數除以欄數去推索引，迴圈尾端就會讀到空格。用透明儲存格把整張表補成完整矩形，或是把欄數減到能整除。

影格尺寸必須能整除整張表。從 320 寬的表裡取寬 64 的子矩形，剛好五欄。從 330 寬的表裡取，會得到五欄加 10 像素的餘數，而那 10 像素不是影格。兩個軸向都讓表尺寸等於影格尺寸乘上欄數（列數）。

原點差一格。貼圖 UV 通常從左下角起算，影格網格卻是從左上角開始排。如果第 0 格畫出來是最後一格，代表你的引擎把 V 反過來了。第 c 欄、第 r 列的精靈儲存格在影像座標裡是 x = c * width、y = r * height，換成翻轉的 UV 就是從 1 減掉它。

精靈表接下來去哪

不管去哪，匯出的都是同一張 PNG；差別在引擎期待貼圖怎麼切、以及它怎麼處理 alpha。下面這份就當快速對照。

每個目標各匯出一張表，用那個目標不需要自訂著色器就能讀的網格。要同時支援兩個目標，就匯出兩張：VRChat 用橫向長條，引擎用網格。從同一個 GIF 再匯出一次，比為了两邊寫一套 UV 換算快。

在 3D 裡看你的精靈表動起來

大多數轉換器到 PNG 就停了，驗證的事留給你自己另外找地方做。3D game builder 會繼續往下走：你可以把一張表貼到面向鏡頭的平面上，在真實場景裡看它跑，這是唯一能回答網格與時間對不對的測試。Agent Sprite Forge 則是精靈變成有控制器的角色的地方；精靈就是角色，3D 世界是它住的地方。

The Cyclops' Island 就是這個想法的可玩示範——一個小小的 3D 場景，可以在裡面走動、在瀏覽器裡生成、用精靈當角色。把你的表丟進去，帶動示範影格的那套機制就會去取樣你的圖集。影格順序錯了，你馬上就看得出來：角色倒退走，或在迴圈尾端跳到空格。alpha 錯了，身體周圍會出現一個硬邊矩形。這些和你在引擎裡會遇到的失敗完全相同，大概五秒就能看見。

去玩玩看 The Cyclops' Island 這個可玩場景，換上你自己的圖集。

更多免費精靈工具

轉換器只是其中一塊。下面三個補上 Neta Studio 上精靈流程的其他部分，而且都在同一個瀏覽器工作階段裡跑，本機檔案處理方式也一樣。

走進它真正所屬的那個世界

精靈是一個沒有地方站的角色。最後這一步別人沒做：把你剛做好的表放進一個能讓人走動的世界裡——一座小島、一顆行星、一個下雨的街角。這個網站上每一個世界都是從一段文字描述生成，發布成一個可以直接玩的頁面。

常見問題