■ CEDEC一日目 自分用メモ 
物語は混沌とした経験を秩序化していく
テーブルトークに最も重要なのは、サイコロ。自分固有の経験。
自分がその子参加している実感を与えたのは、サイコロだ。
経験というのはカオス、全て偶然。ありとあらゆる物事を突き詰めていくと、偶然起こった。
人間は皆、未知の出来事が起き続ける、次にどうなるかわからないと思っている。
人間は偶然を、最も大事にする、興味を持つ。
偶然に起こっている事を解明しようと言う欲求がある。
自分というサイコロを降り続けるのが人間の生活様式であり、生きる実感を与えている
※サイコロ降り続けないとダメだよね
偶然起こった出来事から、人間は秩序だった必然を見出していく。その行為自体が人生の実感を与える
ゲームをプレイしているという実感を与える
あるプレイでクリアできなかったのが、違うプレイでクリアできた、というのがゲームをプレイしているという実感を与える
※物語を自動生成するゲーム作れないかな？一回まじめに考えてみたい。
※小説家がどんなことをかんがえているのか？
物語のあり方、だれが、何の為に、どういう人を対象に、どんな事を書いているのか、を幅広く。
広いバックグラウンドと深い知識をベースに小説が書かれる。
ドラえもんは何の物語か？
主人公やテーマを決めない物語が一番バリエーションを作りやすい
すべて偶然の出来事で起こっているにもかかわらず、それがストーリーとして意味をなしている、そんなものを作れるのか？
「あなたは偉い」「あなたは悪い」と提示する形の二人称的なストーリーテリングは、ゲームでしか発展していない
※個人のホームページが主流だった時代に2chがはじめて出た時に感じた、「自分に興味のあるものを見るだけでも、自分が読める速度より早い勢いで情報が増えていく」という感覚。
ビジュアルから要素をはぎ取って本質を残すのでなく、
そこに在るものに全て意味を持たせて、その意味を統合していく、文字を作っているのと同じ
スティーブンキングや隆慶一郎を模写した。１０回くらい模写したて、言葉を自分にしみ込ませた。
技術力をつけるため。
●Live Cording in C++
質疑応答：
プロセスの全スレッドを止めて、更新して、再実行
関数自体の先頭5バイトを破壊的に書き換えて実装、ホットパッチには頼っていない
64bitの時は専用の14バイトくらいの命令に置き換えている、先頭5バイトを書き換えて、14バイトのジャンプ関数に飛んでいる
スレッドの再生には非対応
DLLインジェクションは32bitと64bitで別個に対応、注入する側も32bitと64bitを用意している
ゲリラゲームズ、社員数200名
テックチームサイズ：10名
4.5GB ラージメモりモード、750MBのデバッグ領域
ヒープ、アロケーションサイズ最大512KB、メールを送って用途に合わない使い方を指摘
ヒープサイズは430MB(出荷時、出荷前はラージメモリモードでもっと大きく、デバッグデータを入れてた)
メモリプールは断片化する、デバッグツールなどでビジュアライズしている
コールスタックの32bitハッシュを使ってる
1MBを32*32グリッドにしていて、各ピクセル1倍とでビジュアライズ。全体としてどこにフラグメンテーションがあるのかを見られる
レンダーターゲット 380MB
レンダーターゲットを手作業で共有してる、その方がいい結果が得られるから
前のフレームのバッファを残しているので容量が大きい
レンダーターゲとｔでバッグツール、登録されているターゲットをクリックで見れる、ピクセル情報やズームもできる。
→リアルタイム簡易Pix
※メモリビューと簡易PixはUIが素敵っぽかった。これはいい。
スクラッチバッファ16MB、フラグメンテーション槍０区が起こらない
アセットメモりプール
3.6GB
CPUデータとGPUデータに分かれて、デフラグメンテーションを連続的に行ってる
130GB/sec(理論値192GB)、簡単なコンピュートシェーダーでメモりコピー、
1frm12MBずつ動かしている
基本はバブルアップ、全く同じサイズがあれば、そこにはめ込む。(同一サイズのテクスチャなど)
スタティックデータは前検索、ダイナミックデータは後ろ検索
すべてのアロケーションはバックグラウンドスレッドで。GPUの移動もある（実際には1から2frm）
テクスチャストリーミング
ほとんどのテクスチャは2K、
一つのレベルッセクションでは6GB
最接近した時のみ一番解像度の高いテクスチャが読まれる
GPUの描画結果から、期待ミップレベルと描画ピクセル数を取得してる？
全てのレベルセクションに関して、6方向にレンダリングして全てのミップスタッとを事前計算
バウンディングボックス単位で記録しておく
全てのステージを見ると30時間かかった
圧縮すると200KB/レベルセクション
パーティクルシステムでパーリンの伊豆を追加
ライトがレンダリングされる前に、1/8の16スライスのパーティクルをバッファに書いておく
ボリューメトリックの品質を上げる為に、りプロジェクションを使用する
偶数、奇数フレームでずらす、オーバーラップしない時にはステップを増やす。
（４ステップでリプオエジェクショ）
GPU Pro5で詳しい情報
ローカライズ度キューブマップのエリア
キューブマップは2パスでレンダリングされる。反射なしと、反射有り。
レンダリングにはセクションごとに30分かかってる
質疑：
シーグラフ2011で、Mayaを改造してカスタムシェーダーでPS3相当の絵が出るようにしていたけど、
４ではどうしてた？
→Mayaを改修したわけではない
Mayaの2013になると、ディファードレンダリングの2.0ができる
DirectXのビューポート2.0が使える、レンダリングエンジンをそこに乗せている
デバッグツールのメモリマップ、リアルタイムかキャプチャーベースか？
→メモリリークを生んでいるのを見たかった。（たぶんリアルタイムだと思う）
全てのデバッグツールはCPUとのリンクも張っている、コールスタックも見つけられる
●ディープダウン
シェーディングを3D-CoatとMayaで再現して、リアルタイムで確認しながら作業できるように。
アーティストメイドシェーダー、パフォーマンスアップで実用的に使える
敵の質感のノードツリーがすごい事になってる。
ディティールレイヤー、RGBAのチャンネルごとにそれぞれの場所ごとに質感を帰る
RGBAに3Dテクスチャの核チャンネルの相互とに格納したものをRGBAのチャンネルに割り当てている、
チャンネルに3Dテクスチャのパックを割り当ててやる事で、意匠替えなどが柔軟にできる
エディターで頂点シェーダーの補正もできるようになっている。
→アーティストだけでその辺も作業できる。
デプスで切って背景を徐々に出すような重いシェーダーも、常時出てるのでなければ実用負荷で動いてる
アーティスト自身が見た目を確認しながら作成できる
ノードが複雑で、パフォーマンスが考慮されないのは問題。
- ライティング
タイルベースディファード＋フォワード
アルベドY 、アルベドCをピクセルの偶数奇数ごとにYCbCrで圧縮
→高輝度にさらされると紫色が発生、問題があった。
タイルベースディファード
16x16単位に分割して、ライトリストを生成、視線方向に32個に分割
大きさを持った光源として処理、ポイント、スポット、ディレクショナル、
影と投影テクスチャに対応
直接照明のシェーダー：
画像を16x16単位でCSで処理
ループをライト単位に展開
間接照明：ピクセルシェーダーで一度の処理
放射輝度ボリューム
SSリフレクション
視差補正環境マップ
放射焦土ボリューム：
間接照明の拡散反射
ロード中にボクセルコーンとレーシングで生成
モデル単位でボクセル情報をリストに出力
証明済みのカラー情報とオクルージョン情報
リストをボクセルに入力(256x256x256)
ボクセルのミップマップを作成
シーン全体をおおう128x128x128のプローブに焼き込み、全九面を12方向に分割してコーンとレーシング、
4基底の色として加算、SHとくらべてメモリと品質のバランスが酔い
128x128x128の3枚の3Dテクスチャに収める
視差補正環境マップ、拡散反射と居面反射の両方に仕様、金属の質感に必須
テクスチャキューブアレイ構造で1シーン中に96個置ける、鏡面の荒さで環境マップのミップレベルが変化。
128x128で、ミップマップで2x2まで、RGBEで保存
ロード中に撮影してフィルタリング
４面体で撮影してフィルタリング、CSで一度に全てのミップレベルオｗ作制
スタックレスツリーで視差補正環境マップを探査、
AABBのみのBVHで
ほぼ同じ方向に分岐するので高速
影
ポイント、スポット、カスケードに対応
全て一枚のテクスチャに出力
ディファードで影を使う都合上、一つのテクスチャに全ての深度値を書き込んでいる
（最大20個くらい影が出る事があった、ダイナミックに動くものが少ない）
大半の光源は移動や回転が不変、動かないものは一次バッファに書き出し
静的物体、動的物体の数に寄ってキャッシュをフラッシュする
SSAOは、ループを４単位でまとめて処理、並列度と実効速度が向上
BC7とBC6Hを使った
毛
モデルロード時に生やす点を計算して、ドメインシェーダーで生成
ライティングもピクセル単位でなく度面シェーダーで。
揺れは、前フレームの位置との差分を速度と見なして、ほとんど負荷をかけずに実装できた
質疑：
スキンシェーダーでカバチャーは曲率として使ってる？
→かバチャーのテクスチャは使っているが、明確に曲率としてでなく、意味をアーティストにお任せしている
体毛は、フォワードかディファードか？
→フォワード
エイリアシングは気にならなかった？
→FXAAを使っている
法線をBC7にしてたのは？BC5でなくコンバート時間の長いBC7にしてる理由は？
→最初に対応したのがBC7だった、BC5の方がエンコード時間は短い
BC7だとアルファチャンネルが使えるので、ラフネスなどを入れられる
パララックスコレクトがなぜRGBAにしてる？
→リアルタイムで生成している為、圧縮テクスチャにできてない
アーティストがシェーダーをつくるとバッチが増えたりシェーダーが増えて困るが、どういう管理になってた？
→作れる人はごくわずか、高木さんと一部のエフェクトアーティストしか作っていない
ディティールレイヤーはテクスチャをPhotoshopで変える感じで触れるので便利だけど、本来は焼き込むべき
スタティックなノードとリアルタイムで変えるノードを分けた法がいいかも、と。
CPUからアクセスしやすいメモリとGPUからアクセスしやすいメモリがある
→全ての処理をGPUで完結させる必要がある、GPU用メモリはCPUで読むと遅い
→連携は、CPU->GPUの一方通行で行う
10000剛体で8〜9ms
三角形と球の荒天、ボロノイ領域を使ってもｔメル
signed distance field(符号付き距離場)
BroadPhaseとは
→大まかな形状を使って衝突チェックを行う、絶対に当たらない組み合わせは排除される
とはいえ、n^2になるので計算量が爆発する
→BVH(AABBをリーフに持つ2分木)を仕様
同じwavefrontが同じプログラムカウンタを共有するので、分岐は苦手。
→BVHの構造を固定、完全にバランスされた2分木として、ツリーの深さは固定。
探索は幅優先
→ツリーの探索が簡単になる
固定数のGPUディスパッチで実現
悪いBVHが作られやすい問題について
→逐次フレームで暫時改善していく
→AABBの体積が最も小さくなる組み合わせを選択（体積が小さいといいBVHになる）
（４つのノードの組み合わせチェックなので、固定処理）
→それを上のレイヤーに再帰的に改善
局所解に陥りそうであれば、ランダムに入れ替える要素を追加すると
※２分木の均一化と、逐次改善は覚えておくとどこかで使えそう。
※GPUのために簡単なアルゴリズムにする必要があるので、わかりやすくていい！
依存ツリーを作る時には、親に遡って繋ぐ必要がある
※union-findの応用範囲の広さ！
GPGPU関係無しに、純粋にアルゴリズムの話としても面白かった。
質疑：
ランダム入れ変えの時の係数、何が0.3?
→AABBのサイズ比較時に、倍率にかけるランダム値の係数(+-0.3倍？)
●シリコンスタジオのデモ
技術とアートを一定レベル以上にする必要があった。
物理ベースシェーディングでは、エイリアスはむしろ増える
fogは、シャドウマップをレイマーチング、キューブマップを一つ反省
マテリアルの合成は、Gバッファで行っている
今までの素材集をベースにチャートを渡して加工してもらう事で、リニアワークフロー+PBRでこのくらいのクオリティにはなった
Localized Cubemap ボックスまたはスフィアの影響範囲を指定、
全体で90個ほど配置、各面256x256、BC6Hで50MB
ディファードレンダリング時に影響範囲のキューブマップを重み付けして、影響範囲内のキューブマップを重ねて描画
キューブマップが重なった場所は重み付け平均で。
→分子と分母を独立してアルファとRGBに加算ブレンド、最後にアルファで割れば正規化できる。
（RGBA16BitFloatだと精度問題が出るので、もう少し工夫が必要？）
→重ならないように配置すれば、パフォーマンスへの影響は少ない。
画面内の45個のキューブマップが写ってるが、面積はスクリーンの1.5倍程度
GF660で3〜4ms、グロッシーなところは3〜4本レイを飛ばすことも
テンポラルスーパーサンプリング無しでは見られたものではないー＞カメラ自分で動かすときついところもあるかも？
エイリアシング地獄！
スペキュラエイリアスが酷い！
→AAに時間を咲かざるを得ない
法線ミップマップ生成時に正規化せずに足して、短いところはぼかす。
テンポラルGバッファフィルタリング！
法線が違ってたら押さえる
費用対効果は高そう。
物理ベース時代のエイリアス
空間周波数が際限なく高くなる。輝度も際限なく高くなる。
頂点数も増大するので、エッジが物理的に増加する
１ピクセル内にエッジが１０個くらい重なって、ピクセルごとの法線がランダムに
MSAAやFXAAはほぼ効果無し
トクスビグで多少改善するが、エッジ部分はまだまだ厳しい
→サンプル数を増やさないとどうにもなならない
が、スーパーサンプリングではコストパフォーマンスが悪い割に改善しない
描画量を増やさずにサンプル数を増やす
→時間方向への積分でサンプルを増やす
→デメリット：高周波の高輝度成分がほぼスポイルされる
※エイリアシングフリーな絵は魅力的！
