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