Web Pixelizer

Web Pixelizerは、Three.jsとReactで構築された3Dピクセルアートレンダリングツール。任意の3Dシーンやモデルを読み込み、リアルタイムでレトロゲーム風のピクセルアートに変換する。GameBoyやPICO-8、Famicubeといった往年のゲーム機・ゲームエンジンのカラーパレットを適用でき、ピクセルサイズやエッジの太さ、ディザリングの強さまで細かく調整できる。

このツールは『A-Z House』というアートインスタレーションプロジェクトのためのビジュアル検証ツールとして作られた。Houdiniで制作した3Dモデルをブラウザ上に持ち込み、ピクセルアート化した見え方をリアルタイムに確認したかった。チームメンバーに共有するにも、Webベースなら環境を問わずブラウザさえあれば確認できるし、『A-Z House』もウェブベースのプロジェクトであるため、ビジュアルのためのパラメータの共有ができると考えた。

開発はほぼ一人で行い、Claude Codeなどのコーディングツールを積極的に活用した。『A-Z House』向けのツールとしてはすでに一区切りがついており、今後はGUIや機能を整理して一般公開する可能性もあるかもしれない。

主要技術スタック

プロジェクトの核となる技術は以下の通り。

• React Three Fiber — ReactのコンポーネントモデルでThree.jsのシーンを宣言的に構築する
• カスタムGLSLシェーダー — ピクセルアートエフェクトの心臓部。深度バッファと法線バッファを使ったエッジ検出、Bayerマトリクスによるディザリング、カラーパレットによる色の量子化を一つのフラグメントシェーダーで実現
• Tweakpane — リアルタイムでパラメータを調整するUI。シェーダーのパラメータを即座に変更でき、試行錯誤のサイクルを高速化する

開発者の背景

このツールを開発した堀川は、普段HoudinやUnityなどを使った3DCGの制作・開発を主としている。Webフロントエンド開発は案件ベースで多少の経験はあったが、メインの領域ではない。

このプロジェクトでReact + Three.js（React Three Fiber）という技術スタックを選択したのは、大元の『A-Z House』がWebベースであることが大きい。またビジュアル検証ツールとしてチームに共有する際、「このURLを開いてください」の一言で済むのが重要であった。

ピクセルアート化の設計思想

「3Dシーンをピクセルアート風に見せる」という課題に対して、Web Pixelizerではポストプロセッシング方式を採用した。シーン内のジオメトリ自体はそのままに、レンダリング結果に対してカスタムシェーダーでエフェクトをかけるというアプローチ。

まずは既存のピクセルアートシェーダーの事例をリサーチするところから始めて、そこから試行錯誤を繰り返しながら独自の組み合わせにたどり着いている。

シェーダーパイプラインは、大きく4つのステージで構成されている。

1. ピクセル化 — UV座標を任意のグリッドサイズに量子化して、解像度を意図的に落とす。これがピクセルアートの「粒」を生む。getPixelatedUV()関数で統一的に処理していて、後続のすべてのエフェクトがこのグリッドに沿って動作する。

2. エッジ検出 — 深度バッファと法線バッファの両方を参照して、オブジェクトの輪郭を検出する。深度差による輪郭と法線差による輪郭を組み合わせることで、3Dの奥行きを持った「線画」感が生まれる。閾値は個別に調整できるので、太い力強い線から繊細な細線まで表現の幅が広い。

3. カラー量子化（パレット適用） — レンダリング結果の各ピクセルの色を、選択されたカラーパレットの中で最も近い色に置き換える。輝度ベースとカラーベースの二つのマッチングモードがあって、パレットによって使い分けている。

4. ディザリング — Bayerマトリクスを使った組織的ディザリング。限られた色数でも滑らかなグラデーションを表現するための古典的な技法で、レトロゲームの雰囲気を決定的に高めてくれる。

カラーパレットへのこだわり

7つのプリセットパレットを用意しているけれど、その選定にはそれなりのこだわりがある。GameBoy、PICO-8、Famicubeなど、いずれもレトロゲームを彷彿とさせるものを選んでいる。これはあくまで開発者である堀川の趣味。

GLBモデル読み込みとHoudiniワークフロー

『A-Z House』は、Houdiniなどで作成した3DモデルをGLB形式で書き出して、ブラウザ上で読み込む運用を想定して設計している。GLBファイルにはカメラ情報も埋め込めるので、Houdiniで設定した構図がそのままWeb上で再現される。

ただし、このワークフローには苦労した点もあった。

特に手こずったのが、透明マテリアルを持つオブジェクトのGLB書き出し。Houdini側でアルファ付きのマテリアルを設定しても、GLBへのエクスポート時に透明情報がうまく引き継がれないケースがあって、原因の特定と回避策の確立にかなりの時間を費やした。

また、シェーダーのチューニングも大きな課題だった。ピクセルサイズ、エッジ検出の閾値、ディザリングの強さ — これらのパラメータは相互に影響し合っていて、一つを変えると全体のバランスが崩れることがある。Tweakpaneによるリアルタイム調整がなければ、この探索プロセスは格段に辛いものになっていたと思う。

フライスルー・ウォークモードの導入

『A-Z House』にはフライスルーモード（Fキーで切り替え、WASD+マウスで移動・視点操作）とウォークモード（物理シミュレーション付き）を実装している。

この機能を入れた理由は二つで、一つは、『A-Z House』のインスタレーションで実際に空間を歩き回る体験を提供するため。もう一つは、シーンを様々な角度から確認するデバッグ・検証用途。

結果的に、この「歩き回れる」機能はツールの実用性を大きく高めてくれた。固定カメラでは見えなかった破綻や、意図せず美しい構図が見つかることもある。デバッグのために入れた機能が、表現の発見につながるのは面白い。

3Dが2Dに見えたとき

開発中で一番良かったのは、3次元の形状が2Dアートっぽくちゃんと見えたとき。特にピクセルサイズを大きくしてlow resolutionにしたときに顕著だった。

3Dの情報量を減らすと、かえっていい感じの絵になる。解像度を落として、色数を減らして、エッジを強調すると、普通に考えれば劣化なのにレトロゲームっぽい良さが出てくる。

マルチシーン管理

最初はシンプルな単一シーンのビューアだったが、開発を進めるうちにマルチシーン管理ができるようになった。シーンごとに異なるGLBモデル、パラメータ、カメラ構成を保持できて、JSON形式でエクスポート・インポートもできるようにしている。

A-Z Houseの複数の空間をそれぞれ別の設定で管理して、チーム内で設定を共有する必要があったので、自然とそうなった。

今後

『A-Z House』向けのツールとしてはもう役目を果たしている。GUIや機能を整理して一般公開することはあり得るかもしれない。3Dモデルをピクセルアート風に変換したい人にとって、ブラウザで手軽に使えるツールというのはそれなりに需要がありそうな気がしている。

エッジ検出：深度と法線は補完関係

シェーダーを書いてみて一番わかったのは、深度ベースと法線ベースのエッジ検出がそれぞれ違う役割を持っているということ。

深度ベースは、手前と奥のオブジェクトの境界、つまりアウトラインを描くのが得意。ただ、オブジェクトの背後に別のオブジェクトが近い距離にあると、しきい値によってはアウトラインが出ないことがある。深度差が足りないのが理由。

法線ベースはインナーエッジ（面の折り目や角）を拾うのが得意で、立方体の稜線とか、曲面が急に向きを変える箇所を捉えてくれる。でも、球体みたいに法線が連続的に変化する形状だと、アウトライン自体が取れない。

要するに、深度がアウトライン担当で法線がインナーエッジ担当。どっちか片方だけだと不十分で、両方組み合わせて初めてちゃんとした線が出る。理屈としては知っていたけれど、実際にパラメータをいじりながら目で確認して初めて実感できた。

パラメータは独立していない

ピクセルサイズ、エッジの太さ、ディザリング強度、カラーパレットの色数。これらは一見別々のパラメータに見えるけれど、実際にはかなり影響し合っている。

例えば、ピクセルサイズを大きくするとエッジの相対的な太さが変わる。同じ閾値でもピクセルが粗いと線が太く見えるし、細かいと繊細になる。ディザリングの効果もピクセルサイズと色数の組み合わせで全然変わったりする。

Webベースの共有のしやすさ

以前はHoudiniで作ったツールをチーム内で共有していたけれど、ライセンスやバージョン、環境構築が前提になる。Webなら URLを送るだけで済むのが楽。特にエンジニア以外のメンバーとビジュアルを確認し合うような場面では、この違いは大きい。