UNREAL FEST EXTREME 2020 SUMMERメモ

メモです

猫でもわかるControl Rig - UE4.25版 -

スクリプト可能なリギングシステム

いままでのアニメーションワークフローでは

DCCツールでモーション作って FBX出して UE4で読んで確認
イテレーションに問題がある
更に外部のモーションキャプチャーツールなどとの連携が増えると更に難しくなる 
つらみ

Control RIgなら

UE4上で編集調整できてしまう
一から作ることも、微調整も可能
C++で独自のノードで機能追加もできる

AnimationBPとちがうの?

AnimBPに比べてバーチャルマシンがすごく軽いメリットが有る

使い方

Rig Graphでリグとキャラの関連付け
Rig Hierarchy で階層構造
Control RigはSkeltalアセットに依存していない骨の名前と階層が同じなら流用可能

アセット作成

Control Rigプラグインを有効化
右クリックメニューから新規作成
ControlとSpaceを積んでいく
ControlはViewport上で触って動かすモノ
SpaceはControlの座標系制御のオブジェクト
動かした結果をノードによってボーンに反映させる
BeginExecuteでControlの位置などをボーンにセットする

ちょっとだけわかった(Sequencer版)




Epic Online Services でできること

EOSでなにができるのか
C++C#IOSSDKをサポート
EOSSDKは現在UEとの特別な連携はなく、ほかのエンジンからの利用と同様にSDKを利用する

全部知ってたらTwinmotionマスター!TwinmotionのぷちTips・テクニック

Twinmotionとは

UE4ベースにした建築建設都市計画造園のリアルタイムビジュアライゼーションソフト
いろいろなDCCツールで作られたデータをインポートして少ない工程で利用できる

user library

自分のアセットを登録して様々なプロジェクトで利用しやすくする仕組み

ライト強度の手入力

普通はスライダで調整するところを数値直接入力もできる

Auto Save

一定時間で自動保存等が設定できる

Grass Fading

芝の表示距離の調整(LOD等)

空の追加

パノラマ画像で空を設定できる
UV展開されたドームオブジェクトが公式にあるので使うと楽(tmiファイル(user libraryデータ)で公開されている)

Reflection Probes

SSRでカバーできない範囲のリフレクションをやりたい場合

Reflection Volume Resolution

鑑などの反射像の解像度を変更する(デフォルトは64x64くらい)

Custom PathとParticle

パス上にフォグやパーティクルをおける

Angle Snap

角度のスナップ単位を設定できる

viewsのレンダリング

平行投影viewなど
ExposureやWhiteBallanceなども変更可能

花の咲く植物

季節ごとのルック切り替えできる

見えない壁

BlockingVolume
納品時に作り込んでいない場所をブロックするとか

Bookmark

オブジェクト出現アニメーション

sections volumeでオブジェクトの可視な空間を制御できる(Volume内でにあるときは見えないとか)

shadowの設定

描画距離とか色々

viewportで操作

carガチャ(リセマラ)

ガチャ

オリジナルデカール

pngで透過付きデカールなど
mp4などの動画も使える

presenter昨日をpadで

Bim motionモードではGamePad操作できる

UE4エンタープライズコンテンツを制作する際のワークフロー ~Cutting-Edge Test Driveを題材に~

エンタープライズ案件50件くらい
これからUE4エンタープライズで使いたい人
開発とワークフローへの理解を深める
当たり前のことを定義

用語

エンタープライズ:非ゲーム領域
CETD:インタラクティブデモとして開発した Cutting-Edge Test Driveの略
アーティスト
エンジニア
開発フェイズ;段階

UE4の利用用途

ゲームから建築自動車輸送放送ライブテレビトレーニング&シミュレーション等

エンタープライズ案件ざっくり分類

インタラクティブコンテンツ系

バーチャルモデルルームや職業トレーニン
体験ベースのもの

静的映像系

建築映像やアニメ等

シミュレーション系

都市シミュレーションや自動運転、災害、AI教師データ生成等
UE4に求められているのはビジュアライズ部分

案件タイプ

エンジニアはインタラクティブコンテンツ系とシミュレーション系が多い
開発期間は3~6ヶ月くらいが多い
開発人数は1~5人くらいが多い

非ゲーム案件の難しさ

要件定義が難しい 技術レベルと要望のすり合わせ
特殊機材や外部ツール連携が多い
制作側が該当業界への理解が薄い 業務フローや用語常識が違う
発注側が開発の流れへの理解が薄い UE制作フローにも

制作フロー

要件定義 技術検証(機能・アート策定) 制作(ほぼ全実装) 詰め

要件定義フェイズ

プロジェクトの目的共有
物量の精査
技術的懸念点の洗い出し(コレによる振り幅が大きい場合は開発計画を分割することも考える)
アートのおぼろげな方向性を提示
「経験が必要なフェイズ」

CETDの場合
目的は自動車業界を中心にUEの活用例を示す
やりたいことはMegascansを使い倒す
製作期間は2ヶ月
メインスタッフはアーティスト2エンジニア1 + 外部スタッフとしてUIとSE

技術検証フェイズ

機能策定 画面遷移
アート策定 テイスト クオリティライン
技術検証 外部機器の検証も試しておく 後のリスクを減らす

どういう画面があってどこがどうつながっていてというのをまとめる
カットリストを作る(映像系の考え方) どういう画面でそれぞれ何をしたいのかどんなアセットが必要か

制作フェイズ

とにかく手を止めずに作る
All-In 全実装を目指す
処理負荷気にしておこう 3割程度の高速化はできるがそれ以上はつらすぎるので注意
ストレージサイズも注意 CETDは2.9GBくらい
スケジュール例
f:id:nagakagachi:20200718160716p:plain

詰め

クオリティブラッシュアップ
最適化 
CETDでは車の質感向上が重要だった
見せるための便利機能の追加等(スキップ機能とか)
粗を潰していく

CETDでは反射物を増やすため直接映らない天井を改良
レイトレやりたかったが4.24の機能では難しかった

f:id:nagakagachi:20200718161226p:plain
各フェイズの割合

案件タイプによる特徴

インタラクティブコンテンツ

とにかく早く動くプロトを作る

映像系

映像を作るパイプラインを構築 DCCツール等 詰めの段階に気合が必要

シミュレーション系

一部モジュールとしてのUEを意識する

これからUE4を始める方へ

なれないうちはチーム連携より個人技 UE4だいすき人間を一人つっこんでおく
プロトタイプは強引でも早く作れるのでつくる

質疑

値段の付け方 初めてのお仕事は数百万でここまでやりましょうという契約
業界ちがいによる予想外の問題が出てくる
契約はフェイズ0とフェイズ1の間で確定が多いがフェイズ0で金額感も決めておくのが多い
フェイズ0の技術検証で出てこなかった問題 外部機器などので機器の用意ができない場合なども多い
ファイルサイズ10GBから2.9GBの削減は主にテクスチャを対象に減らしたのが大きかった
CETDは倍の解像度で出してキャプチャしてた
業界違いの話 建築案件では建材の質感や寸法へのこだわりがすごい ちょっとした草や木の揺れで喜んでくれる ツボがちがう



Bloodstainedで世界のバッカーの期待に応えたUE4事例紹介

ユーザー参加型のゲーム開発
バッカーという個人支援者の要望も取り入れる

ユーザー参加

途中経過をバッカーに報告
ユーザー考案の敵やアイテムなどを組み込み
様々なストレッチゴールに対応 バッカー支援額の量によって変化する目標

どんな期待に答えたのか

描画は 60fps達成
いろいろ

60fpsのためにしたこと

規約

ルールを決めましょう
画面ポリゴン数は30万 背景15万キャラ15万
キャラ背景の奥はunlitにする 画面の30~40%はunlit
規約づくりは実は失敗しながら泥仕合

画面の例教会エリア
背景キャラ合計18万くらい
描画設定
 ForwardRendering
 OcclusionCulling
 Bloom
 FXAA
 影の品質2
計測結果
 実機に近いPCで計測
 実機で計測
 実は半年ほど実機計測してなかった!さらに8倍強いPCで計測してた!

ポリゴン数削減(背景)
 背景は標準LOD機能 装飾はモデリングじゃなくてテクスチャ? OcclusionCulling大事
  LOD設定を Copy LOD でコピペできる!
 OcclusionCullingがとても有効だった
非metalで光沢が出なかった
 ForwardはSSRで無いので反射光沢でにくい
 StationalyLightがあたって無くてそもそもライトがあたってない
 リフレクションキャプチャ(High Quality Reflection)をOFFにしてた

ポリゴン数削減(キャラ)
 当時はUEでスケルタルメッシュリダクションできなかった
 Houdiniでやる
  FBX→Houdiniでリダクション→UE4

f:id:nagakagachi:20200718170945p:plain
Houdiniのノード

  アトリビュートペイントでリダクション具合をペイントできる

マテリアル最適化
 テクスチャ減らす シンプルに
 HightQualityReflectionOFF
 CustomizedUV利用
 キャラはUnlit
  巨大なMaskedマテリアルで常時状態異常のための計算をしてて重い
シャドウ
 影用モデルのHoudiniで作成
 DynamicShadow切る ステージによっては背景全部OFFだったりする

本当はやりたかった負荷削減

負荷設計したかった 実機が必要
EarlyZはいれましょう

途中経過を報告しつつ1600個の画面を輪繰内品質に

納得の行く当たり判定 低画角にする

高画角だと足場がわかりにくいなど問題がある
高画角だと画面の右端と左端でキャラの向きが違ってしまう
低画角にすると背景の立体感がなくなってのっぺりしてしまう
スケールで背景を歪めてしまった
 ジオメトリが歪むのでライティングが壊れる

途中経過を報告する中で改善

大変なことに
手描きテクスチャのアーティスト個性が出すぎて雰囲気がちがいすぎて心配に
手書きのBCテクスチャをやめてProcedual生成にした
基本の建築アセットをHoudiniで作成して品質統一
アセットのプロシージャルアセットを改善し続けて終盤に効果が発揮され始めた
嘘ライトを削除してちゃんとランプとかにライトを置く
Jenkinsさんでライトマップ自動ベイクやBPで大量のライト配置などの効率化

Unreal Engine 4 で広大な世界を構築する際にひそむ罠

共通アセットを探し出す

先読みして共通アセットがないか調査 かなりの量があって1/3のアセットが該当



____________ここでメモは途切れている____________
.
.
.
.

Kd-Treeメモ

Stackless Traversal

Stackを使わない木構造の走査.

Kd-Tree

kd-restart

https://graphics.stanford.edu/papers/gpu_kdtree/kdtree.pdf
子ノードのうち始点に近い方の子を先に処理し、leafに到達して処理をしたら tminをtmaxで更新し、tmaxを新たにルートとの交差で更新してから走査を続ける.
tmin,tmaxだけを保持して都度走査ノードを検索してリスタートする.

Rope

水平方向のノード間のリンク(Rope)によってStacklessな走査を実現する.
http://www.johannes-guenther.net/StacklessGPURT/StacklessGPURT.pdf
https://www.cin.ufpe.br/~als3/saap/ArturLiraDosSantos-ArtigoIJPP.pdf

Dreams Engineメモ

Dreams Engineの仕組みについてメモ

データ表現

CSG

アーティストはCSG(Constructive Solid Geometry)でモデルなどを作る
CSGのEdit-Listという形で管理される
Edit-Listは100kのEditまでサポート
1000^3のグリッド空間でそれぞれのセルについてEdit-Listを評価することで表面を決定する
空間を4x4x4単位で分割していき、局所空間毎のEdit-Listがなるべく短くなるようにする
形状の表面はなるべく分割し、空であったり完全に埋まっている部分は分割しないようにする
分割するかどうかの判断はCSGから計算されたSDFの値を利用する
実験の結果、SDFはL1距離やL2距離ではなく、Lmax距離(Max-Norm Distance)を用いるのが良いとわかった

PointCloud

様々な検証の後に、メッシュ化やVolumeRenderingではなく、CSG表面へPoint Cloudの生成することを試した
SDFは中間表現扱いとなり、Pointを生成する際の評価に利用される
Edit-Listの空間分割の際にSDFの表面上を詳細に分割するようにしており、空間は4x4x4で分割されている
4x4x4=64スレッドでLeafVoxelにSDFのゼロ境界が交差するかチェックし、交差する場合はPointを生成する
LeafVoxelひとつにつきPointは一つとする

LeafVoxelは4x4x4単位でBrickとして管理されている
Brickはヒルベルト曲線で空間充填するように並んでいる
256点毎に1クラスターとしてまとめて処理をする
ヒルベルト順で空間的にジャンプがある場合はバウンディングボックスがタイトになるように調整(よくわからない)

クラスター毎にバウンディングボックスと、法線の境界情報(クラスタ内法線の上限下限?)を持つ
クラスター内のPointは位置、法線、ラフネスをdword(32bit?)にパックしたものと32bitカラーを持つ
クラスター内のPointの情報はDXT1で圧縮される

また、LOD毎に独立したクラスターを計算してミップピラミッドクラスタとそのPointCloudを生成する

レンダリング

モデルのPointCloudを描画をする
各モデルのクラスターをBVHに配置(グローバルではなくモデル一つがBVHでクラスターを管理している?)
LOD間の遷移を滑らかにするために、ロシアンルーレットで25%までPointを間引く(クラスタ毎に256->64まで滑らかに間引かれる)
どうもPointをComputeShaderでAtmicに"Splat"描画をしているらしい

メモ

Brickは4x4x4のVoxelの塊
CSGからSDFを作る(ランタイム?もう一度調べる)
SDFはL1やL2ではなくてLmaxらしい
試行錯誤の後にメッシュやVolumeRenderingではなく点群による描画に行き着いたとのこと

肝としてはPointCloudデータの生成とその圧縮、クラスター単位のカリングとLOD、Compute?によるAtomic演算描画あたりだろうか

Maya Moduleについて

Mayaにおけるツールの配布形態の一つであるModuleについてのメモ。
ツール群を機能やプロダクトでModuleに分けることで最小構成の切り出しなどをやりやすくしたいというハナシ。

Module定義ファイル(.mod)

Moduleの名前、バージョン、Moduleルートディレクトリパスを記述する。
Module毎にロードする条件(win64, linux等)を指定可能。
上記のほかにその他環境変数の設定が可能。
Maya起動時に MAYA_MODULE_PATH環境変数ディレクトリが検索され、Moduleがロードされる。

Module定義ファイルの詳細
help.autodesk.com

記法

+ MAYAVERSION:バージョン条件 PLATFORM:プラットフォーム条件 LOCALE:ロケール条件 Module名 バージョン番号 Moduleルートディレクトリパス
環境変数: 値
環境変数: 値
続く...

条件は省略できる。
環境変数記述は空の行や無効な行があるとそれ以降は無視される模様
scripts, icons, plug-ins, presets の4つの環境変数は、それぞれMAYA_SCRIPT_PATH 等の対応する環境変数にAppendされる。
記述しなかった場合はそれぞれ相対パスで ./scripts 等がデフォルト設定される。
環境変数にパスを設定する際に
[r] scripts: ディレクトリパス
のように [r] キーワードをつけるとサブディレクトリを再帰的に走査する。
デフォルトではサブディレクトリは無視される。

設定例

ロード条件無しで、Moduleのscriptsに関してのみサブディレクトリを再帰的に走査する構成

f:id:nagakagachi:20211006193329p:plain
フォルダ構成
test_module.mod
+ test_module1.0.0 ../module_root
icons: ./icons
plug-ins: ./plug-ins
presets: ./presets
[r] scripts: ./scripts
Moduleロード設定

規定のmodulesディレクトリにmodファイルを置くことでもロードされるが、Maya.envで上記modファイルのあるディレクトリをMAYA_MODULE_PATHに指定しても良い。

MAYA_MODULE_PATH = test_module.modのディレクトリパス

その他

以下のページでは起動時にModule下のuserSetup.pyをそれぞれ呼んでくれるとのことだが、公式情報がまだ見つからないので手元で検証が必要。
Maya起動時に最初に見つかったuserSetup.pyしか呼ばれない場合は、複数ModuleがuserSetup.pyでそれぞれ個別のセットアップ処理をするということができないので別の方法を考える。
hesperas.blog134.fc2.com

Houdini HDK ビルドメモ (18.0.460)

HDK(C++)のサンプルについてcmakeでVisualStudioプロジェクトを作成してビルドする機会があったのでメモ.
注意:ビルドが成功してdllが作成されるところまでの確認しかしていない(未実行).


Houdini 18.0.460
VisualStudio 2017
対象のサンプルは SOP_Star

事前準備

Houdiniインストール
VisualStudioインストール
cmake インストール

サンプルコードを作業用にコピー

Houdiniインストールディレクトリのtoolkitディレクトリを丸ごと適当なディレクトリにコピー(Documentsなど)

コピー元
C:/Program Files/Side Effects Software/Houdini 18.0.460/toolkit

コピー先
Documents等

以降はコピー先ディレクトリで作業する

対象のサンプルディレクトリへ移動

初期だと以下のような状態のはず
f:id:nagakagachi:20200524181238p:plain

VisualStudioプロジェクト作成用ディレクトリ作成

cmakeで作成するプロジェクトファイル群を入れるディレクトリを適当な名前で作成(ここではbuildという名前)
f:id:nagakagachi:20200524181336p:plain

Houdini Command Line Tools 起動

HoudiniのコマンドラインツールHoudini Command Line Tools(以降Command Line)を起動

f:id:nagakagachi:20200524175758p:plain
Houdini Command Line Tools

プロジェクト作成ディレクトリに移動(Command Line)

SOP_Starディレクトリに作成したbuildディレクトリに移動

cd /d "作業ディレクトリ"/toolkit/samples/SOP/SOP_Star/build
f:id:nagakagachi:20200524181857p:plain

cmakeコマンドでVisualStudioプロジェクト作成(Command Line)

cmakeに -G オプションで作成したいVisualStudioプロジェクトのバージョンを指定して実行する
cmake -help でマシンでサポートされているバージョン一覧が表示されるので参考に
今回はVisualStudio2017の64bitビルドプロジェクトを作りたいので以下のように指定

cmake -G "Visual Studio 15 2017 Win64" ..
f:id:nagakagachi:20200524182709p:plain

実行すると以下のようなログが流れる

f:id:nagakagachi:20200524182757p:plain
cmake実行結果

成功すると実行したディレクトリ(ここではbuild)に以下のようにVisualStudioソリューションファイルが作成される
f:id:nagakagachi:20200524183016p:plain

VisualStudioで開いてビルド

slnファイル(ここではHDK_Project.sln) をVisualStudio2017 で開いてビルドして完了
f:id:nagakagachi:20200524183215p:plain

VisualStudioがビルド後イベント等で
/Documents/houdini18.0/dso/
にdllなどをコピーしてくれる

あとはHoudiniを起動してobjタブでビルドしたSOP_Starを検索すれば可能なはず。
しかし私の環境では出てこなかったので一旦ここまで…(Houdini Apprenticeだからかも)

以上

論文メモ[CARL: Controllable Agent with Reinforcement Learning for Quadruped Locomotion](SIGGRAPH2020)

www.youtube.com

Abstract

本論文では物理ベース制御アニメーションで駆動するエージェントに対して、ユーザによる制御が可能且つダイナミックな環境に自然に反応する四足歩行エージェント「CARL」を提案する。本研究ではエージェントは段階的に学習する。まずアニメーションクリップを模倣して身体を制御するように学習する。次にユーザによる高度な制御に対して適切なアニメーションを対応させる行動分布を学習する。行動分布の獲得にはGenerative Adversarial Networksを用いる。さらに深層強化学習によるfine-tuningによって、外部からの摂動から回復しつつ滑らかな遷移を可能にする。本研究では、ユーザの制御に対する追従性能を計測し、生成された動作を視覚的に分析することでその有効性を評価する。

Introduction

(1)動的環境と物理的に相互作用する能力と,
(2)参照モーションクリップから学習した自然な動きを採用することで,データ駆動型の物理ベースの制御可能な四足歩行エージェントを提案する.

複数段階のプロセスからなり、はじめに模倣によってリファレンスモーションを学習、次に速度や向きなどの高度なユーザー制御をGenerative Adversarial Networksを用いたjoint-actionにマッピングすることを学習する。

本研究の貢献をまとめると次のようになる。

  • 高次のユーザ制御と学習した自然な動きを効果的にマッピングするための GAN Supervision フレームワーク
  • DRLを用いて訓練された四足歩行エージェントのための物理ベースのコントローラで、アクションラベルを必要とせずに意味のある反応を生成しながら、様々な外部摂動に適応することが可能
  • 高レベルのナビゲーションモジュールをエージェントに接続する方法

Proposed Method

本研究では、高度なユーザ制御に追従しながら、外部からの擾乱を受けて自然な動きや反応を生成する物理ベースのコントローラを設計することを目的とする。生成された動きは、リファレンスモーションの動きに似ていれば自然なものと評価する。そのために、コントローラを3段階に分けて学習させる。

第 1 段階では、リファレンスモーションクリップの自然な動きを模倣学習により物理ベースのコントローラに伝達することを目的としている。これは物理ベースのコントローラが従うべき行動分布を方策ネットワークで学習することで達成される。
この方策ネットワークはプリミティブネットワークと歩法ネットワークを含み、行動分布を低レベルプリミティブ分布に分解する。結果としてこの方策ネットワークは物理ベースのコントローラが自然な動きを作り出すことを可能にする行動分布を生成し、アニメーションと物理の橋渡しに成功した。

2つ目の学習段階ではGANコントローラーアダプタを採用し、高レベルの歩法ネットワークが先に学習した自然な行動分布を近似できるようにした。しかし、2つ目の訓練段階では外部摂動がないため、外部からのノイズに対応できない。

そこで最後に GAN regularized DRL fine-tuning を追加し、コントローラがそのような外部摂動の影響から回復できるようにする。

関連研究

物理ベース制御アニメーションの具体的な方策や実装などについてはこちらのほうが詳しそう
xbpeng.github.io

UE5の発表についてのメモ

In-house Engineでこれと戦わなきゃいけないってマジ?

PlayStation5 上で動作している Unreal Engine 5 のデモが発表されたので、この時点で感じたことなど覚えておくためにメモ。

目玉は動的GIシステムLumenと微細ジオメトリのレンダリングを実現するNanite。
www.unrealengine.com

Lumen (動的GI)

動的なGlobal IlluminationシステムでDiffuse及びSpecular間接光をレンダリングする。
動的なライトは最近のGIだと半分当然のようなところがあるが、動的なジオメトリはどこまでサポートされるのか気になる。
レイトレハードウェアは使ってないらしいのでCompute Shaderによるものか、EnlightenのようにCPU側で非同期計算する方式なのか。

f:id:nagakagachi:20200514071027p:plain
LumenによるGI有効
f:id:nagakagachi:20200514071116p:plain
GI無し

Nanite (仮想化マイクロポリゴンジオメトリ)

Texture-StreamingのようにジオメトリをStreamingし、ピクセルレベルのジオメトリ描画を可能にする。
デモでは10億Triを超えるソースジオメトリを、Naniteが適切にコントロールして2000万Triのジオメトリを描画しているらしい。

f:id:nagakagachi:20200514070258p:plain
もはやノイズにしか見えないトライアングル群
DCCツールでの特別な作業は不要で、ZBRushなどで作ったものをそのままインポート可能。
いままでNormalMapで表現していたディティールをジオメトリによって直接表現する。
LoDもNaniteがやってくれる。

Niagara

エフェクト以外にもコウモリや蟲の群れなどにもNiagaraを利用している。
パーティクル同士の通信や環境の知覚などもできるらしい。
f:id:nagakagachi:20200514072020p:plain

流体シミュレーション

さらっと流されたけど流体シミュレーション。
f:id:nagakagachi:20200514072246p:plain

Chaos

スカーフのClothシミュレーションや落石にはChaosを使用。
f:id:nagakagachi:20200514072548p:plain

アニメーションシステム

複雑な環境に適応した動きのために手足の適切な位置を予測して動的に調整している。
f:id:nagakagachi:20200514072711p:plain

シームレスなコンテキストベースのアニメーションイベント(よくわからない)。
デモ中の扉に手を添える動きに使われているとのこと。
f:id:nagakagachi:20200514073309p:plain


感想

NormalMapレベルの凹凸をジオメトリで表現してしまえというEpicの解答。Nanite向けのデータを作るためにワークフローが大きく変わりそう。
現代のリアルタイムレンダリングではジオメトリよりも微細な凹凸をNormalMap、更に細かい法線分布のためにRoughnessMapが使われているが、NormalMapが担っていた領域をジオメトリで表現できるようになるとそのあたりの役割も変わってくるのだろうか。
RoughnessMapよりも更に細かいナノスケール表面構造を表現するStructuralMapが使われるようになって構造色レンダリングされるようになったり?
ja.wikipedia.org


あと大したことでは無いけれど気になったのが、3:50付近で右肘の下あたりの水面に一瞬 Screen Space処理っぽい動きが見えた点。肘の動きに合わせて水面のなにかが動いているように見えるけど、部分的に Screen Space Local Reflection をしていたりするのだろうか?(そもそも気のせいかも)

f:id:nagakagachi:20200514082221p:plain
3:50付近


こんな恐ろしいものが出てくる時代でこの先生きのこることができるのか。



5/15追記
UE5デモの技術解説
www.eurogamer.net

一部が削除されたらしいので画像で残しておく
f:id:nagakagachi:20200515071553p:plain