GIF 轉 Flipbook 貼圖 — 將任何 GIF 打包成 Unity 與 VRChat 的影格條

GIF 是一條時間軸。flipbook 貼圖就是將同一條時間軸打包成一張圖片，讓著色器可以依索引逐格播放，而不是由播放器逐一尋找影格。你將 GIF 拖入工具後，它會偵測影格數、尺寸與延遲，然後寫出單列或網格狀的影格條，並附上可貼入材質的 rows 與 columns 中繼資料。

本頁說明 gif 轉 flipbook 轉換實際上會為 Unity、Godot 與 VRChat 產生什麼 — flipbook 著色器需要的四個數字、Poiyomi 材質上該設定什麼，以及何時影格條會優於網格。輸出是一張帶有透明背景的 PNG，旁邊會以純文字標示 rows/columns 數量。

拖入 GIF

工具主體就是第一個畫面。拖放區位於頂部；下方的一切都是輸出。將 GIF 拖到上面，工具會讀取影格數、每格延遲、畫布尺寸與處置方式。它會在寫入任何內容之前回報偵測到的結果，因為現實中的 GIF 對這四項的定義經常不一致。

通常有兩件事需要決定。第一，影格延遲不均：大多數 flipbook 著色器以固定 FPS 逐格播放，因此延遲混合的 GIF 必須重新取樣為固定速率，或以其最慢的共同影格時間匯出。第二，處置方式：如果 GIF 在影格之間只重繪變更的區域，而你直接堆疊影格，就會出現殘影。工具會在打包前將每個影格合成到完整畫布上，因此部分重繪會變成完整影格。

合成完成後，封裝器會寫出一張圖片。一個 24 影格、128x128 的 GIF 會變成 3072x128 的影格條。同樣的影格以 6x4 網格排列則會變成 768x512。兩者的像素相同；差別在於著色器如何處理 UV。

什麼是 flipbook 貼圖

flipbook 著色器會讀取四個數字：rows、columns、目前索引與 FPS。它取得 0 到 1 範圍內的 UV 座標，將其分割成 row/column 儲存格，再依目前索引位移該儲存格。貼圖本身是靜態的。除非索引移動，否則不會有任何動畫。

索引通常是從時間推導而來。使用單列影格條時，索引等於 floor(時間乘以 FPS)，而 U 座標會依索引除以 columns 的結果位移。使用網格時，索引也會決定 row：row 等於 floor(索引除以 columns)，column 等於索引對 columns 取模。這就是為什麼單列影格條是較簡單的情況 — 只有一個維度需要逐格行走。

rows 與 columns 必須與圖片完全相符。一張 3072x128 的影格條，若宣告 24 columns 與 1 row，取樣會正確。宣告 23 columns 的話，每個影格都會偏移一個儲存格的分量，看起來就是對角拖影。宣告 1 column 則會得到靜態圖片。這兩個錯誤占了大多數損壞的 flipbook。

FPS 與影格數是分開的。24 影格的影格條以 12 FPS 播放，每秒循環兩次。24 影格的影格條以 24 FPS 播放，每秒循環一次。貼圖資料完全相同；只有時鐘改變。請將 FPS 與 row 和 column 數量放在同一個地方，這樣它們永遠不會不同步。

rows、columns、索引、FPS。rows 與 columns 描述貼圖。索引與 FPS 描述時間。rows 與 columns 在匯出時固定。索引是動態的，屬於著色器或腳本。FPS 對大多數著色器而言是固定的，但當你想要控制速度時，可以由參數驅動。

如果你的著色器有速度或播放速率參數，它會乘以時間項，而不是 FPS 常數。請將匯出的 FPS 保留為基礎速率，這樣當速度為 1 時，中繼資料仍然有意義。

Unity 的 flipbook 貼圖

在 Unity 中，flipbook 通常是套用在 Quad 或粒子上的材質。匯入 PNG 時啟用 sRGB，若影格很小則關閉 mipmaps，並將 alpha is transparency 設為開啟。環繞模式應設為 Clamp，而不是 Repeat — 重複環繞的 flipbook 會在 UV 邊緣將最後一個影格繞回第一個，並顯示出一像素的接縫。

驅動索引有兩種方式。在具有內建 flipbook 節點的 Unlit 或 Particles 著色器上，你將並排設定為 rows 與 columns，並餵入 0 到 1 的混合值。在自訂著色器上，你自己編寫 UV 數學，並將 rows、columns 與 FPS 公開為材質屬性，這樣就能在不需要重新編譯的情況下編輯。

你要貼入的中繼資料：rows、columns、影格數、匯出的 FPS。如果你的著色器使用正規化混合而非整數索引，混合範圍是 0 到影格數除以總網格儲存格數 — 對於 24 影格的單列，這是 0 到 1；對於 6x4 網格且 24 影格分布在 24 個儲存格中，這也是 0 到 1。部分網格是容易讓人出錯的情況：一個 6x4 網格有 20 影格時，結束於 20 除以 24，約為 0.833。超過這個範圍就會取樣到空的儲存格。

VRChat 的 Poiyomi flipbook

Poiyomi 內建 flipbook 節點，這是製作會說話的嘴巴、捲動螢幕或 avatar 上兩影格切換的常見做法。該節點接受一張貼圖、一組 rows 與 columns，以及一個混合值。VRChat 不會在執行階段從腳本執行自訂著色器程式碼，因此索引必須來自動畫材質屬性或動畫控制器驅動的參數。

網格模型與材質一樣重要。在平坦 Quad 上的 flipbook 能正確呈現；同樣的貼圖在曲面上，會因為 UV 分布不均而顯示出拉伸的儲存格。請將 flipbook 材質保持在平面或接近平面的網格模型上。

當動畫是循環時，Poiyomi 請使用影格條版面，因為 UV 數學只需一次乘法與一次加法。當動畫是一組你想要跳轉的離散狀態時，請使用網格版面 — 一個有四種形狀的嘴巴，用 4x1 網格搭配整數索引來思考，會比用捲動更容易理解。

影格條 vs 網格：該匯出哪一種

像素資料完全相同。選擇取決於誰要使用它。著色器想要影格條。引擎與 Sprite 系統想要網格。請根據使用端來選擇，而不是檔案大小 — 影格條較寬，網格較接近正方形，而兩者在相同總像素數下的壓縮效果相似。

影格條只有一個 row，因此 V 座標不會用到，著色器只會位移 U。這代表指令較少，數學出錯的方式也較少。網格會使用兩個軸，這正是以圖集為基礎的系統所預期的。如果不確定，請匯出影格條，只有在引擎匯入器要求時才重新匯出為網格。

還有一種情況是預期個別影格的 Sprite 動畫器。有些引擎想要一個裝滿 PNG 的資料夾，而不是圖集。工具可以將影格個別寫出，但磁碟上的圖片會是所有影格的總和，而不是單一檔案，且匯入設定是逐影格設定。

在 3D 中實際遊玩

靜態平面上的 flipbook 貼圖證明不了什麼。你必須檢查的是那些只有在動態中才會顯現的主張：接縫是否環繞正確、alpha 在遠處是否保持、相機移動時 FPS 感覺是否正確。The Cyclops' Island 是在 3D 遊戲建構器中打造的可遊玩場景，其中的表面會即時產生動畫，因此你可以看著 flipbook 在幾何旁邊循環，而不是在 Inspector 裡。

打開它，走過表面，並觀察循環點。如果 flipbook 少了一個影格或 columns 多了一欄，你會在那裡看到 — 明顯的卡頓或對角拖影 — 而且是在你上傳資產之前。這就是可遊玩場景的完整論點：失敗是視覺上的，而視覺失敗需要視埠。

同一個場景可以作為參考，了解翻動影格在不同距離與相機角度下的呈現。在近距離 128 像素下看起來沒問題的影格，若沒有 mip 控制，在遠處會產生鋸齒；在遠處看起來沒問題的影格，在近距離可能太模糊。這兩者在移動時都比較容易判斷。

走進它所屬的世界

Sprite 是一個無處可站的角色。最後一步是其他人沒有提供的：將你剛做好的圖集放進一個有人可以四處走動的世界 — 一座小島、一顆行星、一個下雨的街角。本網站上的每個世界都是從一段文字描述製作出來，並發布成你可以遊玩的頁面。

常見問題