CEDEC2019行ってきましたその２　メモ書き

Unityで始めるオープンワールド（エンジニア偏）

どうつくる？部分 オブジェクトをいっぱい配置した中でどうやって制御するのか？

オープンワールド 広いステージ、多いオブジェクト、スムーズなロード、アンロードをモバイルで

DOTSを使ってやる ECS、JobSystem、Burst 連続して、処理種早く、並列

demoでは１km四方

誤差問題はノータッチ

Stageロード、プレイヤー情報オブジェクト配置、描画をECSで行なっている。 4万２０００くらいのオブジェクト

配置情報はベット持っている。 ECSベースのシーン GameObjectからECSへ変換 GameObjectからEntityへ どういうことか？ GameObject->Comverterを通して変換をおこなう。 パッケージのいくつかはコンバーターに対応している。

ConvertEntityっていうコンポーネントが存在している。 4万２千をコンバートしてしまうと重くなる。 ＝＞SubSceneっていうワークフローが存在している SubjScene以下のオブjぇくとは全てEnetityにする Sceneとは異なるバイナリとして、Sceneとは別に存在している。 これはSceneとは違うもの。

変換自体は簡単 オブジェクト選択して、SubSceneとして変換するだけっぽい それらがアセットっていう形になる？ 4万２千となると全部は結構しんどい ＝＞分割したSubSceen

Entityとは？ Entityごとにコンポーネントごとに見えてしまうが？

実態は構造体の配列 Entityにアクセスする場合は配列のIDを渡して参照するイメージ的 Chunk＝＞特定の組み合わせでのアクセスは楽

SubSceneに保存されるのはChunkと、Entityと、、、、＋Asset

ロードとアンロードを早くしたい→ストリーミングで読み込み等のを行う。 SubSceneっていうAutoLoadSceneにチェックしを入れる

ロードで早くするのにはどういうことをやっているか

ほぼコピーしているだけ。 マネージドデータを使わずにあんマネージドの状態でダウンロードしていく。

AsynvUnloadPipelineを使用 ＝＞逐次読み込み逐次アップロードしていく感じ ＜＝これまでは読み込みが終わるまで待機してアップロードする。

Entity->ワールド間のデータのやりとりはできない。＝マージでワールドで読み込んだ内容をマージする必要がある？

別のワールドに、ロード要求をして、その読み込んだものをMainのワールドに対して読み込んだものをマージすることによって可能にしている。

描画に関して

ECSでのレンダラー REnderMeshはChunkごとに分割されていて、 マテリアルの切り替えが発生する状況だとまずい RenderBatchを行うことで、バッチングを優先される。 ＝＞描画順番が崩れることもあるのでは？

バッチングだけをまとめて、テクスチャで、デプスを最終的テクスチャ単位でのデプスだけを見てみては処理的に軽くなるのでは？ あーでも、その場合だと、ベットどこのテクスチャのものが必要になるかどうかの判断が必要になるのか・・・・

メッシュの結合は描画命令は減らすことができるが、描画するべきものが増えてしまう。

遠距離部分だけは、メッシュの結合（HLOD） なので、手間は見える範囲のもの、遠距離部分は、メッシュをまとめることで結合されたポリゴンとして扱う。

LOD的に、必要なタイミングのデータだけをロードしていく。

ハイブリットレンダラーの問題点としては バッチの特性上、半透明、BAkeしたものはつかえない。

動かしてみると GPUの負荷がすごくなる。。頂点シェーダーのせい

LOD化されていないメッシュはUnityMeshSumoliFireで一応ある GitHUbにて取得できる

UnityDistribution PortalでAndroidアプリを世界の市場へ

アジアが今の所市場が大きい 中国も含めているが、、、

野良アンドロイドストアとかも結構存在する。

現状は各ストアごとのビルドをしないといけないものを 解決するための仕組み。

一つのアプリで 各アプリのUDPダッシュボードに表示 世界中のリサーチが可能になる。

UDPSDKがPackageManagerにある UDPポータル→Webサイト

それぞれの部分に対して、ストアに合わせたSDKがリパッケージされて、ストアに登録される。 ←結構各ストアごとの審査が今後もっと時間がかかるようになってくるのでは？

UDP用のビルドが必要になる。

ポータル上で、スクリーンショットとか、説明文をあげてあげると 選択した、ストアに対して、ストアのチェックを投げる状態になる。

すでにいくつかのストアで行なっている。 表示されただけでも、５つほどあり、ヨーロッパ、東南アジア、インド、中国

お値段的には、全て無料　→ライセンスに関わらず、全て使用が可能。 Google、Appleは無理

各ストアの支払いの一本化はできない、 広告は、動作保証自体は存在しない。使えるかもしれないし、使えないがある。各ストアに対しての、規約によるものが、ある。 これらはデベロッパーもの。

ゲームのみ。（前例がないため） 各プラットフォームに最適化をするわけではない。 ローカライズ

まとめると ローカライズ、振込先の登録、広告規約は、デベロッパー側が調べたり、獲得する必要がある。 広告は動作保証は存在しない。

ローカライズはLocalizartionToolっていうものがあるので、それで対応は可能になるっぽい。 将来的には、TextMeshProでも対応する。 Unity2019以上　０.４.0が現在の最新 Addrestableが必要の関係。

特定の言語なら、このフォントっていう指定は今の所できない。 Foramでの、。フィードバックが必要。

数式式・シェーダープログラムで実現するプロジェクションマッピングー「屋内・冒険の島ドコドコ」

「屋内・冒険の島ドコドコ」は、施設展示形のもので、プロジェクションマッピングを使うためのもの

https://bandainamco-am.co.jp/others/docodoco/

人の行動によって、それが反映される形のもの 像のお尻にボールを当てると、泥が描画されるみたいなインタラクティブな感じになっている。

Projえぇクターと、キネクトと、リアルセンスの組み合わせ。

ここからが講演内容

プロジェクタの選定 画面サイズあとか、投影距離、三面図での表記して選定。

曲面と重複と追従をシェーダーで行う。

数式とかの値をどうこうどうこうする場合の説明の際は実際の、図とか存在した方がいいかもしれない。

歪み補正の話

プロジェクターでの描画色と、それを見る側の見えるものが交点を求めて、表示する。 これでUVを求める感じ

プロジェクションマッピングをする際には、描画の面に対しての、UVの貼り方を結構工夫しなければいけない。（滑り台的な）

重畳　

「カスタムガンマ補正」輝度を半分にしても、実際の明るさは半分にはならないもの

追從

映像取得したものを成績づけした上で処理する。 「Hough直線変換」 https://qiita.com/YSRKEN/items/ee94c7c22599c2374722

画像の中から、円形などの図形を取得するためのもの

輪郭抽出してから、その輪郭の輝度を法線方向に直して成績づけ

誤差的には、映像の方が、先に動いている方が、誤差的にあんまり違和感が存在しない。ように見える。

「重指数関数平滑化フィルタ」

シェーダーで簡単にわかる　DirectXリアルタイムレイトレーシング

レイトレーシングの基礎

レイトレーシングパイプライン

原理的に全ピクセルに対してレイをとばして、そのピクセルを取得

手順 レイの生成 ー＞RayGeneratuinシェーダー レイを飛ばす シーンの操作 三角形の交差した？
ー＞interrectionシェーダー（交差判定を独自で行いたい（プロシージャルで行いたいなど） ー＞AnyHit－＞半透明を使える（CrossHitの部分でさらにレイを飛ばしてというやり方でもできる。） はいー＞ClossHitシェーダー　　 が呼び出される いいえー＞Missシェーダー が呼び出される

フォンシェーディングの最低限のコード

アルベドカラー １．例の生成　２・ピクセル色の取得　　３．テクスチャに格納

ClossHit （例についてまわるオブジェクトと属性（事前定義が必要）が入力として入ってくる

※ラスタライザーで使っていた部分を多く使えるよ。

レイトレースシャドウ

セルフシャドウ（自分自身の影）とドロップシャドウ（床とかの影）

レイトレースシャドウの原則として スクリーンレイ（RayGenerationシェーダー）を飛ばして当たった場所から光源に対して、レイを飛ばす。 光源に飛ばしたレイ（RayGenerationシェーダー）が、 ー＞何にも当たらなければ、そこには影が落ちないっていう判断　ClossHitシェーダー ー＞当たったら、その場所には、影が落ちるっていう判断　Missシェーダー

シャドウのアルゴリズムは基本的は2種類。

レイトレースリフレクション

オブジェクトに反射したもの。映り込み。

スクリーンレイを飛ばした時に、そのオブジェクトが、リフレクションマテリアルだった時に、反射角のリフレクションレイを飛ばす。

レイトレースアンビエントオクリュ―ジョン

レイの衝突点から、半球状に無数のレイを飛ばして計算の平均を行う ＝＞ただし、それだと計算量はすごく重くなる。 なので、ランダムでいくつかのレイを飛ばした平均を行う。

AAあり、でノイズ3回、サンプル3回くらいで、それなりに表示される。

自由に移動できるVRゲームにおけるプレイヤーの誘導

「VoxEl」　ハイエンドVRの研究う開発タイトルとして着手したもの

「VoxEl PV」

https://youtu.be/FSlghmh7j7Q

プレイヤーへの情報提示と誘導

実在感と納得感
納得感ー＞それがなぜ、そのビジュアルで、その音が鳴っているか？の理解。リアルにするというわけではない。

ゲーム開始時の情報制限

移動方法は、わーぷ＋方向転換（押したボタンの方角）

プレイヤーに対してい、何をすればいいのか？を理解してもらう必要がある。

今回の場合は、極端に見せる分を減らす事で、できる事を明確にする。
    声＋ドアのみの状態で、誘導をする。

チュートリアルを兼ねた初期誘導

この世界について、ここにくる理由　プレイヤーの状態を提示する。
世界観
    体を触られる。＝＞プレイヤーが実態がない状態という事にする。
チュートリアル
    何を見ればいいのか？　＝＞　何となくこの系統のものに注目すればいいという感覚が必要。
    操作方法、


VR慣れしていないと、基本的に操作者は、前しかみない。

謎解きステージでの情報提示

エリアが終了の事に、次のエリアへ行くために、次へ進むためのものが存在する。

キャラクターによる誘導 ＝コミュニケーションを取ろうとする生物に対して、人間は強く反応する。 どこを見るべきか？次に行くべきか？を提示

ミスリードする部分として、本当に動かしてほしいものに対して、キャラクターの視線がそれと違う部分があったため、動かしてほしいものと違うものを見ているという状況

音による視線誘導。 ゲームリテラシーが低いと、現実の音ほど、効果がない、明確に長い発音する方がいい。

サウンド重要 環境を表現する音は効果が高いらしい 残響音＋環境音

『ASTRO BOT : RESCUE MSSION』の驚きと心地よさを作るVRレベルデザイン

アストロとの協力関係のもの　　それぞれの独立したもの VR－NESS 体で楽しめる体験

体を動かしたくなる地形
    パースペクティブ　（覗き込む）
        体を動かしたら見えるもの　　大きすぎると、やらされている感になってしまう
    ヴァーティカルティ　（上下の視線移動）
        Astroを見失わないような工夫が必要。
    NEARプレイ
        ASTOROが知覚に来る感じのものを表現する。
        顔にはりつくみたいな事もあり得る。
        単純に近づいてくるだけでは、通り道になってしまう

    FARプレイ
        遠くにASTROが遠くで操作する。
        難易度があがってしまうので、３D上で壁を設けて、２Dプレイ的な操作をする（落ちないようにするなどの工夫）

    360°プレイ
        座っている前提なので、多様はさけた
        ＜－一回向き直す必要がでてくるため


1人称の体験をやっているときはASTOROの操作がとまってしまうので
２：８くらいの割合で今回の場合は実装。

ゲーム内だけでなく、人の動きなども注目して行う必要があった。

コントローラーでのものは基本的には、射出してASTOROの補助になり、同時に動かすっていうことは行わない（大変なので）射出に関しては、厳密ではなくて、補助システムが存在しているので、正確性はン求められていない。

酔いにくくするための3台要素

ベクションを減らすレベルデザインが重要。
    ー＞基本的に向きは同じ方向　その分ASUTOROの動き回る部分を作る。
    進む方向が、プレイヤーが感じる部分がななめとかだと、酔いやすくなる
    ー＞シンメトリーの空間で、中心線を作ってあげる事で、進行方向をわかるなどの工夫がある。

    視線がどのように誘導されるかのものを調整されていった。

自然に感じる動きだし
    ー＞Stopと動く部分のコントロールと、明確な前に進むという状態時（一定距離）
    動揺に首の角度を制御している。

　レベルデザイン制作プロセス

直接すぐに反映ができるような状況位なる。
ゲームのおおめ白さは見た目がチープでも変わらないという信念の基、プロトタイプで確認をしている。

GameStudio/ぱじゃまのままで世界中へ：バーチャルゲームスタジオ運営の技術

どの国にも所属していない会社：Boomzap シンガーポールにVRゲーうをするために物理的に配置した。

どのように？

雇用 ー＞頭と、情熱 正直さと、自己認識

コミュニケーションの問題がある。 職場の専用時間　　オフィスにいる時間というのは、チャットやSlackと同等 共有オンラインドキュメントを使うっていうのが大事

スクリーン共有ビデオと録画するビデオが必須

どうやってタスクの管理をされているか？ 毎日新しいバージョン、毎日2回作業工程を2回工程を報告する。脈絡を添えて。 例えば、見せる時にどのように魅せるものなのかを判断する必要がある。 日報、毎日、サンプルを見せる等で、把握する。 日報自体は簡易で大丈夫。 オークを追加したとかでも大丈夫、リンクを張って、それがどんなものを作ったのかという事を知る事が大事。

毎週のタスクリスト。週の初めに言った仕事が、週の最後の日に終わっているかが大事。

芯（シン）・遅延対策2020 ～ヒトのスペックから紐解かれる、安定性重視とフレームレートのベストプラクティス～

組織にテストを書く文化を根付かせる戦略と戦術

DirectX12 を使用したシェーダー上への独自ニューラルネットワーク構築と描画品質向上のためのリアルタイムレンダリングへの応用

エンジニアから見た「カジュアルゲーム」の魅力

AI「りんな」のボイストレーニング

共感を如何に生み出すかどうかを目指している。

りんなの役割。 相手からの感情表現を受け取って。りんなの中で新しい何かを生み出すような形になる。

人の5感に相当する部分の所が必要。 歌、テキストを理解、動画を生成する、耳と口の連携

2015年ー 最初の立ち位置はLineの中でのサービス まりも育てたり、しりとりしたりとか。

2016－2018年　　タレント的な活動

根幹を担っているのは機械学習 大量のデータから、ある事柄をモデル化する事で、ある程度学習する事が出来る。

実際に、何かを作り出す方向部分にシフトしてる。 ラジオで、上の句と中の句をランダムでもらったものから、下の句をりんなが作成する。 絵画とか、ダンスとか。

りんなのSenses 共感チャットモデル テキストからテキストを生成。 前後の文脈的に、相手とより長く会話を続けるっていう風にする。 １・新しい話題の提案 ２．相手に質問 ３．あ亭の内容の肯定 ４．単純な相槌 ５・無意識（挨拶など）

共感視覚モデル 歌声 電話

歌もデータから学習してモデルの作成　歌声を出す方法。 お手本の人の歌を聞いて、どのタイミングで歌うとかを学習する。 機会学習から、ある事象のモデルの作成。そのモデルから、歌声を作成する。

統計モデルに基づく音声合成 日本語の場合、漢字、ひらがな、カタカナであったり、呼び方がちがったり、アクセントなどで意味がかわってくる場合もある。

エンジニアは、どのようにモデルの学習構築をするか？ 何を入れて、何を出力するか？どのようなモデル構造、どのような学習するか？ 5文字の値から48000の値を予想するとなると、それらの処理（タスク）の簡略化などが必要。

言語特徴量、品詞などのアクセントのベクトルとして表す。 音響特徴量とかのベクトルから、48000の予測を200まで削減できる 音の長さが、どれくらい続くかの要素の推測を行う。

これらのものを学習していく。 合成時には、合成したいテキストを、音声特徴量に直して、音声合成を行う。 そこに発話スタイル（うれしい、悲しい）などのトーンと混ぜる事で行える。これはスタイルのスイッチによる合成を行う。

音声に合わせた音の場合は、音の高さなどの合わせなければいけない。音の大きさなどの考慮も必要

ユーザー歌唱（音量、長さ、高さなど）＋楽譜学習（楽譜から、長さ、高さなど）＋歌詞（テキスト）

『禍つヴァールハイト』モバイルにおけるプレイヤー最大100体同時表示可能なグラフィックス最適化について

淡々としゃべっている感じなので、これはよくないプレゼンのタイプかと。抑揚？とかがないから？

100体表示のために何をしたのか？という内容 UnityVer 2017.4.2.2 全体で最低保証として、20万ポリゴンの表示を目指す。徐々に表示するポリゴン数は増やしていく。 キャラ4000ポリ、ボーン80　骨格が30　ゆれもの　（アニメーションにベイクしている） シェーダー　リムライト、ディレクションライト使用 使用ツール：Profailer FrameDebugger Android　TrepnProfiler

チューニングしたところ ゲームロジック GCのをつぶす部分。

フレーム更新処理でアロケーション控える ListPoolなどでオブジェクトプール 文字列操作自体を減らす 部分検索、結合をなくす。検索の場合は一致検索、ハッシュにする。

Transformの最低限 Findの削除、Generic、ToArrayのコピー　Linqのコピーなどのもの

SetPassCallの削減 ・背景のメッシュの結合、エフェクト、アトラス化＋半透明の発生数の制限 ・UI　静的なパーツと動的なパーツが入れ子にならない

シェーダーの最適化

各要素のSetPass数などを決めるなどの事はやっておいた方がいいかもしれない。 自動でチェック機構などがあるとなおよい。

こっそり教えます！エフェクトデザインのイ・ロ・ハ

・上位5%のしかいないので、希少性が高い。 ・SEとかの連携とかもあるので、すごい大変。 覚えるものが、シェーダー、モデリングなどのものが必要。 大局観が必要になってくる。 ・生存率　95％くらいあるかもしれない。 ・エフェクトはむっちゃ必要とされているので、引く手数多。

エフェクトが、どのように生まれるか 姿、道、死の3工程。

表現には、理由が必要。 これから、作ろうとするエフェクトがどんな姿が求められているか？ 誇張表現（デフォルメ）が求められる理由 １．多次元展開が前提 ２．低等身アバターと相性がいい ３・表現コストが低い

誇張エフェクト３つの特徴 手書き調 パキっとした表現、記号的表現（ピクトグラム的な） 鋭い輪郭 ちぎれる

どんな質感にエフェクトが乗るのか？ 世界の外側との親和性 背景が厚塗り、人物が淡色べた塗。　　全体の質感 結論＝＞異なる質感同士の共存が起きている。 表現において、疑問が大事（当たり前を疑う） エフェクトの質感はどちらに寄せる？背景？人物？ エフェクトのなじませ方 １．等身に合わせる アバターの等身。 等身が高いほど細かくしていく。 最近は等身が高くなっているので、写実的に合わせるが必要 ２．規模間に合わせる ろうそくと山火事では違ってくる。 表現の規模に合わせて、エフェクトを合わせてあげる。 ３．発生源にあわせる。 アバターから出ている場合、アバター側から、合わせる必要がある。 なめらか、ぱきぱき

エフェクトの究極の形（不変な形）
    円、線
    これらが力の向きが存在しているので、それらを崩して整える事で、すごく良い感じのものがいい。

道（ベクトル） 例えば、花火 中心から外側にむかっていきつつも、曲線で。 花火ー＞エフェクト 火花ー＞パーティクル 薬筒ー＞エミッター

主要な属性
    主要4属性
    大きさ、角度、位置（初速、重力、速度、力含む）、色


    メニューを決める
    オーダーする（発生）する
    スパイス

    どんな状況（背景）でも見れるようにする

死（デス） ー流のエフェクトは消え方がカッコいい 例えば円がどう消える（死ぬ） ルック、ベクトル、デス

エフェクトの消去法。表
    １．透かす
    ２．ちじめる（軸方向で色々）
    ３．動かす（方向性、色とか）

エフェクトの消去法
    １．逃がす（拡大、移動）
    ２．さえぎる（白い板、波画像）
    ３．何もださない（エフェクト以外の表現にゆだねる）
    人間に最も響く表現を考え抜く。

GPU最適化：シェーダ実行の高速化手法

最適化の手順 ・最適化対象とするシーンの決定 ベンチマークとするシーンを用意した上で計測を行う。

・最適化対象とする処理の特定 対象を選ぶ　＝　全体の中で、時間のかかっている所 ・ボトルネック要因の特定 対象の時間がかかる要因を探る ・改良方法の選定 対象の解消、手法を考える。

処理間の処理、設定

2016年「GPU最適化入門」とかでボトルネック要因の特定を行う事ができるよ。

コロプラの開発中タイトル事例　〜Unity最新技術でコンソール級のモバイルゲームを実現〜

新レンダリングシステムの方針 ベイクしない、容量少なくする リッチなグラフィックス シンプルな設計 ターゲット30FPS,でもそれ以上で動く。 動的なグラフィックス設定の切り替えがデキル Inspector側から、調整する事で、デザイン側から設定を行うk十ができるようになった。

「サーマルスロットリング」
    部品が燃えたり壊れたりする前に、CPU,GPUが、自己防衛のために、クロック数が下がり、処理速度が下がる事。実質重くなる。


PostEffect
    Glow、Color　Grading、SSAO、FXAAなどを使用している。
    ※SSAO－＞ScreenSpaceAmbientOcclusion　物体に反射した光にも配慮した陰影を生み出す技術
    http://kultur2.blog.fc2.com/blog-entry-2062.html?sp

    ※FXAA・・・Fast Approximate。他と違いポストプロセスのアンチエイリアスで、イメージがレンダリングされた後に適用される。非常に軽く、フレームレートへの影響が少ない。NVIDIAが開発

    シャドウはCascaded　Soft　Shadow　カスケードは最大4枚。

    GPUInstancingを使用する。
        DrawCallがこれで減らす事が出来る。
        SetPassは減らせない。

    Androidだけ遅いの場合は、ドライバのオーバーヘッドを疑った方が良い。

移行するために必要なもの
    CGからHLSLへの移行が必要

AO（アンビエントオクルージョン）マップ   
     影の部分に対して、影を書き込む
     http://ambientocclusion.hatenablog.com/entry/2013/10/15/223302?utm_source=dlvr.it&utm_medium=twitter

描画が遅い問題原因 解像度が高いー＞縮小バッファで解決（LWRPの標準機能） GPUドライバが遅い SetPass DrawCallが多い。GOUInstancingで減らす GPUInstancingではDrawCallだけは減らすことはできる。

これ前提のアセットはどう作るのか？
シェーダーを対応させる必要がある、
ユニークなモデルをなるべく使用しない。共通のモデルを使いまわす。
スケールや回転でごまかす。3種類前後。それらを組み合わせて大きなモデルのように見せている。

岩に草が生えているように見せかけるようにできるようにする。

LWRPにするとLightModeの追加が不可になった。追加でカスタム。 エフェクトはUnityの DefferdDecal？ ※DefferdDecal Decalは、マテリアルをテクスチャにはる技術っぽい　Defferdなので、遅延したはる技術？

ライティング（背景） 光が届かない面も、ランプで調整可能に、シャドウマップ内でも適応するため＝影の部分の立体感を出すため。