Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

60fpsアクションを実現する秘訣を伝授 基礎編

8.278 Aufrufe

Veröffentlicht am

講演動画:https://youtu.be/YXGmiWzHxeo
解析編:https://www.slideshare.net/EpicGamesJapan/ue4-festeast2019-60fpsanalysis/

2019年10月6日に行われた「UNREAL FEST EAST 2019」における「60fpsアクションを実現する秘訣を伝授」の登壇資料です。
●公式サイト
https://unrealengine.jp/unrealfest/
===
発売中のタイトル「NARUTO TO BORUTO シノビストライカー」に開発中のプロジェクトの事例も加えて、60fpsアクションゲームを実現するためのポイントや、パフォーマンス・チューニングについて解説します。おまけとして「NARUTO TO BORUTO シノビストライカー」のグラフィック面の技術を紹介。

Veröffentlicht in: Ingenieurwesen
  • Als Erste(r) kommentieren

60fpsアクションを実現する秘訣を伝授 基礎編

  1. 1. #ue4fest#ue4fest 60fpsゲームのために 基礎編 講演者:田中達大(ソレイユ株式会社) 60fpsなゲームを実現するための基礎知識、基礎的なノウハウを解説して いきます。
  2. 2. #ue4fest#ue4fest 60fpsゲームを想定した最適化に必要な基礎的な情報や考え方を お伝えします。 より詳細な情報は同講演内のWinterCrownWORKS 梶井氏の 「60fpsゲームのために 解析編」を御覧ください。 このスライドでは
  3. 3. #ue4fest#ue4fest 田中達大 ソレイユ株式会社 シニアソフトウェアエンジニア。 30年くらいゲーム作ってますが、まだまだ現役のつもり。 グラフィック関連を中心に多数のUE4プロジェクトに関わって います。自社経由で他社のプロジェクトをお手伝いすることも。 ご相談はソレイユ株式会社まで。 自己紹介
  4. 4. #ue4fest#ue4fest • 1秒間に60回画面を更新する • コントローラーの入力も毎秒60回判定される • アニメーションも以下略 つまり、16.66ミリ秒で描画、入力に対する反応、各種ゲーム処 理、アニメーションの更新などが行われるゲームです。 忘れがちなことですが 描画が1/60秒で完了することが60fpsなゲームではない! 60fpsなゲームとは
  5. 5. #ue4fest#ue4fest AI制御、コリジョン判定、IK、モーション制御、UIの更新、サ ウンドの更新、オンラインゲームならサーバーとの同期処 理・・・ ゲームに必要なほぼ全ての要素が一秒間に60回更新される必要 があります。 60fpsなゲームとは
  6. 6. #ue4fest#ue4fest ・NARUTO TO BORUTO シノビストライカー PC/PS4/XBOX ONEで60fpsに対応 描画 ⇨ 大変でした 通信 ⇨ 大変でした UI ⇨ 大変でした コリジョン ⇨ 大変でした 実際のところほぼ全ての要素が16.66msに収まっておらず、コ ンソール開発機で15fpsくらいしか出ていないところからスター トでした。 弊社のケース
  7. 7. #ue4fest#ue4fest • プロジェクト初期に仕様を決める段階から考慮しておきまし ょう • 諦めないといけないこともあるという覚悟を • 常に計測をしてパフォーマンスを把握しておくこと • 早めにターゲットコンソールで動かしておくこと • 描画だけ見て油断しないこと • マルチプレイなら最大人数でプレイした状況の負荷を見積も ること 60fpsを目指すなら
  8. 8. #ue4fest#ue4fest 誰でも簡単におおまかな負荷を確認する機能がUE4にはたくさ ん用意されています。 プログラマーに任せっきりにせず、プランナー、アーティスト も常に負荷を気にしましょう。 60fpsを実現するにはチーム全体の協力が不可欠! 日常的な計測
  9. 9. #ue4fest#ue4fest stat unitは常に表示させておいても良いくらいです。 stat fpsはあくまでも最終的なfps値です。CPUが遅れているの か、GPUが遅れているのかわかりません。stat fpsよりもstat unitを見ましょう。 何はなくともstat unit
  10. 10. #ue4fest#ue4fest 開発PCは速いです。超速い。お金持ちな会社ほどさらに速い。 PCで見て安心しないように。 とにかくターゲットの開発機でパフォーマンスをチェックしま しょう、そして時には絶望しましょう。 PCは超速い!
  11. 11. #ue4fest#ue4fest これはバンダイナムコゲームス様 の「ACE COMBAT 7」のPC版シ ステム要件です。 多くの会社が最低スペックにあげ ている構成がだいたいPS4の性能 に近いものを設定しているように 思えます。 最低と推奨で優に数倍の性能差が あります。 PCとコンソールの性能差
  12. 12. #ue4fest#ue4fest PCと各種コンソールでほぼ同じ状態のstat unitを比べてみます 一番左がPC、性能の高い順に並べています。 PCのGPUはVsync待ちを含めての値と思われ、まだまだ余裕が あります。GameスレッドにCPUの性能差が現れています。 stat unitの比較
  13. 13. #ue4fest#ue4fest Frame : そのフレームのトータル時間。 Game : ゲームスレッド。各種CPU処理 Draw : Drawスレッド。描画のCPU処理 GPU : GPUの描画時間 RHIT : RHIスレッド、CPUとGPUの橋渡し的スレッド どれも16.66msを超えてはいけませんが、特にGPUがオーバー しているなら描画、GameがオーバーしているならCPU処理が重 いと判断できます。 stat unitの見かた
  14. 14. #ue4fest#ue4fest ProfileGPUも簡単に結果を見るには大変便利です。 どのパスにどれくらいの時間がかかっているかをざっと確認で きます。 ProfileGPU : 100.0%15.11ms FRAME 457 draws 134401 prims 174505 verts : 19.2% 2.90ms PrePass DDM_AllOpaque (Forced by DBuffer) 3 draws 2 prims 0 verts : 1.1% 0.17ms BeginOcclusionTests 269 draws 8112 prims 5408 verts : 1.8% 0.27ms ShadowDepths 29 draws 42548 prims 57000 verts : 21.2% 3.20ms BasePass 0 draws 0 prims 0 verts : 9.2% 1.39ms LightCompositionTasks_PreLighting 9 draws 19 prims 26 verts : 7.0% 1.05ms DirectLighting 21 draws 41611 prims 55613 verts : 2.1% 0.32ms FilterTranslucentVolume 48x48x48 Cascades:2 2 draws 192 prims 384 verts : 2.0% 0.30ms ScreenSpaceReflections 1725x970 2 draws 1 prims 3 verts : 5.8% 0.88ms ReflectionEnvironmentAndSky 1 draws 2 prims 4 verts : 2.2% 0.34ms ExponentialHeightFog 1725x970 1 draws 2 prims 4 verts : 0.2% 0.03ms Translucency 1 draws 2 prims 4 verts : 16.3% 2.46ms PostProcessing 33 draws 27 prims 75 verts 右はとあるコンソールで実 行した結果です。 シーン全体でのおおよその 負荷を見るには大変便利で すが、個別の重いアセット などを調べることはできま せん。
  15. 15. #ue4fest#ue4fest 大変大雑把ですが、簡単な見かた。 PrePass DM_AllOpaqueが長い ⇨単純にメッシュが多すぎるか、 Masked Materialが多い ShadowDepthが長い ⇨Dynamic Shadowが多い BasePassが長い ⇨描画するメッシュが多い LightCompositionTasks_PreLightingが長い ⇨Dynamic Shadowが多い DirectLightingが長い ⇨動的ライトが多い ProfileGPUの見かた
  16. 16. #ue4fest#ue4fest 全ての描画処理を16.66msec以内に収めるには大変厳しいです。 とあるゲームのとあるコンソールでは、Postprocessはだいたい 2.5msecくらい、BasePass,Prepassで7msecくらい、 DirectLightingに1.5msecくらい、Shadowに2msecくらい使 うともう残りはほとんどありません。 Postprocessパスは頑張ってもあまり減りませんし、他で頑張る しかありません。 BasePassとPrePassはだいたいセットで増減するケースが多い ので、攻めやすくはあります。 ProfileGPUの見かた
  17. 17. #ue4fest#ue4fest いくつかのプロジェクトを見てきた経験では • 影を落とすものを最低限に絞る • 動的なライトも最低限 • Maskedマテリアルを多用しない • 草や樹をたくさん植えない • Landscapeを過信しない • LODをちゃんと用意してちゃんと設定する が基本的なパターンになります。 ざっくり
  18. 18. #ue4fest#ue4fest パフォーマンスを見るには常にライトビルドされた状態で見ま しょう。 ビルドされていないobjectはDynamic Shadowの対象になり、 ShadowMapが生成され描画されてしまいます。これでは正しい パフォーマンスはわかりません。 REFLECTION CAPTURES…の方はパフォーマンスには影響しま せんが、期待した描画にならない可能性があります。 ライトビルドを忘れずに
  19. 19. #ue4fest#ue4fest LODについてのよくある勘違い • LODはあとで用意すれば良い • 頂点数が少ないメッシュには不要 • 遠くにしか表示しないメッシュには不要 LODは大事
  20. 20. #ue4fest#ue4fest ダメです • LODはメモリをその分消費するのでメモリ配分に含めておか ないと後でメモリに入らないということも • 早めにパフォーマンス向上効果が得られていればその分を他 の部分に回せる • 逆に効果が無い場合は早めに見切りを付けられる • 頂点カラーブレンドなどの要因でLOD間の差異が大きくなる 問題が起きる事があるので早めに検知。 ⇨複雑すぎるマテリアルはLODで問題が起きやすい LODはあとで用意すれば良い?
  21. 21. #ue4fest#ue4fest LODの目的は単純に頂点を減らすためだけではありません。 頂点数が少ないメッシュでも小さく描画されると頂点が密集す ることで描画負荷が跳ね上がります。 特にMaskedマテリアルを多用したもの。樹の葉などは顕著です。 面積が0(一点に3頂点が集まったケース)や線になったポリ ゴンはとても負荷が高い。 頂点の密度が高くなりすぎないためにLODは必要です 頂点数が少ないメッシュには不要?
  22. 22. #ue4fest#ue4fest この場合はLODでなくても良いのですが、前ページの理由で頂 点が密集しないように遠景にははじめから頂点密度が低いメッ シュを用意しましょう。 遠景専用モデルはエディタ上でLODを生成して、最小LOD (Minimum LOD)で低いLODに固定するのも有効です。 遠くにしか表示されないメッシュの場合
  23. 23. #ue4fest#ue4fest LODの切り替わりが見えてしまったり、手間がかかるという理 由でLODを嫌うアーティストさんも多い気がします。 しかし、きちんと設定されたLODはかなり効果があります。特 にGPU性能が低いコンソールやモバイルなどには覿面です。 とはいえ、ただLODをStatic Mesh Editorで設定しただけではあ まり効果が無い場合が多いです。 その理由のひとつは、自動で作られたLODはそのままではかな り遠くにならないと切り替わらない事にあります。 やはりLODは大事
  24. 24. #ue4fest#ue4fest Auto Compute LOD Distanceが 有効になっているとScreen Size にかなり小さい値が設定され、相 当遠くに離れないとLODに切り替 わらない場合が多いので、無効に して手動で調整した方が良い場合 が多いです。 手間はかかりますが、効果は大き いです。 LODの設定
  25. 25. #ue4fest#ue4fest LODが適切に設定されているかを確認するのはやはりレベルを 開いて Level of Detail Coloraationを見るのが良いです。 真ん中から赤、奥は緑になって いると良い感じでLODが設定さ れていると個人的には思います。 LODの確認
  26. 26. #ue4fest#ue4fest UE4 4.22からPlatformごとに最小LODを設定できるようになり ました。これはなかなか便利です。 コンソールの性能にあわせて最小LODを変更することでGPU性 能が低いコンソールのパフォーマンス向上に効果があります。 この機能について、コンテンツブラウザから変更できるプラグ インを作成して記事にしたのでよろしければ参考にしてくださ い。 https://qiita.com/dgtanaka/items/5029df3ffcfb0ea1f2de 最小LODの設定
  27. 27. #ue4fest#ue4fest テクスチャについての注意です。 • マテリアルが使用するテクスチャはなるべく少なく。パラメ ーターに置き換えられるものはテクスチャを使用しないなど • サイズが4の倍数、2のべき乗になっているか確認。テクスチ ャ圧縮がかからなかったり、MipMapが生成されていないとと ても描画に負荷がかかる • 解像度は適切に。解像度が高いテクスチャを設定しても実際 に使用される際にはMipMapが使用され、描画に使用されるテ クスチャの解像度は上がらない場合があります テクスチャ
  28. 28. #ue4fest#ue4fest テクスチャエディタで確認しましょう。 フォーマットが適切か、ミップが作ら れているか。 解像度が高すぎるテクスチャは Maximum Texture SizeやLOD Bias で実際にゲームで使用される解像度を 設定しましょう。 テクスチャの設定
  29. 29. #ue4fest#ue4fest 実際の描画時には画面の解像度とUVの密度に応じて適切な MipMapが選択されます。この仕組みは大変良くできていて、テ クスチャマッピングの密度が画面の密度と近くなるように自動 で調整してくれます。 とあるプロジェクトではキャラクターの顔に4096サイズのテク スチャが貼られていましたが、画面内に全身が入るサイズのキ ャラクターの表示時には顔のテクスチャは64x64のミップが使 用されていました。 解像度の高いテクスチャを貼っても描画される解像度が上がる わけじゃない良い例です。 MipMap
  30. 30. #ue4fest#ue4fest エフェクトなどでFlowMapやVectorTable、ノイズテクスチャ などを使用することもありますが、FloatRGBだったり解像度が 高いと大きな負荷になることがあります。 テクスチャのサイズ、アクセス回数が多いということは、それ だけGPU内のメモリアクセスが多いと考えるとわかりやすいか と思います。 描画負荷=GPUのメモリアクセス量 と常に意識すると良いです。実際にはキャッシュにより隠蔽さ れたりするのですが、大まかにはこう思っておいて間違い無い です。 テクスチャの解像度
  31. 31. #ue4fest#ue4fest 描画負荷を抑える意味でもまずはマテリアルは最低限に、シン プルに作りましょう。 シーンに配置して、ライティングを行った上でディテールが足 りなければ足す考え方をオススメします。 全体を軽く作り余裕を残し、その余裕分で必要な部分のクオリ ティを上げていくのが60fpsゲームの作り方だと思っています。 せっかく頑張って凝ったマテリアルを作っても、負荷が高いと 結局削られる結果になりがちです。 マテリアルはシンプルに
  32. 32. #ue4fest#ue4fest • Dynamic Shadowの対象オブジェクトが多い • ポイントライト、スポットライトが多い • Maskedなマテリアルの多用 • ポストプロセスが多い(DoF,SSAO,Motion Blurなど) 多くのプロジェクトで非常にありがちなのが「葉がついた樹を たくさん植えて葉陰が風に揺れる」をやりたがるパターン。 これは最悪に重たいです。60fpsではほとんど無理に近い。 描画が重いよくあるケース
  33. 33. #ue4fest#ue4fest Dynamic Shadow,動的な影は負荷が高いです。 • 影を落とすアクターはシャドウマップ生成のたびに描画され る • 影を落とすライトが複数あるとそのライトごとに描画される • ポイントライトのシャドウは複数方向のシャドウを生成する 場合がある • カスケードシャドウは枚数ごとに描画される • シャドウマップをライティングに合成する際にまた描画され る Dynamic Shadow
  34. 34. #ue4fest#ue4fest • Cast Dynamic Shadowsなライトを最低限にする • なるべくStatic Shadowを使用する • Directional LightのCascaded Shadow Mapsの設定 • Dynamic Shadow Distance…の距離は短く • Num Dynamic Shadow Cascadesを減らす(標準は3) • Inset Shadow For Movable Objectsを無効にする • Dynamic ShadowをCapsule Shadowで行う など、クオリティと相談しながら設定を詰めていく必要があり ます。 Shadowの負荷を下げたい
  35. 35. #ue4fest#ue4fest 動的なオブジェクトの影を別に生成する機能です。キャラク ターの影のクオリティを高くするのに有効ですが、若干負荷は あがります。 プロジェクトによってはDynamic Shadowを切って、キャラ クターの影だけをInset Shadowで描画するのも良いかもしれま せん。 背景のDynamic Shadowが無いとキャラクターが背景の影に 入ってもキャラクターに影が落ちないので、それを許容するか は要検討。影のクオリティは描画負荷に直結するので、なるべ くプロジェクト早期に検討、検証することをオススメします。 Inset Shadow For Movable Objects
  36. 36. #ue4fest#ue4fest Inset Shadowの設定はDynamic Shadow Distance StationaryLightの値が0だと変更できません。 Inset Shadowの設定
  37. 37. #ue4fest#ue4fest • Cast Dynamic Shadowsは必要なアクターにだけ設定 • Maskedなオブジェクトや複雑な形状のオブジェクトは別途影 モデルを用意する • LandscapeのFar Shadowは可能なら切る • LandscapeのDynamic Shadowも切る(要エンジン改造) Landscapeの起伏で影をつくらずに地形の影は別途メッシュや影メッ シュを配置するのは効果的です。Landscape + Cascaded Shadowは高 い負荷になりがちです。 Shadow負荷を減らすその他Tips
  38. 38. #ue4fest#ue4fest • Directional LightはCascaded Shadowで調整 • Point Light, Spot LightはなるべくStaticで。動的に配置する ときもなるべくCast Shadowさせない • StationaryなPoint Light, Spot Lightをオーバーラップさせ ない。範囲も極力狭く Light Stationary Lightが5つ以上オーバーラップするとこのよう にバッテンがついたりします、これは論外ですが、バッテン がついてないからと安心せずに、極力オーバーラップを無く しましょう
  39. 39. #ue4fest#ue4fest エフェクトは常時出るものでないので、気づきにくいです。 常に表示し続けるデバッグレベルを用意したり、デバッグコマ ンドで出せるようにするなどしてチェックできる体制を作ると 良いです。 実際に表示されるときのサイズによっても大きく負荷が変わっ てきます。画面を埋めるほど大きく出すと重いし、遠くにしか 出ないならもっとシンプルにできたりするので、表示される大 きさも考慮して作成しましょう。 エフェクト
  40. 40. #ue4fest#ue4fest • パーティクルがたくさん出る。半透明やMaskedが重なり合う • ライトがたくさん発生する • 半透明のDefaultLitを使用している • 描画面積が大きい • Refractionの多用 エフェクトが重くなる要因
  41. 41. #ue4fest#ue4fest パーティクルがたくさん出ると当然重いです。 薄いものをたくさん重ねるよりも、濃いものを少数重ねるのは とても効果があります。 半透明やMaskedが重なり合うと激重になります。半透明よりも Maskedの方が凶悪なケースも多いです。MaskedはPrepassに も影響を与えるので。 ワイヤーフレームで表示して重なり具合を常にチェックするの が良いです。 パーティクルのオーバードロー
  42. 42. #ue4fest#ue4fest ライトを発生させるときは次の点に注意 • なるべくシャドウは無しで • 数は最低限 • ライトの範囲を極力狭く • ライト同士の範囲が重ならないように ライトの調整はけっこう難しいです。欲しい見た目にしようと するとかなり広い範囲のライトになりがちですが、激重になり ます。 パーティクルのライト
  43. 43. #ue4fest#ue4fest 砂煙などにありがちですが、画面全体を薄い半透明で覆うよう なパーティクルには注意が必要です。とくに薄くて画面全体に 近いサイズのパーティクルが多数重なっていたりすると要注意 です。 描画範囲
  44. 44. #ue4fest#ue4fest エフェクトでよく使う表現ではありますが、Refractionを使う とDistortionパスが走ります。 専用のバッファへの描画が行われ、その後全画面のポストプロ セスが行われます。 Refractionも要注意
  45. 45. #ue4fest#ue4fest Refractionを設定し た球を置いただけの 簡単なレベルです。 Refractionの例 RenderDocでキャプチャして確認。 Distortionというパスが増えています。 そして、屈折方向のVectorがバッファに書 き込まれています。
  46. 46. #ue4fest#ue4fest 屈折Vectorバッファを もとに屈折を反映させ た画面が作成されます。 Refractionの描画 Refactionの描画をまとめると • TranslucencyパスでRefractionが設 定されたActorが描画される • Distortionパスで同Actorが屈折 Vector描画のためもう一度描画され る • 屈折描画をもとに全画面を歪めた画 像が描画される。
  47. 47. #ue4fest#ue4fest • RefractionなActorは2回描画される • 全画面のポスト描画処理が実行される 1つでもRefractionが設定されたActorやパーティクルが描画さ れると上記処理が必ず走ることに注意が必要です。 全画面処理はActorがいくつあっても1回だけなので、そこは安 心してください。 Refractionまとめ
  48. 48. #ue4fest#ue4fest UE4にはDynamicResolutionという、描画負荷が高くなると描 画解像度を自動で落とす機能があります。これは大変効果的で す。 動きが速い画面などでは多少解像度が落ちてもそれほど気にな らないものです。 特に全画面描画をするポストプロセスには大きな効果がありま す。単純にGPUがアクセスするメモリの量が減るので描画負荷 低減に直結します。 DynamicResolution
  49. 49. #ue4fest#ue4fest • アンチエイリアス • モーションブラー • ディストーション • SSAO,SSR,DoF,Bloom,ToneMapping • ポストプロセスマテリアル • Shadowの合成 • ライティングパス などなど。Dynamic Resolutionによる効果がダイレクトに。 全画面描画するもの
  50. 50. #ue4fest#ue4fest 特にCPUの負荷の計測はTestビルドで。Devleopmentとは相当 な差があります。コンソールではより顕著に差がでます。 Shippingではさらに高速になりますが、その分は保険と考えて、 Testビルドで60fpsをキープできる状態を目指すのが良いです。 TestビルドではDevelopmentで使用できるプロファイル系コマ ンドが使用できなかったりしますが、その辺を解決する方法を スミオさんが紹介しています。 Testビルドでも色々計測できるようにする DevelopmentとTest
  51. 51. #ue4fest#ue4fest GPUの負荷の話ばかりでしたが、CPUについても少しだけ。 CPU負荷はゲームのスタイルによってケースバイケースですが • AI処理 • コリジョン判定 • アニメーション • UMGの更新 • 通信処理 のあたりが問題になります。 CPU負荷について
  52. 52. #ue4fest#ue4fest UIはだいたい後で問題になってきます。インゲームUIが多いと 積むケースも。 画面にいろいろ情報を出したい誘惑との闘いが必要。 UIの場合描画よりもレイアウトの更新などでCPUへの負荷とし て重くのしかかってきます。 シノビストライカーでもUIだけで10msec以上食っていた時期 がありました。 UIは要注意
  53. 53. #ue4fest#ue4fest UIに関してはとにかく表示を減らすのがベストですが、それで も表示しなければならないものはあります。 UIで主に負荷になるのはCPU側なのでレイアウトや更新頻度な ど細かく最適化することでかなり改善は見込めます。 シノビストライカーでもご協力頂いた有限会社ウニコさんの資 料が参考になるかと思います。 実際にあったUMG実装問題と処理負荷対応 有限会社ウニコ UI(UMG)の最適化
  54. 54. #ue4fest#ue4fest CPU処理はGameThreadに集中しがちです。実際には多数の物 理スレッドが使用できるにもかかわらず、ほとんど使用されて おらず、GameThreadだけが詰まってるケースが多いです。 コアを使い倒すのは非常に困難ですが、なるべくスレッド分散 ができる方法を考えたいところです。 時にはエンジンの改造が必要ですが、マルチスレッド化はかな り効果があります。 とはいえマルチスレッド化できない処理が多いのが現実ですが。 並列処理
  55. 55. #ue4fest#ue4fest よく「DrawCallを減らすと負荷が下がる」という話を耳にしま すが、少々誤解があります。 DrawCallを減らすことで負荷が下がるのは主にCPU側です。 DrawCallを減らすためのマージやインスタンス化はカリング効 率を下げることでむしろGPU負荷を増やす結果になることも多 いです。 CPU側もGame Threadとは別スレッドで処理されているので、 負荷軽減がほぼ影響しないこともあります。 CPU,GPU両方の負荷を計測しながら作業することが大事です。 DrawCallについて
  56. 56. #ue4fest#ue4fest DrawCall削減のためにアクターマージをするときの注意点 • マージ後のバウンディングボックスを確認。大きくなるとカ リング効率が悪く描画負荷が高くなる。 • 離れて配置されているものをマージしない。バウンディング ボックスが巨大になりがち • マテリアルが違うものをマージしてもマテリアルごとに描画 されるのでBasePassのDrawCallは減らない バウンディングボックスが大きいと実際には1ピクセルも描画 されないのに数十万頂点がGPUに投入されたりします。 DrawCallとマージ
  57. 57. #ue4fest#ue4fest 画面の外だったり、他のオブジェクトの後ろにあって描画しな いで良いものを除外することをカリングと言います。 カリングの話だけで1講演できるくらいなので詳しくは説明し ないですが、描かなくて良いものを描かないのは絶大な効果が あります。 距離が遠いものをカリングすることもできます。 バウンディングが大きいとかリングされなかったりするので注 意が必要です。 カリング
  58. 58. #ue4fest#ue4fest 定番ですが、コンソールコマンドで FreezeRendering ToggleDebugCamera でカリングを固定してカメラを引けば、どれくらい画面外やオ ブジェクトの後ろのものが描画されているかを確認することが できます。 不要なものがなるべく描画されない様にバウンディングを確認 したり、CullDistanceVolumeを設定していきましょう。 カリングの確認
  59. 59. #ue4fest#ue4fest シューターゲームでFreezeRenderingでカリングを固定して ToggleDebugCameraでカメラを自由に移動できる状況にし た。まだカメラは動かしていない。
  60. 60. #ue4fest#ue4fest 後方にカメラを引いた状態。上下 の構造物や遠景などかなり多くの オブジェクトがカリングの対象に なっていないことがわかる。 反対側から見た状態。手前のオ ブジェクトはオクルージョンカ リングでカリングされていると 思われる。
  61. 61. #ue4fest#ue4fest 最適化についてはEpic Gamesからもたくさん資料が出ています。 特にFortniteに関する資料は非常に実践的ですので、まずはひと とおり眼を通すことをオススメします。 Fortniteを支える技術 参考資料
  62. 62. #ue4fest#ue4fest • 60fpsゲームとして企画、デザインする。 • 日々計測。計測の結果を信じる。予想で終わらせない。 • チリツモな作業の連続、ていねいな仕事が結果最も早い。 • こまめにターゲットコンソールで確認する。 • すべてのセクションで協力する。エンジニアまかせにしない。 説教ぽくなりますが、60fpsは茨の道です。 60fpsの秘訣
  63. 63. #ue4fest#ue4fest • 60fpsで作るのはしんどい • 60fpsで遊べると気持ちいい ご静聴ありがとうございました。 ソレイユでは新人からベテランまで幅広く人材を募集していま す。興味があれば弊社ウェブサイトからエントリーできますの で是非! ソレイユ株式会社 http://soleilgamestudios.com/ まとめ

×