『Around The World』開発レポート：天候・大気表現の改善と実装

プレリリース段階での進捗概観

• シリーズ告知: 本作は航海による冒険と発見をテーマとしたゲームで、現在は**プレリリース（初期開発）**段階にあります。
• 前回の成果: ゲーム内の雲の「実用的な見た目」を整えることに成功しました。
• 現状課題: プレイテストを経て、海・空・雲が一体となった全体の描写に対して依然として満足感を持てない部分がありました。
• 今回の方針: いくつかの細かい調整を加え、状況を著しく改善してきました。

---

1. 雲における光の散乱の実験

POV-Ray の限界と自作実装

• 背景事情: 前回の投稿で導入したルックアップテーブル（LUT）に対して疑問を抱きました。「POV-Ray は実際には多重散乱をシミュレートしていないのではないか？」という疑念がありました。
• 試行錯誤: ドキュメントに明確な答えがなく、パラメータ調整でも解決しないため、一時的に自制しました。しかし最終的に好奇心が勝り、数百行の Rust コードで自作の再帰型モンテカルロ・レイトレーサーを実装しました。
  • 実装の特徴: 極めて単純化されており、ハードコーディングされた均一密度の球形雲のみをレンダリング可能ですが、検証には十分でした。

多重散乱による画質変化

• LUT の形状変化: 多重散乱を考慮すると、従来の LUT と全く異なる形状になります（パラメータのスケーリング調整済み）。
  • 結論: 雲から出る光ははるかに均一に分布し、結果として雲全体がより明るく見えます。
• 密度による違い:
  • 薄い雲（低密度）: 差が顕著ではありません。光子が 1 回以上散乱する機会自体が少ないためです。
  • 厚い雲（高密度）: 従来の LUT では底部が暗く「金属的」な見え方でしたが、新しいアプローチでは底部が明るくなり照明全体が滑らかになりました。

「ある奇妙なトリック」による色彩調整

• 目的: 雲は太陽からの直接光だけでなく、空からの**間接光（散乱光）**も受けます。この光は青色系なので、雲にはより青みがかった色合いを加える必要があります。
• 課題: 「青色」を単純に足す定数を入れることは避けたいです。なぜなら、日出・日没・夜間など空の色が変化する環境でも適応させなければならないからです。

法線ベクトルによる解決策

Godot エンジンの光のレンダリング仕組みを活用し、以下のアプローチで実現しました。

• 原理: 間接光はキューブマップからサンプリングされます。雲表面に当たるときの法線方向に合わせてその値を調べるのが自然です。
  • 調整前: 雲の底部の法線は地面に向いており、間接光がほとんど含まれていませんでした。
  • 調整後: 法線を空側へ向かせるように調整しました。

視覚的な改善効果

• 昼間の状態:
  • 調整前: 無機質な質感。
  • 調整後: 青みがかった色調が加わり、空と調和し、柔らかく遠近感のある見た目になりました。
• 日没時の状態:
  • 調整前: 底部はオレンジ色がかったトーン（強いレイリー散乱による直接光の影響）。
  • 調整後: 雲全体がピンク色に変化！
  • 理由: 赤（直接太陽光）と青（間接的な空の色）が混ざり合い、緑チャンネルがやや失われる形で生成された現実的な表現です。

---

2. 大気散乱の不自然な黄色の解消

問題点：地平線付近の黄色化

• 現象: 太陽高度が低くない（真上にある）にもかかわらず、地平線付近の空が不自然な黄色に染まってしまうことがあります。
• 原因仮説: レイトマーチングにおいて、外側への散乱（outscattering）が強すぎて、内側への散乱（inscattering）とのバランスが崩れていた可能性があります。

解決策：操作順序の反転

フェイク多重内散乱項などのハックを試みましたが、より優れた解決策を見出しました：レイトマーチ中の操作順序を反転させることです。

ステップ	元の実装順序	新規実装順序（改善後）
1	レイトセグメントに青みを散乱させて加算	レイトセグメント上で外側散乱で減衰（赤味が増す）
2	レイトセグメント上で外側散乱で減衰	レイトセグメントに青みを散乱させて加算

• 効果: 内側散乱に対する減衰量が相対的に少なくなり、視覚的な効果が大幅に改善されました。
  • 理論的には積分ステップ数を増やせば差がなくなるはずですが、実際には依然としてわずかな不備が残っています。現在はこの方法で十分機能しています。

---

3. 地平線の曲がり方調整

惑星パラメータとの不一致

• 背景: リアルな空をレンダリングするには地球のパラメータ（密度・高度など）が必要です。しかし、本作のゲーム内惑星は地球の約 75 倍小さく、曲率が強いです。
• 問題: 地球のパラメータをそのまま使うと、実際の地平線よりも上空に見えてしまう問題が発生します。
  • 特に日没や日出の際に、暗い帯として際立ってしまいます（シェーダーが大気密度が惑星中心に向かって指数関数的に増加していると勘違いしているため）。

シンプルなハックによる解決

• 手法: 空シェーダーに対して以下の処理を追加しました。
  1. グローバルビューベクトルのY 成分（垂直）に小さな値を加える。
  2. さらに再度正規化する。
• 結果:
  • 全体的に空が引き下げられ、特に地平線付近で強く効果が出ます。
  • 暗い帯は実際の地平線の背後に隠れ、視覚的な問題が解消されました。
  • コストをかけずに有効な解決策です。

---

4. トーンマッピングのチューニング

HDR レンダリングと表示の課題

• 背景: ゲームは HDR でレンダリングされることが多く、カラー値が 1.0 を超えます。これを通常のモニター（LDR）に表示するにはクリップが必要で、オーバーサチュレーションを引き起こします。
• 一般的な解決策: HDR 値を LDR スペースに戻すためのトーンマッピング関数を使用します。

Godot での選択基準

Godot は複数のトーンマッパーを実装していますが、以下の理由から特定の設定を選定しました：

• Reinhard: 暗くなりすぎるため不適。
• ACES / AgX: 色が薄くなりすぎるため不適。
• 最終採用: Filmic トーンマッパー（白点を 2.0 に設定）。

採用理由と効果

• 雲に柔らかい印象を与え、遠近感の表現も大幅に改善されました。
• Godot が推奨する「フォトリアリズムを得るための白点 6.0」を使うと全体的に暗くなりすぎるため、妥協案として 2.0 を採用しています（微妙な判断ですが）。

チューニングの難しさ

トーンマッピングは他の要素と密接に関連しており、以下の点を注意する必要があります：

• トーンマッパーを変更すると、それ以前に行われたすべての影響を受けます。
• 線形に進むプロセスではなく、トーンマッパーとシーンの照明の間で何度も行き来する必要があります。
  • 例：空の明るさを literal に 2 倍減らすだけで、トーンマッピング後のコントラストが格段に良くなりました。

---

5. オーラリーを用いた昼夜サイクルの実装

システム概要

• 目標: 太陽の昇り沈み、場所や季節による日の出・日没時刻の変化、満ち欠けなどを再現します。
• アプローチ: 複雑な数学計算を行うのではなく、オーラリー（惑星の公転・自転をモデル化したシステム）内で全体を回転させることで実現しました。

実装フロー

1. 物理演算: エンジン内で惑星と衛星がオーラリーのように回転します。
2. 逆変換: エンジンから、特定の観測者（地表の位置）に対して空上の天体の位置を決定するように計算を任せています。

結果と活用法

• 成果: 良好な昼夜サイクルと天体位置が得られました。
• 副産物: レンダリングされたオーラリー自体が、デバッグ用の有効なツールとなりました。
• 今後の予定:
  • 日の出の動画配信の検討。
  • 魅力的なゲーム内ロケーションの撮影計画。