要点： 私たちは Unreal Engine 向けの水システムを、二つの約束とともに作っています。正しく見える水（なぜなら 光・色・泡が物理的に計算されるからで、シーンごとに手でチューニングされるのではありません）、そして ふるまう 水： 任意のメッシュを水面に落とすと、セットアップゼロで正しく浮き、傾き、沈みます。現在、活発に開発中です。この記事は、 それが何をカバーするか、参照写真でどう自分たちを律するか、なぜ浮力が皆が飛ばす難所なのか、そしてツールキットの 残りの隣でどこに収まるかを説明します。
超えるべき基準。これを本物たらしめているものに注目を：砕ける波から生まれた泡、崖を食むかすみ、うねり全体に わたる白波の統計。どれも手で配置されておらず、すべて物理。これが私たちの設定したハードルです。
なぜまた別の水システムを？
ほとんどのゲームの水は、ちょうど一つの照明条件でだけ素晴らしく見えます。ストアのスクリーンショット のそれです。太陽を動かし、曇天に切り替え、カメラを水線の半分下に置いてみれば、崩れます。
同じくらい重要な、より静かな失敗がもう一つあります：ほぼすべての水システムが、浮くオブジェクトを後付けの発想として 扱います。ボートのテンプレート、ポンツーンのリギング手順が一ページ、そして「誰もランダムな木箱を海に投げ込みはし まい」という言外の仮定が手に入ります。プレイヤーは絶えず海に木箱を投げ込みます。
私たちは、現在ひとつのパッケージに共存していない二つを欲しました：どんな 照明も生き延びる映画品質の見た目と、 一切 セットアップのいらない物理的なふるまい。どちらも、スクリーンショットがきれいに見えるまでパラメーターを いじって達成できるものではありません。スクリーンショットは単一の太陽の下の一枚のフレームであり、どちらかが変わった 瞬間、好みでチューニングされた水はその継ぎ目を見せるからです。だからこのプロジェクトの土台は機能リストではありません。 人間が言い争えない受け入れテストです：一枚の写真。
好みではなく、写真に照らして判定される
開発は、固定のカメラ・照明契約をもつ参照写真によってゲートされます。物理的な光の単位、固定された トーンマッパー、そして合否を決める知覚的差分メトリクスであって、その日のアートディレクターの気分ではありません。
二つの参照が正典であり、それらは対極になるよう選ばれました：
- 澄んだ湖、カメラは水線の中。 半分は空気、半分は水、アーティファクトの帯のない波打つ境界；距離とともに色が 深まる緑がかった沿岸型の水；上の水面と一致する岩のコースティクス；界面で正しく屈折する沈んだ丸太。これは屈折、 水線の横断、水中の色吸収を一度に試します。
- 完全な曇天の下の嵐の海岸。 太陽なし、きらめきの帯なし。海は柔らかな空の反射、彩度を落とした灰緑、白波の統計、 そして崖にかかるかすみを通して読まれねばなりません。ブイは信じられる周期と傾きでうねりに乗ります；静止画は判定の一部にすぎず、ふるまいもまた問われます。
曇天の参照は意図的に二つのうちの一つです。日の当たる水は地球上のあらゆるレンダラーをおだてます。スペキュラーの きらめきが数多の罪を隠すのです。太陽を取り去れば、水は反射の粗さと色と動きだけでフレームを担わねばなりません。 それが正直なテストであり、ほとんどのシステムがこっそり避けるものです。日差しでだけ良く見える海は出荷されません。
カメラ側は水側と同じくらい厳格に指定されます。写真比較は、カメラがずるをできないときにだけ公正だからです。それは、 本物の物理的な光の強度（恣意的な明るさスライダーではなく、真昼の太陽で 10 万ルクス前後）、固定の露出、そして参照ごとの 固定のトーンマッピングとブルーム構成を意味します。トーンマッパーを変えれば、どんな水もどんな写真にも合わせられます 。だからこそトーンマッパーは最初に釘付けにされます。
Drop-a-Mesh：宿題なしで浮かべる
任意のメッシュを Numivo の水体にドラッグすると、即座に正しくふるまいます。システムは自動的に物理 プロキシを構築し、実際の波の高さから毎フレーム排除体積を計算し、実際の密度から浮くか沈むかを導きます。
水中はポストプロセスではなく、ひとつの場所です。色は深さとともに吸収され、光は柱となって降り注ぎ、頭上の界面は きれいに横断されねばなりません。湖の参照は、この三つを一度に正直に保つために存在します。
丸太が浮き、長い側へ転がります。木箱が揺れます。石像が沈みます。リギングなし、ポンツーンの配置なし、スクリプトなし。 ボンネットの下では：
- 衝突形状は、オブジェクトの実体積を測るために 自動でボクセル化されます。非同期で、アセットごとにキャッシュ されるので一度だけ起こります；
- 浮力は毎フレーム物理的に計算されます：排除体積を水の密度に対して。淡水と塩水は本当に異なります（塩水はより 密なので、同じ木箱が湖より海で高く乗ります）；
- 浮くか沈むかは密度から、質量を割るプロキシ体積。デフォルトで「これは浮くべきか？」のチェックボックスはあり ません。デフォルト こそ が物理だからです；
- 安定性は現れます：プロキシの体積がどう分布するかから。上が重い木箱は転覆し、竜骨に重りのある船体は自ら立ち 直り、板は平らに横たわります；
- 浮くオブジェクトは 水面に逆結合します。さざ波、航跡、水線の泡のリング、そして衝突時のしぶきエフェクト。
アクターにはオーバーライド用の小さなパネルがあります（強制的に浮かせる、強制的に沈める、減衰スライダー、航跡と しぶきのトグル）、ですが、オーバーライドは物理を置き換えるのではなく 物理をスケールします。岩塊を強制的に浮かせても、 それでも正しい周期で揺れ、正しい航跡を残します；ただ軽いかのようにふるまうだけです。この区別が肝心です：ソルバーを 無視した強制結果は、平面に貼りつけたプロップのように見え、プレイヤーは即座に気づきます。
設計目標はあけすけで、それはライブで走らせられるようにしたいデモです：誰かが二十個のランダムなプロップを海にドラッグ すると、すべてがただふるまう。先に設定ウィンドウを一つも開かずに。そのデモにチュートリアルが要るなら、その機能は 失敗です。
何をカバーするか
沿岸の水、外洋、水中、洞窟の池はどれも一級です。うねりとクロスシーが別々のスペクトルベースの波、 実際に砕ける波からの泡、水中の光柱を駆動するコースティクス、そして映画的エフェクト下での安定性。
水を気にかけるなら重要な詳細：
- 波は海洋学的スペクトルから来ます（実際の海を記述するのに使われるのと同じ統計モデル）、指向性の広がりと独立に 制御可能なうねりを伴って。海況は天気の判断になります（「高まる嵐、西からの長いうねり」）、嵐っぽく見えるまでつつく 三十個のばらばらのスライダーではなく。
- 泡は塗ったマスクではありません。 波が実際に砕ける場所で生まれ、時とともに古び、風下に筋を引きます。塗った泡は 偽物の水の最もよくある証です。表すはずの物理とともに動かないからです。
- 水中は本物の場所です。 深さによる正しい色吸収（赤が最初に、次に緑が去り、ダイビング映像で誰もが知る深い青を残す）、 底を照らすのと同じコースティック場から導かれる光柱、そして古典的な硬いアーティファクトの帯なしの水線での横断。
- 洞窟の池 は独自の扱いを受けます（静止したか、ほとんど動かない水、しずくの乱れ、ほぼ暗闇の中の反射）、なぜなら 穏やかな内部の池は外洋とは異なる失敗を露わにするからです。
- シネマティクは受け入れ基準であって、後付けではありません。 水面は被写界深度、モーションブラー、フィルムグレインの 下で安定を保たねばなりません。グレインを適用して初めて現れるスペキュラーの fireflies なし、遅いカメラがストロボに 変えるちらつきなし。
なぜ浮力は皆が飛ばす部分なのか
見た目は良いシェーダーで偽れますが、ふるまいは偽れません。説得力ある浮き沈みには、リアルタイムの 体積推定と安定したソルバーが要り、これは本当に難しいので、ほとんどのシステムはボートのプレハブを出して止まります。
不都合なエンジニアリングの真実は、美しい水シェーダーは解かれた問題であり、汎用の浮力ソルバーはそうでないということ です。波の見た目を偽るのはテクスチャと法線の問題；任意の、見たこともないメッシュをその波に正しく座らせるのは、 フレームレートで走り、速い時間ステップを生き延び、千三角形の岩が嵐のうねりに出会ったときに破綻しないでいなければ ならない物理の問題です。そのギャップこそ、ほとんどのエンジンで「水」が「相互作用できないきれいな平面」を意味し、 相互作用する部分が、存在するなら、手作りのボートである理由です。
そのギャップを閉じること（ふるまいを見た目と同じくらい自動にすること）、がこのプロジェクトの存在理由であり、週末の シェーダー作業ではなく、参照写真の規律プラス本物のソルバーを要する理由です。
いつ使えるのか？
Unreal Engine の拡張として開発中で、段階的な展開です。キネマティックな浮遊プレビューが完全な物理 ソルバーより先に届くので、シーンを早く populate できます。日付は発表しません；いつ完成かは参照画像が決めます。
段階分けは意図的です。キネマティックなプレビュー（オブジェクトが完全な力シミュレーションなしで波面に追従）が最初に 来るので、重いソルバーがまだ堅牢化されている間にアーティストはメッシュを落として海を populate できます。物理が最終 になるずっと前に結果を感じられます。完全なソルバー、オートプロキシ、完全なパネルが続きます。進捗とマイルストーンは 公開ロードマップに現れ、ローンチ当日のサプライズにはなりません。
それと並んで出荷されるツールキット（スキャッター、メッシュブレンディング、グリッド、計測）、は今日、無料で試せます。 公開の水ビルドが存在した瞬間に通知が欲しいなら、サイトからリンクされた Discord が最初に告知される場所であり、参照 画像の合否比較が起きるたびに投稿される場所です。
ミニ FAQ
Numivo の他のツールを必要としますか？ いいえ。同じファミリーの拡張で、単独で立つよう設計されています。ただし同じ 原則を共有します：結果は物理的に可能な限りエンジンネイティブなデータにベイクされるので、あなたが作ったものはあなたの ものです。
どのエンジンバージョン？ 現行の Unreal Engine 5 リリース。詳細は、拡張が公開ビルドに近づくにつれてロードマップに 着地します。今約束して後で改訂するのではなく。
エンジン組み込みの水とどう違う？ 組み込みの水システムは見た目に強く、汎用の相互作用に弱い。浮力は通常、別個の、 手でチューニングされたコンポーネントです。ここでの要点全体は、見た目とふるまいが単一の物理的に根拠づけられたシステム から来ることであり、参照写真のゲートが照明を横断して見た目を正直に保つことです。
なぜリリース前に発表するのか？ 参照写真の手法それ自体が要点だからです。誰も精査できない完成品を明かすより、 ハードルを公に見せてそれで測られるほうを選びます。この記事がそのハードルであり、書き記されたもの。私たちをそれで 問い詰めてください。
