西川善司の「試験に出るゲームグラフィックス」（8）「人喰いの大鷲トリコ」の「リアルとアートの狭間」はこうして生まれた・後編

　前編から少し間が空いてしまったが，「人喰いの大鷲トリコ」解説の後編をお届けする。


　人喰いの大鷲トリコは，東京ゲームショウ2017の会期に合わせてCESA（コンピュータエンターテインメント協会）が主催した日本ゲーム大賞 2017（JGA2017）において優秀賞を獲得したことで，再び話題に上がった。
　また，2017年12月にはPlayStation VR対応のデモ版が無償公開され，作品の楽しみ方も広がってきている。
　今回は，そんな同作を支える技術のさらなる深淵部を覗いていきたい。

2018年1月に開催された見本市「CES 2018」のソニーブースでは，VR対応デモ版を体験できるようになっていた。写真は体験している筆者。トリコによじ登ったり，頭をなでたりできて，かなり楽しい。無料なのでぜひお試しあれ

　というわけで，本稿ではいきなり「細かなスレッド内訳」の話から始めてみよう。

メモリシステムとスレッドシステム

　人喰いの大鷲トリコはPlayStation 4（以下，PS4）専用タイトルである。これは，「ほかのプラットフォームへ移植することを考慮する必要がない」ことを意味しており，そのため，PS4のハードウェアリソースをフルに使い切るような仕様になっている。
　PS4の場合，メインメモリ容量8GBのうち，システム領域用を除くと，ゲームに使えるのは4.5GB＋αだが，人喰いの大鷲トリコではこれを全部使っているのだ。プログラムとその関連データスペース「CPUメモリ」で約2GB，グラフィックスメモリとテクスチャなどの関連データスペース「GPUメモリ」で約2.8GBというのがその内訳である。

　CPUメモリ側をさらに細かく分類すると，アニメーションシステムとサウンドシステムが約400MBずつ，物理シミュレーションシステムが約256MB，AIシステムとスクリプトシステムが約100MBずつ，動的な頂点データバッファに約128MBといった具合だそうだ（※それ以外はカテゴリに分類できないような“雑用メモリ”なのだろう）。
　「動的な頂点データバッファ」というのは，CPU側でプログラム的に動的生成している頂点データのバッファで，人喰いの大鷲トリコにおいては，プログラムの設計上，CPU側からもGPU側からも同じデータへアクセスする要素があるため，同じ内容のデータをGPUメモリ側でも用意することになる。

　PS4のCPUコア数は8基で，そのうちゲームから使えるのは6.5基分だが，人喰いの大鷲トリコでは使えるすべてのコアを最大7つのワーカースレッドで使い，メインスレッドはワーカースレッド制御のみを行うようにしている。
　前述したアニメーションシステムやサウンドシステム，物理シミュレーションシステムなどといったサブシステムは，これら最大7スレッドによって適宜並列実行される仕様だ。

　人喰いの大鷲トリコのソフトウェアアーキテクチャは，非常にモダンなマルチスレッド対応になっていると言えるだろう。

LoDシステムと影生成システム

　いきなり本連載の主題から少し離れた話をしてしまったが，軌道修正。グラフィックスの話に戻ろう。
　まずは，LoD（Level of Detail）システムからだ。

　広義のLoDは，3Dモデルの詳細度に限ったものではないが，狭義としては，「視点からの距離によって3Dモデルなどの詳細度を適宜切り換える仕組み」のことを指すことが多い。
　ソニー・インタラクティブエンタテインメントのリードプログラマー，井澤 允（いざわまこと）氏によると，人喰いの大鷲トリコにおけるLoDシステムの実装は次のとおりだ。

井澤 允氏（ソニー・インタラクティブエンタテインメント，Worldwide Studios JAPAN Studio，プロダクトデベロップメント部テクノロジーグループ，チーフ）

井澤 允氏：
　「距離ベースで3Dモデルの詳細度を切り換える」という，シンプルな設計を採用しています。切り換えはプレイヤーに気付かれないように気を使ったつもりですが，背景の木々だけは，LoDの切り換えが分かりやすく見えますね。
　LoDモデルは事前生成によるもので，テッセレーションステージなどを使った動的な実装ではありません。


　主人公の少年やトリコはLoDモデルを持たない。一方，背景の木々は4段階，ステージである遺跡自体は遠景と中景，近景の3段階LoDとなっている。

上段が近景用モデルで，下段は左が中景用モデル，右が遠景用モデルとなる。見てのとおり，ポリゴン数や適用されるテクスチャの解像度は近景用モデルが最も高く，種類も多い

　続いて影生成システムはどうか。


井澤 允氏：
　人喰いの大鷲トリコでは，デプスシャドウ技法の基本形にカスケードの拡張を組み合わせた手法を採用しています。


　デプスシャドウ（Depth Shadow）技法は，「光源位置から見たシーンのオブジェクトまでの距離情報をデプスバッファやテクスチャなどへレンダリングしたもの」を生成するので，シャドウマップ（Shadow Maps）技法とも呼ばれる。
　「光源位置から見たシーンのオブジェクトまでの距離情報」は，要するに深度（depth，デプス）情報だ。近代のGPUはこのデプスレンダリングを高速に行えるようになったため，PlayStation 3（以下，PS3）＆Xbox 360時代で一気に主流となった。
　デプスシャドウ技法では，さまざまな改良や拡張も考案されているが，人喰いの大鷲トリコが採用しているのは，最もベーシックな原形技法である。

　実際にピクセルを描画するときは，着目しているピクセル位置から光源までの距離と，先ほどのデプスマップから読み出した当該ピクセル位置に対応するデプス値を比較して，「影か否か」の判定を行う。このあたりの仕組みを図解したのが下の図だ。

デプスシャドウ技法の概念図
出典：『ゲーム制作者になるための3Dグラフィックス技術 増補改訂版』（西川善司著，インプレス刊）

　シャドウマップは近景用から遠景用まで，合計4枚をそれぞれ微妙に重ねながら生成している。井澤氏の言う「カスケード拡張」はこのことを指しており，要するに，人喰いの大鷲トリコはカスケードデプスシャドウ（Cascaded Depth Shadow）を採用しているわけである。

　4枚あるシャドウマップ用のテクスチャ解像度は2048×2048テクセル。近景は主人公である少年の位置（≒視点位置）からおよそ6mくらいまでで，それよりも遠方の十数mまでは2番めのシャドウマップが担当する。
　3番めと4番めの遠方シャドウマップはリアルタイム生成ではなく，事前生成した固定シャドウマップとなっているという。これは，負荷低減のための工夫である。

人喰いの大鷲トリコはカスケードデプスシャドウ技法を採用している。ここで例示しているシーン（左）の場合，ゲーム世界全体のうち，右の図で赤く塗ったエリアに対して，カバー範囲を変えた4段階（＝4枚）のシャドウマップを，近景はリアルタイム，遠景は非リアルタイムで生成する仕様だ。シャドウマップの解像度はすべて2048×2048テクセルとのこと

シャドウマップとは，光源方向から光源照射方向を見たシーンに対してデプス（depth，深度）レンダリングを行ったものである。左上が最近景用のシャドウマップで，右上のものは左上のものと同一解像度ながら，より広範囲をカバーしたシャドウマップで，分解能的に（≒解像度的）には一段下がったものになる。さらに一段ずつカバー範囲を広げた（≒解像度を下げた）シャドウマップが左下，右下と続く

　背景物や動的キャラクターはもちろんのこと，地面に生えている草の1本1本までもが，人喰いの大鷲トリコでは影の生成元となる。ただ，カスケード（cascade，段階）の3番め以降はいま紹介したように固定なので，遠方にある草木の影は風で揺れないことになる。ただ，そんな遠方で地面にある草木の影が揺れる様子などはほとんど見えない。だから「これで問題なし」ということなのだ。

　なお，シャドウマップについて井澤氏は追加で，次のようにも述べている。


井澤 允氏：
　人喰いの大鷲トリコにおけるグラフィックスエンジンの仕様では，さらに4枚のシャドウマップを生成できるようになっています。たとえば窓枠から注ぎ込む陽光や，その他のスポットライトが作り出す影などです。


　人喰いの大鷲トリコにおける煙の表現は，一般的なパーティクルシステムを用いたものだが，各煙パーティクルはその場にある光源からの影響を受けてライティングされる仕様になっている。もわもわとした，煙ならではの立体感を伴った陰影があるのは，ちゃんと法線マップ付きの煙テクスチャがリアルタイムにパーピクセルライティング（Per Pixel Lighting）されているためだ。
　ただ，トリコや地形からの影は，煙パーティクルにもちゃんと投射されるものの，この煙パーティクル自体が周囲の地形に影を落とす処理系は省略されているので，この点は付記しておきたい。

遺跡の影が煙パーティクルに落ちている点に注目。ただし，煙パーティクル自体の影は地面に落ちていないので，ここは処理が省略されていると分かる

　影について続けると，間接光が作り出す淡い影の生成では，近代ゲームグラフィックスにおける定番である，画面座標系の疑似陰影生成テクニックであるスクリーンスペース・アンビエントオクルージョン（Screen Space Ambient Occlusion，以下，SSAO）などが採用されている。

　また，SSAOとは別に，動的キャラクターが背景に対して作り出す近接影（Contact Shadows，コンタクトシャドウ）はCompute Shaderを用いた特別な技法で別途生成しているとのことだ。近接影生成の生成元となる動的キャラクターには，トリコや少年，そして樽などといった一部の背景オブジェクトが含まれるという。

　方法としては，「動的キャラクターの形状をカプセルや球体として扱い，描画対象のピクセルから見た距離を計測して，近ければ影色を付ける」といった，擬似的な実装になっている。Uncharted（アンチャーテッド）シリーズなどが採用しているものとよく似ていているが，ともあれこうした影表現は，屋内などの環境光（＝間接照明）主体のシーンにおける接地感や距離感を演出するのに貢献している。

キャラクターの環境への近接影は，ジョイントカプセルモデル（Joint Capsule Model）を使用した手法が実現されている。この画面ショットは，トリコと少年のジョイントカプセルモデルをワイヤーフレームで可視化したものだ	近接影のみの画面ショット。描画対象ピクセルからジョイントカプセルモデルへの距離に応じて陰影を付与するため，距離的にトリコや少年に近いピクセルほど濃い「陰」が現れていると分かる
完成版の画面ショット。デプスシャドウ技法によるリアルタイム生成シャドウとSSAO，近接影のすべてを適用した状態だ	参考として，近接影を無効化し，リアルタイム生成シャドウとSSAOのみにしたもの。完成版と比べると，トリコや少年と地面との接地感がいまいちだ

物理シミュレーションとアニメーション

　人喰いの大鷲トリコでは，主人公の少年とトリコに対してさまざまな障害が降り掛かる。その障害を，創意と工夫で乗り越えていくアドベンチャー的な謎解きが，ゲームメカニクスの醍醐味となっているわけだが，このかなりの割合を物理シミュレーションが下支えしている。
　その根幹となる物理エンジンは，PS3版として開発していたときはSony Interactive Entertainment内製のものだったが，PS4版として開発することになって以降は「Havok Physics」に変わっている。Havok Physicsは基本的にCPUで実行する実装のエンジンだが，人喰いの大鷲トリコにおいてはどの程度の負荷になっているのだろうか。
　質問してみると，井澤氏からは次のような回答が得られた。


井澤 允氏：
　基本的に30fpsとなるゲームサイクルにおいて，物理には約7msの“予算”を割り振りました。物理担当のエンジニアとゲームデザイナーには，この予算内で処理量が収まるよう設計してもらっています。

高所恐怖症の人だと胆が冷える，やじろべえパズルシーンのひとコマ

　人喰いの大鷲トリコにおけるHavok Physicsの適用先は，トリコが怖がる「やじろべえ/カカシ」のパズルや，「トロッコ押し」のパズル，「石を運ぶ」パズル，「球体檻に閉じ込められた少年が転がる」パズルなど，多方面にわたる。あらためて述べるまでもないだろうが，そうしたオブジェクトの各挙動は，リアルタイムに計算された物理シミュレーションによって制御されているわけだ。
　ただ，一口に「物理シミュレーションによる制御」と言っても，ゲームメカニクスの根幹に物理シミュレーションを適用すると，ゲーム展開としてはむしろ逆に理不尽な結果になったりすることも多いため，このあたりの調整には開発チームも苦労したようだ。

　たとえば，やじろべえ/カカシのパズルだと，シーソーと振り子を組み合わせたような構造物に少年が飛びつき，上ったり下りたりして目標地点まで到達することがひとまずのゴールとなるが，このとき，100％の物理シミュレーション任せにしてしまうと，シーソーや振り子の揺れがなかなか落ち着かなかったりして，プレイ時の爽快感が損なわれることがあったのだとか。


井澤 允氏：
　かといって，物理シミュレーションの挙動を抑え込みすぎると，「リアルタイムにゲーム世界と触れ合っているプレイ感覚」が希薄になってしまいます。物理シミュレーションベースのゲームメカニクス構築は，そのさじ加減が難しいところですね。
　実際の調整は，物理パズルの構成物の物理パラメータを調整することで行うイメージです。たとえば，「パーツが曲がりにくくなるよう剛性を上げる」とか，「大きく回転したり倒れたりしないよう，重心の位置をずらす」とかです。



　人喰いの大鷲トリコでは，物理シミュレーションを事前実行した結果の表現も一部で組み込んでいる。
　具体的には，少年やトリコ，あるいは敵キャラクターの行動などによってゲーム世界が破壊されるケースで，事前計算による物理シミュレーションの結果をトレースさせる場合があるのだ。これはグラフィックスで言うところのプリレンダリングのようなイメージで，激しく割れたり，その割れた破片がバウンドしてさらに分裂破損したりするような表現において，そうした各破片の振る舞いを事前に計算して求めておくということである。
　この事例をゲーム中のシーンからピックアップすると，たとえば「大きな塔が倒れるシーン」や「石橋が崩壊するシーン」のような，大規模な破壊シーンが該当する。


　破壊の途中，前半までが事前計算物理で，後半からリアルタイム物理にスイッチするシーンもあるという。
　井澤 允氏，そして開発会社ジェン・デザインのキャラクターアートディレクターである酒井勇太朗氏（さかいゆうたろう）氏は次のように述べている。


井澤 允氏：
　物語の序盤付近で，トリコの尻尾による電撃で遺跡内の壁が崩壊するシーンがあるのですが，あれは最初が事前計算物理で，途中からリアルタイム物理です。こうすることで，少年やトリコが崩壊したオブジェクトと直接インタラクションする表現を行えるようになり，「このゲーム世界が生きている」感じの説得力を増すことができています。

酒井勇太朗氏（ジェン・デザイン，キャラクターアートディレクター）

酒井勇太朗氏：
　一方，トリコの耳や尾尻などがゲーム世界の壁などといった障害物に衝突した場合は折れたり曲がったりしますが，それらはHavok Physicsのラグドール物理で制御しています。そういうところはリアルタイム処理ですね。


　ラグドール物理というキーワードは，ゲーム関連の技術を追っている人でなくても聞いたことがあるのではなかろうか。銃撃の結果即死したキャラクターの力が抜けて，人形のように倒れたり，あるいはキャラクターが爆風に吹っ飛ばされたりするアレだ。
　ラグドール（Ragdoll，ぬいぐるみ）物理では，仕込まれたボーン同士の接続もしくは拘束条件に従って，当該オブジェクトに対して剛体物理シミュレーションを適用する。適用先のオブジェクトに「自ら動いたり姿勢を維持したりしようとする意思」がなく，外的要因に対して従順に従う物理挙動においては，今でも一般的に利用される技法である。

トリコの身体，一部はラグドール物理によってその動きを制御している。ラグドールでありながら，アニメーションを流し込んでいたり，巨大な生物の部位表現に利用したりするというのはちょっとユニークだ

　人喰いの大鷲トリコでは，少年が巨躯のトリコに飛びついてよじ登ることになる局面が多い。動き回っているトリコの上で少年は歩いたり，さらに高いところへ上っていったりして，そのとき，少年はトリコの動きに振り回されることもあるのだが，この挙動はダイナミックでありながら自然で，実に見事だ。
　実のところ，この「小さき者が，動き回る巨体に物理コンタクトする」というテーマに対して世界で初めて取り組んだのは，ゲーム史に刻まれるべき名作「ワンダと巨像」である。
　2005年にPlayStation 2（以下，PS2）版としてワンダと巨像が登場した頃は，極めて難度の高い技術テーマだったのだが，当時のワンダと巨像開発チームは，「物理シミュレーションから算出された速度ベクトルで，手付け実装された基本モーションを摂動させる仕掛け」を自前で実装していた。

いずれもワンダと巨像より。PS2時代の先進技術である「物理×アニメーション」統合システムはなんと開発チームの自前だった

　当時「物理加算モーション」と呼ばれていたこのテクニックは，本作でも使われているのだろうか。ジェン・デザインのアニメーションディレクター兼リードゲームデザイナーである田中政伸（たなかまさのぶ）氏の回答をお伝えしよう。

田中政伸氏（ジェン・デザイン，リードゲームデザイナー/アニメーションディレクター）

田中政伸氏：
　物理が絡む処理系は基本的にHavok Physicsベースとなりました。ただし，トリコに対して主人公少年が飛びついたりするようなアクション部分は自前のアニメーションシステムによる制御です。
　手でトリコに掴まったら，手をその位置にロックして，そこから先の胴体はHavok Physicsによる制御に切り換えています。


　少年が手で掴まっているときに，振り子のように振り回されているところはHavok Physicsが制御する一方で，両手でしっかり掴んだり，そこから登ったりするところはアニメーションシステムによる動きになる。つまり後者は一種の「それっぽいフェイク」ということだ。
　ちなみに，トリコが激しい動きをしたとき，トリコを掴んでいた手が離れてしまう挙動は，少年の手の位置にかかる速度ベクトルが閾値を超えたときに起こるそうだ。一方，手が離れて落下し，地面に叩きつけられるとき，少年が受け身に近い「自らの身体を衝撃からかばう」動きを見せるが，そちらはHavok Physicsによるものだという。

　こうして見てくると，人喰いの大鷲トリコでは，いわゆる「ゲーム的な処理」と物理シミュレーションとを細かく組み合わせていることがよく分かる。ゲームはプレイしている人が楽しめることが最重要であるため，「体験としてリアル」を感じられれば，その過程でフェイクが混ざっていてもいいのだ。


　各キャラクターの動きは，モーションキャプチャによるものではなく，すべて手付けのアニメーションだ。少年が歩いたり走ったり，立ち止まったり，飛んだりといったアクションは，手付けアニメーションの動きを適宜合成して再生したものになる。たとえば直進よりもやや右にずれる歩行であれば，「直進の割合を多め」「右横歩きの割合を少なめ」にした合成モーションで歩かせるイメージだ。

　また，人喰いの大鷲トリコでは，事前に仕込んだ手付けアニメーションの合成とは別に，プロシージャルアニメーション（Procedural Animation）技術も併用している。
　プロシージャルアニメーションとは，算術合成で生成＆変調されるアニメーションシステムのことだ。もっと具体的な技術キーワードで言えば「フルボディIKシステム」である。

　さらに用語解説を続けると，IKは，Inverse Kinematics（逆方向運動学）のこと。たとえば「気を付け」姿勢の人体があったとして，片足を前方に30cm動かして一歩踏み出す挙動を与えるとき，そこから足首と膝，股関節の曲げ角度を計算して足の曲がり方を逆算出するようなことだ。
　フルボディIKは，これをさらに発展させたもので，「片足を前方に30cm動かして一歩踏み出す」挙動で言うなら，人体骨格の構造が許す範囲で，しかも人体の動きとして不自然に見えない姿勢変化をも伴って足を前に差し出す姿勢を逆算することを指す。

　上で紹介した「トリコの体にしがみついてからのよじ登りモーション」なども，実は，フルボディIKシステムに近い，自前のプロシージャルアニメーションシステムによる制御となっているのである。


田中政伸氏：
　巨大生物であるトリコの挙動は，多くがプロシージャルアニメーションシステムによるものです。トリコの基本的な歩行モーションには，旋回用を除いて，緩やかにカーブするようなものは用意していません。直進状態のものしか用意していないということです。

　トリコは4足歩行ですが，そんなトリコが方向転換をするとき，身体を伸ばし切ったまま車両のように転回したらとても奇妙に見えますよね（笑）。なので，トリコはそんなとき，上半身を転換方向に曲げて曲がっていくわけです。さらに，その足を伸ばした先には段差があれば，その段差に安定接地するよう足を置きますし，盛り上がった場所があればそこに足を置くこともあります。そうなったときに不自然な姿勢とならないよう，身体のほうを統合的に制御するようになっているんです。



　トリコによる周囲の地形認識は，開発チームが「抽象探査」と呼ぶ仕組みで行っているという。
　地形データを抽象化して――平たく言えばローポリゴン化して――衝突するか否かの情報を広範囲で取れる機能を開発チームは作ったそうで，それに問い合わせることにより，トリコの最終的な足の置き場所を決定しているとのことだ。
　具体的なパイプラインとしては，

1. 「どこへ移動する」という行動AIによって意志決定を行う
2. 足を置くことになりそうな場所周辺を，前述した抽象探査でスキャンする
3. 姿勢に無理が起きない範囲内の適切な場所へ，最終的に足を置く

という流れだ。そのため，「トリコが狭い隙間に足を置いてしまって，結果，壁にめり込む」ような事態は生じないのである。

細かい揺れを表現する，連番テクスチャアニメーション

　人喰いの大鷲トリコで，草木などの植物の揺れが従来のゲームグラフィックスよりも少しリアルに見えなかっただろうか。
　最近のゲームグラフィックスにおいて，「背景物の植物を風で揺らす」というのは定番の表現にはなっているが，人喰いの大鷲トリコにおける揺れの表現はよりきめ細かいのだ。一般的なゲームグラフィックスで採用されているような「草木の枝に仕込んだボーンを動かして枝を揺らす」表現ではなく，頂点単位で揺らしているという。
　さらに，葉っぱ1枚1枚を異なる周期でバラバラに動かす表現も入っているのだが，さぞ複雑なのかと思いきや，酒井氏によれば，意外にシンプルな実装になっているとのことだった。


酒井勇太朗氏：
　種明かしすると，いわゆる連番のテクスチャアニメーションです。葉が揺れる動きをパラパラ漫画の要領でテクスチャマップに展開して，ポリゴンに適用する葉のテクスチャを切り換えているだけです。
　この表現は，草木の葉以外だと，主人公の髪の毛を揺らす表現にも適用しています。

　実のところ，このアイデアはディレクターの上田からの発案なんですよ。「ポリゴン単位の揺れ」を超えた密度感を出したいということで，すでにパーティクルで実装されていたものを発展させて，実装してもらいました。

上田氏自らのアイデアで実装された，連番テクスチャで1ポリゴン未満の細かい揺れを表現するアニメーション表現

　連番テクスチャはクラシックな表現手法である。人喰いの大鷲トリコでは，葉っぱサイズのポリゴン板に葉のテクスチャを適用するとき，その葉が傾く動きをテクスチャマップの切り換えアニメーションによって，風に揺れているっぽく見せているだけだ。しかし，「風によってなびく葉々の表現に応用した」アイデア自体はとても面白い。

　テクスチャアニメーションのコマ割りは，表現対象の種類にもよるが，たとえば1コマ128×128テクセルで32コマといった構成になるという。実際には，4096×128テクセルのような帯状のテクスチャマップに展開されているようだが。


　揺れの速度は風のパラメータに応じて変わるような制御になっていて，強い風を受けた場合は激しく動くことになる。いずれにせよ，枝は大きい動きになり，葉は細かく動くので，全体として見るとかなり複雑な動きに見えるのだ。
　少年視点で木々を見上げた場合，これら複雑な枝と葉の動きは木漏れ日の出方にも影響するので，シンプルながらも，人喰いの大鷲トリコが持つ「独特な映像美」への貢献度は高い。


田中政伸氏：
　同じような連番のテクスチャアニメーション表現だと，ほかには「抜け落ちて舞うトリコの羽根」がありますね。トリコに刺さっている槍を抜いたときなど，空中にひらひらと舞う動きがそれです。
　ほかにも煙や水など，ほとんどの連番アニメーションは，上田が自ら「LightWave」（※3DCG開発用ソフトウェア）でレンダリングし，テクスチャのベースとして採用することになりました。リアリティのある動きの素養とレンダリング知識が必要なので，ほかのスタッフにはなかなか難しい部分でしたね。


井澤 允氏：
　少しプログラム的な制御を組み合わせた連番テクスチャの事例としては，「トリコの羽根における血の滲み方」が挙げられます。
　敵に攻撃されるとトリコは出血しますが，その血が羽根に滲んでいく挙動が毎回同じだと不自然でしらけてしまいますから，今回は16種類のバリエーションを用意してあります。この「16種類ある血の滲み方」を連番テクスチャとして管理しているわけです。


　井澤氏が語ってくれた内容は少々特殊な制御を伴うので，補足解説をしておこう。
　氏が言っているのは，「血の滲み方バリエーションを16個用意し，これらを16枚の連番テクスチャに対応させている」ということだ。「血が滲み広がっていくさまを，16枚の連番のテクスチャアニメーションで表現している」わけではない。

　ゲーム内において，実際の滲みは，事前に用意された，地図の等高線のような感じのテクスチャマップで表現される。等高線で言うところの頭頂点（＝頂上部）が「血の起点」，具体的に言えば槍の刺さった場所だ。そして，そこから血が段階的に滲み広がっていくさま（＝形状）を，等高線のようにデザインしたバリエーションを16用意してあるということである。
　描画にあたっては，血の起点からどこまで滲みが広がったかを別途「血の濃さ」的なパラメータで与え，テクスチャマップ上ではこの血の濃さに対応する等高線（＝血の広がり）を血色で描画する流れになる。

トリコの羽根の上に血が滲（にじ）む表現は，そのバリエーションを連番テクスチャで生み出していた。ここで示している画面ショットにおいて，赤青緑の模様のようなものが，段階的な血の広がり方を表した等高線マップ的な存在となる

井澤 允氏：
　この，等高線のような「血の広がり」表現は，フラクタル的なアプローチで事前計算して生成しています。

見えない風の存在を実感させるシステム

　前出の連番テクスチャによる「葉の揺れ」表現は，適当に揺らしているわけではなく，ゲーム世界を吹き荒ぶ「風」によって揺らしている。
　この風は，前出の草木だけでなく，少年の服やトリコの羽根，煙，そしてやじろべえやカカシ，樽といった物理オブジェクトにまで影響を及ぼすグローバルな存在として，ゲーム世界で確かに実在しているのである。
　この点については田中氏が次のように述べている。


田中政伸氏：
　それ自体には姿も形もない風ですが，そこでは大きく分けて2つの仕組みが働いています。1つは空間上で実際に波が押し寄せる仕組みで，これが強い風の担当です。もう1つは「流速」や「向き」「周波数」といった情報を持つ「空気の流れ」として，ノイズを3Dテクスチャ化のうえで実装した仕組みですね。
　これら2つの風を合算した「風ボリューム」がゲーム世界を流れるように制御してありまして，ゲーム世界に存在するあらゆる動的オブジェクトへ干渉するようになっています。



　この風は，ゲーム世界の中を絶えず動いているため，ある風が「少年→トリコ→木々」と通り過ぎた場合，まずは少年の衣服をはためかせ，その後トリコの羽根をなびかせ，最後に木々の葉や枝を揺らすことになる。
　また，トリコの羽根の1枚1枚に摩擦係数のようなものが設定してあって，弱い風では立ち上がらないが，強い風には巻き上げられて立ち上がる制御が組み込んである。それぞれの風は3Dテクスチャベースとなる細かな乱流情報を持っているため，風に煽られたオブジェクトは，大きな風の影響とは別に，「巻き込む」ような挙動も示す。


　反復的なノイズ駆動の頂点シェーダプログラムで動かしているのではなく，見えない立体的な空気の流れが，確かにゲーム世界に存在していることをプレイヤーに感じてもらえるよう，あえてこのような表現にしているのだ。


酒井勇太朗氏：
　動的なキャラクターが風を起こす場合は，この風システムに統合したうえで処理します。少年が走れば，彼の足元には弱い風が発生して，これは周囲の地面から生えている草をちゃんと揺らします。少年がトリコに飛び移ったとき，トリコの羽根が動くのも同様です。


　そうした衝撃によって発生する風は，「球状の風の塊」を，ゲーム内の風システムに対して追加発生させることで実現している。
　トリコがジャンプから着地したときなどは，大きな「球状の風の塊」がトリコの足元に発生し，この風は草木や樽などの障害物をも揺らすことになるのだ。


田中政伸氏：
　トリコはくしゃみをすることがありますが，この衝撃でも風が発生します（笑）。

プロシージャル的な手法を導入して制作された背景

　人喰いの大鷲トリコは，プロデューサー兼ディレクターでもある上田文人氏の独特なアートスタイルによって世界観が構築されているわけだが，過去作である「ICO」やワンダと巨像とも共通する構成要素して，「謎の遺跡」の存在が挙げられる。
　ICOで主人公は同伴するヒロインとともに遺跡の謎に挑むことになっていた。一方のワンダと巨像では，対決する相手の巨像こそが「動く遺跡」的なものだった。その観点で言えば，人喰いの大鷲トリコにおける謎の遺跡は，「インタラクションする機会も多いが，そればかりではない」といった感じなので，ちょうど，過去2作の中間的な存在感といった感じだろうか。

　ただし，過去2作と決定的に異なることがある。それは，人喰いの大鷲トリコにおける遺跡の造形が，上田作品の歴史上，最も緻密に作り込まれている点だ。とくに興味深いのが，経年劣化表現の数々である。

今作の舞台となった遺跡は，経年劣化の表現がリアルである

　石のブロックを積み上げて作られた遺跡は，完成当初，垂直線と水平線が縦横に走る，整然とした景観だったはずだが，そこから何百年も経過したのだということが感じられる。要するに「滅びの表現」がそこかしこに盛り込んであるのだ。
　雨水の影響による石材の浸食表現や，接合部や溝に溜まった土に生える苔など，例を挙げれば枚挙に暇がないが，背景制作や背景レイアウトを担当したソニー・インタラクティブエンタテインメントの栗山立慎（くりやまたつし）氏は，その滅びの表現を「揺れる輪郭」と定義したうえで，次のように述べている。


栗山立慎氏：
　ステージを構築するにあたって，最初から輪郭の表現を行っているわけではありません。
　人喰いの大鷲トリコでは，「Maya」上でレベルデザイン（※ゲーム世界の地形や建造物を配置・設計していく工程）を行っていますが，基本的には，レゴのようなブロックベースでゲーム世界を構築しています。そして，ひとまずの完成状態になったところで，パーリンノイズ（Perlin Noise）による，再現性のあるフラクタルノイズでブロックの位置と回転に揺らぎを与えて，フリーハンドっぽいテイストにしていますね。


　なぜ，最初にブロックベースで構築する必要があるのか。「最初からフリーハンド的にデザインしてしまったほうがいいのでは？」と思う人もいるだろう。
　しかし，これをやってしまうと，地形を構成するジオメトリがすべてユニークな3Dモデルとなって，ゲーム世界内に存在するすべての地形を一から構築しなければならなくなり，制作コストが膨大になってしまう。

　また，一度ユニークな3Dモデルベースのゲーム世界を構築してしまうと，調整のための変更や調整を行いにくいというのもある。
　動的なキャラクターである少年やトリコ，敵などとのインタラクションにおける不都合や，ゲーム展開に合わせた微調整が必要になったとき，作り直しに近い手間が掛かってしまう。その点，一定の品質まで作り込んでおいた地形部品（＝ブロック）をあらかじめ用意しておけば，地形を構築するコストを抑えることができ，かつ一定の品質を保つこともできる。

最初から朽ちた状態でレベル設計を行っているわけではない。制作段階ではこのように，新品ホヤホヤのようなレイアウトとなっている

　というわけで，「起こりうる問題」に効率よく対処できるようにするため，一見まどろっこしくも思える，このような設計工程を採用しているのである。

　もう少し噛み砕いて見ていくことにしよう。
　実際のゲーム世界は，基本的に，小さいものでは一辺50cm程度，大きなものでは一辺が4m〜8mにもなるブロックベースとなっている。大枠としてのレベルデザインをこのブロックベースで行うわけだ。

　その後，フラクタルノイズでブロックの直線的な並びを変調して「揺らぎ」を与える。揺らぎ具合は，ゲーム世界全体へ一括適用するのではなく，ゲーム世界の要所要所に対して，波長や振幅などを細かく自在に変えることができ，かつ，それ自体に再現性があるため，ゲーム世界の更新や変更にかかわらず，何度でも復元して適用できるそうだ。
　このツールは，3DアニメーションツールであるMayaのプラグインとして開発チームが独自開発したもので，チームは「LJツール」と呼んでいるという。LJツールは「Lattice Jitter」の略だそうだ。DCCツール（※Digital Content Creation Tool。Autodesk製などの開発ツール）におけるラティス変形のようなものなので，格子（Lattice）で取り囲まれたオブジェクトを変移（Jitter）させるという意を込めたものだろう。


栗山立慎氏：
　破損表現には，「曲げ破壊」「剪断（せんだん）破壊」があると思いますが，ここで与えられる経年劣化の表現は，どちらかと言えば前者のほうですね。


　空間の揺らぎ計算はすべてMaya上で事前に行ってあり，ランタイム上ではその計算結果である座標データのみを利用している。
　具体的には，「座標変移ノイズ」という形で，空間の揺らぎをMaya上における各ブロックの座標データに適用して，当該座標データをゲーム実行時のランタイムから読み出すことにより，「ゲーム世界を構成する各ブロック」の配置に揺らぎを与えているのだ。
　揺らぎの対象はあくまでもブロック配置情報（＝座標）となるため，ブロック自体の変形は発生しないという。

　なお，LJツールは同時に，背景側の物理シミュレーション用となる衝突判定用形状データも出力できるようになっているそうだ。

左が，モデリングされた遺跡をそのまま描画した画面ショット。右は，左の状態に対し，LJツールを駆使して形状変移させた状態だ

井澤 允氏：
　ゲーム世界をブロックベースで構築してあるため，編集中は壁のパーツ1つ1つを動かすことができます。PS4で描画する最終データに「変形の元情報」は不要ですから，複数のブロックを結合して，より高速に描画できる状態に変換していますね。ブロック同士が重なって見えなくなる部分はポリゴン単位で破棄したり，遠方のモデルは結合範囲を大きくするような最適化処理も行っていたりします。
　ポリゴン単位でモデルを加工する都合上，PS4上での最終的な「ブロックモデルのインスタンス描画」はしていません。

栗山立慎氏：
　すべてではありませんが，自然物の岩石，あるいは接合部の溝に広がる汚れや苔の表現は，ランタイム側のピクセルシェーダで実現していたりします。
　具体的には，汚れや苔のテクスチャレイヤーを露出させるようなシェーディング処理を，当該テクスチャ適用先の面法線や頂点カラー強度などに応じ，プロシージャル的に制御するイメージです。

　地上の植物群のうち，地面から生える草はMayaで動く独自のプラグインツール上で配置していますが，これもプロシージャル的に，草の種類や生える密度，その植生減衰率などを設定してデザインしています。

左が苔・汚れシェーダ適用前。右が苔・汚れシェーダによってプロシージャル生成された最終画面ショットだ。岩肌の見映えの違いに注目してほしい

　栗山氏の発言は補足が必要だろう。
　頂点カラーのRGB（赤緑青）には，テクスチャのブレンド率パラメータが仕込んである。実際にピクセルシェーダがテクスチャを適用するとき，この頂点カラーのRGBに仕込まれたパラメータに応じて，テクスチャの適用の仕方を変調させるイメージだ。

　RGBのRには，地層の模様や汚れなどのテクスチャ適用率，Gには苔や草などのテクスチャ適用率，Bには微細な凹凸表現用法線マップの適用率をそれぞれ仕込んであるとのこと。ここで言う「適用率」は「そのテクスチャをどのくらい強く出力するか」の意味だが，その合成計算の手法はテクスチャの種類によって異なる。たとえば地層の模様や汚れのテクスチャならアルファ合成，法線マップは加算合成といった具合だ。

　このツールで制作した植物の植生データは，「草が生える起点座標」「種類ID」「形状の変調情報」などから構成されるランタイム用データとして出力することになる。そしてランタイムでは，これらの情報を基に，実際に草を描画することになる。
　草をはじめとする樹木，蔦などの植物群は，地形の揺らぎに沿ったインスタンスとして配置してあるという。

上は草木植物の植生データを設定中の画面。下はその植生データに従って生成された草木を伴う最終画面だ

人喰いの大鷲トリコのグラフィックスは「芸が細かい」

　ゲームとしてプレイした場合の人喰いの大鷲トリコは，心に訴えかけてくるストーリーや，微妙に気まぐれで微妙に人なつっこいトリコの振る舞い，探索の奥深さ，作り込まれたアクションパズルといった具合に，多くの魅力的な特徴を持っている。

　それらを下支えしているグラフィックスは，歴代の「上田文人テイスト」の集大成的なものになっているわけだが，作風のポイントはどこにあるのかと言えば，筆者は「芸が細かい」点に尽きると考えている。
　歴史上の著名な建築家や美術史家が「神は細部に宿る」（転じて「美は細部に宿る」とも）と言ったことがあるらしいが，人喰いの大鷲トリコは，まさにこの言葉を体現したタイトルと言えるのではなかろうか。


　上田文人氏は，2011年にSIEを離れ，現在は独立系ゲームスタジオのジェン・デザインを率いて，次回作を構想中とされる。再び「細部に宿った美」で我々を楽しませてくれる日が来ることを楽しみに待ちたい。

人喰いの大鷲トリコ公式Webページ