GTMF2016大阪

Top > GTMF2016大阪

---

概要、資料 †

http://gtmf.jp/2016/
togetter: http://togetter.com/li/996417

Enlightenを使ったリアルタイムの大域照明 †

• リアルタイムなGI
• インドア、アウトドアどちらでもOK
• IBLを提供する

目指した †

• 深みのある影
• 動的なライティングなので、時間と天気の変更が出来る

メモ †

• SkyReflectionMap
  グレースケール。時間帯等で色を変えるため。

海辺のデモ †

• CPUで動く。非同期で描画をブロックすることがない
• 間接光はフルで行う必要がない。間隔は調整できる
• コストと解像度のバランス

• 渓谷で光の遮蔽がないので、上から下まで同じ見た目になる
• Enlightenを使用すると、空からの光の遮蔽、バウンスを計算。
  • 太陽光とスカイライト２つだけで表現できる。
  • ライトマップ、ライトプローブを使用
  • 光の当たっている場所、フォリッジとかはプローブ。影部分はライトマップ。どこにプローブ使うかはアーティストが決めることができる。
  • メッシュに対して、ライトマップの解像度を指定する事ができる。

• enlightenは事前計算する。サーフェイス内の光の計算。
  このシーンでは10台のPCで40分程度

Diffuse Light Probes †

• 自動で配置する
• 複雑なところは高めの解像度になる、マルチ解像度

Reflection †

• シーン内のライティングがリフレクションに反映される
• リフレクションキューブマップをリアルタイムに更新する

Emissive †

• コスト無しで追加のエリアライト

Tools †

• ライティングすべてをコントロールできる
• 早いイテレーション
• コストとのバランスもとっていける

インテグレーション †

• UE4
• Unity5
• SDK
• クロスプラットフォーム

ほか †

blogに情報書いてる

ゲームにおける物理の最適化とデバッギング †

衝突判定の仕組み †

1. ブロードフェイズ
   AABBで判定する剛体を絞る
2. ミッドフェイズ
   複合シェイプをサブシェイプを判定する
3. ナローフェイズ
   正確な衝突の判定

デバッグ †

• ブロードフェイズ、ナローフェイズの可視化
• タイムラインの巻き戻し
• ブレークポイントのひっかけ
• 条件でオブジェクトの検索
• パフォーマンスを可視化
  負荷が高い所をスクリーンに赤く表示

コリジョンメッシュの簡略化 †

• ミッドフェイズとナローフェイズは劣るネックになりやすい
  • 衝突判定する剛体を減らす
    • AABBの分離
    • 衝突フィルター
  • シンプルなコリジョンメッシュ

• 複雑なコリジョンジオメトリとは
  • 頂点数の多い凸形状
  • サブシェイプを多く持つ構造

• 複雑なコリジョンだと
  • ミッドフェイズ、絞るサブシェイプが多くなる
  • ナローフェイズ、衝突判定を検出するサブシェイプ、頂点が多くなる
• 簡略化
  • 手による簡略化
    • Hacokにはメッシュを簡略化するツールが有る（CGO CollisionGeometry Optimizer）。手で簡略化する前にこれで粗くする。
    • Havok Convex Hull Utility。メッシュを一つの凸形状に置き換える。頂点数も制限出来る。
    • Havok Convex Decomposition。目ssyを複数の凸形状に置き換える。元の形を維持したまま簡略化。

線速度、角速度の制限 †

剛体が早い速度で動いている場合、壁をすり抜ける問題
移動量が大きいのでブロードフェイズのAABBがすり抜けてしまう

• 速度を考慮したAABBを作成してすり抜け防止する
  →衝突判定を取るオブジェクトが多くなる
  →制限を強くした方が判定負荷が減る

• デフォルトの制限
  • 線速度＝200 m/s
  • 角速度＝100 rad/s

地形メッシュのマージ方法 †

両極端なマージ方法 †

• staticジオメトリを一つの剛体に
  • 短いブロードフェイズ
  • 少数の長いミッドフェイズ、ナローフェイズ
• 一つのstatic三角形を一つの剛体に
  • 長いブロードフェイズ
  • 多数の短いミッドフェイズ、ナローフェイズ

中間を選ぶ形になる †

• レイヤー分けしたマージ
  地形、木、岩
  一つずつを別の剛体として定義すると３つの剛体
  • 注意点
    • ブロードフェイズのAABBがすべて重なる。全エリアがAABBになってしまうので。
    • AABBが元の形状から懸け離れる

• 領域分けしたマージ
  • 地形を領域に分けてマージする。XZ平面で空間を割る形。

Mizuchiによる超ハイクオリティなキャラクター表現（人肌、衣服など）技術デモ「YURI」について †

シェーダー †

skinシェーダー †

Separable Subsurface Scatteringをベースに実装
テクスチャで強弱をコントロール

• SSSカラー（表皮）、SSSフォールオフ（真皮）、SSS幅（BlurKernelサイズ）

布シェーダー †

スペキュラがソフトに入る、広範囲
スペキュラのピークが出る。リムライト的な。

• 標準的なBRDFでは表現できないので別シェーダーモデルを使用。
  IBLを用いることはできないので、LUTを使用

• Clothnessというパラメーターで調整

髪シェーダー †

• Kajiya-Kayベース
  Specular Shiftsによって２つのハイライト位置を調整
  →入り具合の位置の調整

• Noiseによって人工的な均一のスペキュラ見た目になるのを避ける

クリアコート †

• メタルフレークも表現可能

今後 †

• クリアコート対応
• 髪シェーダー
  • Defferd対応
  • 髪の先のエイリアス除去
• ガラスシェーダー
  • Deffered対応
• 眼球シェーダーも？
  • 今はガラスシェーダーを応用しているので。

YURI Projects †

• およそ330,000ポリゴン
• テクスチャ容量300MB。
  • 2kテクスチャ、顔のアルべドだけ4k

4kでも見れるクオリティ

気を付けたいポイント&Tips †

• とにかく観察して人の形状パターンの把握
• モチーフ無しの場合、特定の素材を見すぎない。引っ張られてしまう
• 加齢やアシンメトリ等マイナス表現を恐れない
  • 写真を加工しすぎるとCG風になるのと同じ
  • 毛穴、シワ、シミ、形状の歪み

• 人物設定を掘り下げ、特徴づけに繋げる
  • 設定から要素分解。年齢や趣味、人柄からシワやシミ、血色、目つき等

• 肌は部位ごとに質感が異なる
  • 部位や加齢によってツヤツヤ感、カサカサ感、テカテカ感が変わる
  • 肌に多少青筋を入れるとしっとり感が増す
  • Tゾーン（額から鼻筋）毛穴が大きめでてかりやすい
  • Uゾーン（顎）、かさつきやすくスペキュラが控えめ
  • 頬。毛穴が開く安く黒ずみやすい
  • 目元口元。皮膚が薄くシワが入りやすい。毛穴ではなく角質が支配的。

• mizuchiのレイヤードマテリアルで高解像度感を増す
  • ベースレイヤー。部分ごとのシワやほくろ等。
  • 詳細レイヤー。毛穴や細かな角質。小ジワ。
    →ベースレイヤーで突き詰めなくても高解像度感が出せる。

QA †

• Q. 髪の流れの方向はテクスチャ？Tangent?
  A. Tangent

• Q, 肌の透過やるのか？
  A. やる予定。後ろからバックライトが当たった時とか

Unreal Engine 4で高品質なVRコンテンツを制作するために知っておきたい100のテクニック †

• Vircleデモ
  • 酔い調査にカメラのパスをloggingして表示。後から再生して確認できる。
  • スタビライザーに近い機能。SpringArmがあって、上下左右の揺れ、回転を抑える
  • ロールとピッチをしないようにしてシーンの水平線を保つ。

• Showdownデモ
  • 低速移動
  • 等速直線移動
  • 高いパフォーマンス
    • Palallax Mapping
    • POM

• Bullet Train
  • 基本的に定点で戦う
  • 移動はテレポート
  • テレポートの際にホワイトアウト、ホワイトイン
  • 腕を半透明にして、肌の質感の違いを無くす。指の動きの違いから感じる違和感の軽減
  • パフォーマンス
    • Instanced Stereo Rendering
    • 映り込みのフェイク。足の形をしたテクスチャを逆方向に張り付けてるだけ
    • 複数マテリアルのベイクによる軽量化
  • オブジェクトを掴める範囲の調整。奥行きはかなり余裕をもって

• VR Editor

• Japan VR ハッカソン

• 何から始めればいい？
  FirstPersonテンプレートがVRコントローラーに対応済み。Motion Controllerコンポーネント。
  手に持たせるのはMotion ControllerコンポーネントにStaticMeshを付けるだけ。

• パフォーマンスが出ない
  • 調べる
    • 「stat UnitGraph」 でボトルネックを調べる
    • 「Profile GPU」でGPUを調べる
  • ライティングとシャドウイングが重いことが多い
  • ポストプロセスも標準状態ではかなりリッチ

Unreal Engine 4を利用した先進的なゲーム制作手法 The Unreal Way 2016 †

Epic Gamesの開発スタイル †

• アーティスト、デザイナーにもっと力を
  • デザイナーのクリエイティビティを解き放つ
  • プログラマのボトルネック化を回避

• 面白さを早く見つける
  • 迅速なイテレーション
  • "Fail early, fail Often"

ホワイトボックス †

レベルデザインのワークフロー

• 目的
  • 短時間でプレイ可能なプロトタイプを作る
  • イテレーションをしやすくなる
  • 無駄な作業とアセットの作り直しを抑える
  • 見た目ではなく、楽しさに集中する

• 順番
  • ハイレベルコンセプト
  • ブレインストーミング　ミーティング
  • ホワイトボックス
    →　箱ポリや板メッシュでレイアウトを作る
  • メッシング
    →　最終段階に近いメッシュに置き換え、基本的なマテリアルを適用
  • スクリプティングパス（ゲームのロジックとか）
  • ライティング
    →　ライティングとマテリアルの改善、ポストプロセスのエフェクトを入れる
  • ファイナルポリッシュ

• ホワイトボックス
  • 大まかにレイアウトを作る
    • レベルの流れを決める。
    • BSPやシンプルなメッシュ
  • ゲームプレイの骨組みを作る
    • ゲームコードのシミュレーション。橋が崩れるなど
  • 短時間で。数日〜数週間

• BSPブラシでホワイトボックスを作った後、そのBSPをブロッキングボリュームに変換したりする。
  • プロトタイプと同じコリジョンを使える

• なぜホワイトボックス？
  • 変更が簡単
    • コアな部分が出来上がるまでアートの実装はしない
  • 時間の無駄を抑える
  • チーム内のコミュニケーション・ロードマップ
    • 後工程の人が、何が必要なのかが分かりやすくなる
  • フィードバックや新しいアイディアを誘発
  • ホワイトボックスに向いていないゲームもある。
    • Fortnite
      ルールに基づいてレベルがプロシージャルに作成される。
    • 格闘技ゲーム
      固定しているライトやエリア

キットバッシング †

• デザインドキュメントはうまく行かなかった
  • 多すぎるディティール？誰も読まない。
  • 少なすぎるディティール？曖昧さ、先入観
  • 読み手への依存
  • Noと言いがちな生活の人々
  • デザイナーがグルメ評論家になってしまった

• キットバッシング
  • 映画の業界。プラモデルのキット。

• 従来
  • 頭の中でデザイン
  • 書類か
  • 終わりのない議論
  • チームによるぷろとたいぴんｇ
  • デザイン通り出来上がるように祈る
  • 背咲くようにレビュー

• 新しい
  • 頭の中でデザイン
  • デザイナーが自分でプロトタイプを作る
  • 製作用にレビュー
  • 実際にテストしたうえで書類か

• アンリアルのキットバッシュ
  • メッシュのパーツ＋ブループリント
  • 見た目は重要ではない。
  • 蜘蛛形の敵を作る。足を破壊していって全部破壊すれば倒せる
    • 適当な円形とかのメッシュを組み合わせてそれっぽい形を作る。
  • 遊んでみて面白ければ、実際に作っていく

• 使用例
  • クリーチャー
  • 武器
  • ゲームプレイシステム
  • 特別なゲームシナリオ

• ベストプラクティス
  • 一人のデザイナーによって製作されなければならない
  • 迅速に実装されなければならない
  • 既存のアセットを使わなければならない
  • 素早いイテレーションを行わなければならない
  • フィードバック（ゲーム中の反応表現）が重要。音やパーティクル等。雰囲気を最終に合わせる。
  • アイディアを捨てるのをためらうべきではない

• やってみよう
  • もっとリスキーなアイディアを考え、やってみよう！
  • Free Friday

新機能 †

• シーケンサー