3Dブラウザゲームの画像を軽くするには？KTX2とテクスチャ配信の考え方

1. KTX2はGPU向けテクスチャを届けるための容器

KhronosのKTX資料では、KTXをGPUテクスチャ向けのコンテナ形式として説明しています。KTX 2.0はBasis Universalの圧縮されたテクスチャを扱い、実行時に各GPUの対応形式へ変換する構成を提供します。一般的なWeb画像を小さくする話と、GPU向けの圧縮を使う話を分けて考えます。

最初に見るのは、背景、地形、キャラクター、装飾のテクスチャ一覧です。解像度、透過の有無、どの画面で必要になるかを記録します。画面では小さくしか見えない模様に大きな画像を使っているなら、形式の変更より解像度の調整から比較できます。必要な場面が後半だけなら、最初の読込対象から外す設計も候補になります。

一つの素材に複数の画像がある場合は、色、凹凸、粗さなどの役割を確認します。見た目の判断をファイル名だけで進めず、どこでどの情報が使われるかを整理しましょう。実際には使われていない素材が書き出しや配信に含まれていないかを見ることも、導入前にできる改善です。

2. Three.jsでは変換器と対応確認を準備する

Three.jsのKTX2Loader資料は、Basis Universalのテクスチャを対応するGPU形式へ変換することと、Wasmの変換器とJavaScriptのラッパーを使うことを説明しています。detectSupport(renderer)は読込前に呼ぶ手順です。KTX2という拡張子のすべての中身を無条件に扱えるという想定は置かないようにします。

次は初期化済みのWebGLRendererを使う例です。変換器のファイルも、使っているThree.jsの版と合わせて配信します。画像だけを置き、変換器の配置を忘れると表示まで進めません。読込の失敗は案内できる状態にし、必須の素材がないままゲームを開始しない構成にします。

import { KTX2Loader } from 'three/addons/loaders/KTX2Loader.js';
const loader = new KTX2Loader();
loader.setTranscoderPath('/basis/');
loader.detectSupport(renderer);
const texture = await loader.loadAsync('/assets/ground.ktx2');
// rendererは初期化済みのWebGLRendererを想定。
// /basis/には同じThree.js版の変換器ファイルを配置する。

3. 遠い場所と近い場所で画質を比べる

当ブログの比較案では、同じ素材を元の形式と変換後の形式で表示し、近距離、通常の距離、斜めからの表示を見ます。細い線、透明な縁、繰り返す模様を重点的に確認します。ファイルが小さくなっても、ゲーム内で必要な目印が読めなくなれば採用条件を満たしません。

文字や操作アイコンは、地形の模様と同じ判断だけで変換しないようにします。UIには輪郭の読みやすさが必要で、表示サイズも違います。素材ごとに「少し粗くてもよい装飾」「形を読める必要がある目印」「文字情報」を分けると、画質を下げる対象を選びやすくなります。形式を統一することより、ゲーム上の情報を守ることを優先します。

テクスチャの色空間や透明表示の設定も、比較条件に含めます。圧縮した素材を読み込めても、材質側の設定が変わっていると色の差の原因が分かりにくくなります。見た目を比較する段階では、カメラ、光、材質をそろえ、変換した画像だけを差し替えると判断がしやすくなります。

• 遠景と近景で目印を読めるか
• 斜めの地形で模様がちらつかないか
• 透過した縁が不自然にならないか
• UIの文字や記号を別に確認したか

4. 取得と変換を含めた最初の体験で判断する

転送量が減った場合も、変換器の取得と変換の準備が追加される構成では、最初の表示までを通して比べます。対象端末で初回と再訪を確認し、素材の準備がどの段階にあるかを記録します。形式名だけから全端末での速度を予測せず、自分の作品が使う素材の数と大きさで考えます。

素材予算は「最初の画面で必要」「次の場面までに用意」「まだ取得しない」の三つに分ける案から始められます。これは公式が定める上限ではなく、記事独自の管理方法です。通常画質と軽い画質を作る場合も、両方で勝敗に関わる情報を残します。素材を増やしたときに一覧と確認条件を更新すれば、後半の開発で読み込みが長くなった原因を追いやすくなります。