3d-high-resolution-textures

3D 高解像度テクスチャ

想定される最も近いカメラビューでも、マテリアルの見た目が保たれるようにします。目に見える表面のディテール、マッピングのスケール、配信コストをまとめて指定します。

ビューに応じた解像度を選ぶ

主役となる表面、カメラからの最短距離、投影されるピクセル範囲、目標とするレンダリング解像度を特定します。テクスチャに必要な解像度は、表示される UV の範囲によって決まります。たとえば、表面が物理ピクセル 1200 ピクセル分を占め、タイルの半分が表示される場合、幅が約 2400 ピクセルのタイルが有効な出発点になります。すべてのマップに 4K や 8K を割り当てず、結果を確認してください。

読み取り可能なクローズアップのアルベドや法線ディテールには高解像度を使用し、滑らかな粗さや遠景の表面には、見た目が同等であれば低解像度を使用します。つながった表面間でテクセル密度をそろえます。小さなソースを拡大しても、撮影されたディテールは生み出せません。必要に応じて、より高品質なソースを入手するか、適切なプロシージャルディテールを作成してください。

一貫性のある PBR マテリアルを構築する

マップ	役割	色の解釈
ベースカラー、発光色	表面の色、または発光する色	通常の PNG/JPEG/WebP カラー画像では sRGB
法線、粗さ、メタリック、AO、高さ	数値のマテリアルデータ	色空間変換なし
HDR ライティング画像	環境ライティング用の放射輝度	形式／ローダーのリニア HDR 解釈を使用

ライティング計算はリニア空間で行い、最終出力変換は一度だけ適用します。マテリアルとレンダラーのバージョンに応じてマップを設定してください。Three.js の色管理を参照してください。

動的ライティングを想定する場合、ベースカラーに方向性のあるハイライトを焼き込まないでください。木目は部材の向きに沿わせ、石のスケールは実寸に合わせ、織物の繊維は生地の構造に合わせます。同じマテリアルに属するマップ間で、タイリング変換を共有します。動くライトの下で、接線空間の法線規約と継ぎ目を確認してください。廃止された属性名をそのまま複製せず、使用中のレンダラーでサポートされている AO の UV チャンネルを確認してください。

広い範囲の色変化、中程度のスケールの構造、繊細な微細ディテールを組み合わせます。バンプ／法線の強度は現実的な範囲に保ちます。法線マップとバンプマップはシェーディングを変化させます。シルエットのディテールには、ジオメトリ、または十分な頂点数を持つディスプレイスメントが必要です。木材、石、布は通常、誘電体の表面です。光沢を出すためにメタリック値を上げても、マテリアルの問題は解決しません。

サンプリング時にディテールを保つ

一般的な静的テクスチャでは、ミップマップと適切な縮小フィルタリングを有効にします。斜めから見る床、屋根、木材には異方性フィルタリングを使用し、renderer.capabilities.getMaxAnisotropy()で上限を設定します。どこでも最大値を割り当てるのではなく、中程度の値を比較してください。異方性は斜め方向のサンプリングを改善しますが、ソースにないディテールを補うものではありません。

葉の抜き用テクスチャでは、アトラスのセルに余白を設け、透明テクセルにエッジカラーをにじませ、ミップレベル間でアルファカバレッジを保ちます。明るい空を背景に遠景のカードを確認し、暗い縁や葉の消失がないか調べます。すべてのミップを無条件にしきい値処理しないでください。アルファテストまたはアルファトゥカバレッジに適した方法を選んでください。

詳細を段階的に追加する

• 最初に、開始時のビューに必要なマップを読み込みます。小さくても役立つプレースホルダーや低解像度のバリエーションを使い、その後、画面近くに見えるヒーローサーフェスを、UV スケールやマテリアルの特性を変えずに高品質なものへ切り替えます。
• カメラが到達する少し前に、任意の部屋や詳細ビューをキューに追加します。DOM の loading="lazy" では WebGL のテクスチャリクエストはスケジュールされないため、シーンの表示状態、カメラとの距離、またはチャプターの状態を明示的に使います。
• リクエストを重複排除し、アセットの完全な識別情報とサンプリング／カラー設定に基づいてテクスチャのバリエーションをキャッシュします。衝突する可能性のあるファイル名のサフィックスをキーに使わないでください。
• アセットは外部に置き、キャッシュ可能にします。カラー画像は WebP／AVIF にするとネットワーク転送量を減らせますが、データマップに圧縮アーティファクトがないか確認してください。通常、これらは非圧縮の GPU テクスチャにデコードされます。対応環境では KTX2／Basis によって GPU ストレージも削減できます。トランスコーダーとフォールバックを設定し、動作を検証してください。KTX2Loader を参照してください。
• 置き換えられた GPU テクスチャは、どのマテリアルからも参照されなくなったら破棄します。別々の WebGL コンテキスト間で画像データを再利用しても、GPU メモリの割り当ては共有されません。

フルミップチェーンを持つ 4096² RGBA8 テクスチャは、ドライバーのオーバーヘッドを除いても、GPU ストレージで約 85.3 MiB を使用します。そのため、ダウンロードサイズが小さくても、割り当てサイズは大きくなることがあります。ファイルサイズだけでなく、マテリアルセット全体、デコード済み CPU 画像、同時に行われるアップグレードも考慮して予算を立ててください。

プロシージャルマップでは、必要に応じて安定したアセットを事前にベイクします。共有するノイズ／高さフィールドをキャッシュし、大規模な処理は上限を設けたバッチまたはワーカーで行い、起動時に何百万回もの canvas 描画呼び出しを行わないようにします。非常に大きな同期処理の前後で処理を譲るだけでは、その停止時間を分割できません。

検証する

意図した表示解像度で、近接視点と浅い入射角からのビューを確認し、同じマテリアルをさらに離れた位置から見た場合と比較します。シーム、木目の方向、アルファの縁、法線の向き、中立的なライティングと最終的なライティングの下での色を確認してください。起動時のバイト数と総アセット量を分けて記録し、リクエストされた寸法、推定 GPU メモリ、テクスチャ切り替え時の引っかかり、モバイルでのアセット欠落も記録します。

REFERENCES.md を読んでください。Seijaku では、barUV、assetTex、葉のミップ／ブリードの準備、共有プロシージャルフィールド、チャプターに基づくテクスチャのスケジューリングを確認してください。これらのパターンを見ると、ソース画像の寸法だけではわからないマテリアルのディテールが理解できます。