Top > GTMF2016大阪

概要、資料

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

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

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

目指した

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

メモ

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

海辺のデモ

  • CPUで動く。非同期で描画をブロックすることがない
  • 間接光はフルで行う必要がない。間隔は調整できる
  • コストと解像度のバランス
  • 渓谷で光の遮蔽がないので、上から下まで同じ見た目になる
  • Enlightenを使用すると、空からの光の遮蔽、バウンスを計算。
    • 太陽光とスカイライト2つだけで表現できる。
    • ライトマップ、ライトプローブを使用
    • 光の当たっている場所、フォリッジとかはプローブ。影部分はライトマップ。どこにプローブ使うかはアーティストが決めることができる。
    • メッシュに対して、ライトマップの解像度を指定する事ができる。
  • 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三角形を一つの剛体に
    • 長いブロードフェイズ
    • 多数の短いミッドフェイズ、ナローフェイズ

中間を選ぶ形になる

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

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

シェーダー

skinシェーダー

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

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

布シェーダー

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

  • 標準的なBRDFでは表現できないので別シェーダーモデルを使用。
    IBLを用いることはできないので、LUTを使用
  • Clothnessというパラメーターで調整

髪シェーダー

  • Kajiya-Kayベース
    Specular Shiftsによって2つのハイライト位置を調整
    →入り具合の位置の調整
  • 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と言いがちな生活の人々
    • デザイナーがグルメ評論家になってしまった
  • キットバッシング
    • 映画の業界。プラモデルのキット。
  • 従来
    • 頭の中でデザイン
    • 書類か
    • 終わりのない議論
    • チームによるぷろとたいぴんg
    • デザイン通り出来上がるように祈る
    • 背咲くようにレビュー
  • 新しい
    • 頭の中でデザイン
    • デザイナーが自分でプロトタイプを作る
    • 製作用にレビュー
    • 実際にテストしたうえで書類か
  • アンリアルのキットバッシュ
    • メッシュのパーツ+ブループリント
    • 見た目は重要ではない。
    • 蜘蛛形の敵を作る。足を破壊していって全部破壊すれば倒せる
      • 適当な円形とかのメッシュを組み合わせてそれっぽい形を作る。
    • 遊んでみて面白ければ、実際に作っていく
  • 使用例
    • クリーチャー
    • 武器
    • ゲームプレイシステム
    • 特別なゲームシナリオ
  • ベストプラクティス
    • 一人のデザイナーによって製作されなければならない
    • 迅速に実装されなければならない
    • 既存のアセットを使わなければならない
    • 素早いイテレーションを行わなければならない
    • フィードバック(ゲーム中の反応表現)が重要。音やパーティクル等。雰囲気を最終に合わせる。
    • アイディアを捨てるのをためらうべきではない
  • やってみよう
    • もっとリスキーなアイディアを考え、やってみよう!
    • Free Friday

新機能

  • シーケンサー

リロード   新規 編集 凍結 差分 添付 複製 名前変更   ホーム 一覧 単語検索 最終更新 バックアップ リンク元   ヘルプ   最終更新のRSS
Last-modified: 2016-07-07 (木) 01:28:06 (1929d)