2019年10月6日に横浜で開催した「UNREAL FEST EAST 2019」の講演動画です。
【公式サイト】
https://unrealengine.jp/unrealfest/
【スライド】
Part 1 : https://www.slideshare.net/EpicGamesJapan/ue4-festeast2019-ue4mobilepart1-179705324
Part 2 : https://www.slideshare.net/EpicGamesJapan/ue4-festeast2019-ue4mobilepart2-179705328
#ue4 #ue4fest
Summarize this content in Japanese 本日最後の公演は そういう e 4ならね あなたのモバイルゲームをより快適にする 沢山の冴えたやり方についてと題しまして 生駒の爆笑をこと エピックゲームズジャパンサポートエンジニヤ 岡田風が講演いたします なおこちらの公演に関しては後日 youtube に公開いたします それではよろしくお願い致しますはいよろしくお願いします うちのボスがまた変な方が気をつけてくれましたん いや本当は何か10人ぐらいの前で話す予定だったんですけど結構 ドラクエじゃなくてこっちに来ていただいて本当にありがとうございます ちょっと頑張ろうと思います宜しくお願いしますはい だ絵本に立ちたくまんご存知の方多いかと思いますがこちらで しておりますスライドは近日中に公開予定です で今回スライド335ページあるんですけどあの時間が足りないのでだいぶ 表示にしておりますゲストであの下の方にあるプログレスバーが一気に進んだらなんか 表示スライドいっぱいあるんだなと思って頂けますと 幸いです はいこんな人ですモバイル担当しております で言い for mobile やはりかなり増えてきました例えばまあこういった タイトルもありますし 最近ですとアップルアーケードで配信がそのオクトバトラベラチームの最新作の針圧 デイライフにも良い4個が強いいただいております 他にもまだ公開されてない台頭もたくさんあったりします というところでやはりもっと言い for mobile 使っている方に実践的な話 をしたいなと今までの城振り替えたところこの2つのですね結構モバイル開発では問題 になりやすいこの2つに関してちょっとまだ ガッツリ時間とって話したことがないので駅をこちらに関してお話ししたいと思います でこの2つに対してですねあの対策をしていない場合もういろんなヤバイことが起こり ますかくついたり電池減ったり発熱したりまクラッシュしたりなどなど やばいですあのストアーに欲しい1みたいな つけられちゃうやつですですのでまぁ今実お話しするような対策を入れてそういった まま a 問題であったりとかゲームをより快適にしていこうという話をしていこうと思い ます ちなみに普段の開発とかテストとかもスムーズに回りやすくなるのである 目から取り入れるのが結構お勧めないようになっております って御品書きです結構盛りだくさんな内容になってますが頑張って最後の公演ですがお 付き合いください まずは筆記対策についてですまあそもそもヒッチってなんぞやと思ってる方いるかも しれません いわゆるこちらゲームの各月にあたります 例えば滑らかに動いていたのに急になんかグッと画面が感なく引っ張られるような
かくついたりすることが時々見ることがあるかと思いますもうですねもう見てるだけで イライラがすごいです そのアクションゲームとかでかくついたりするともう最悪ですねもう なるべく避けたいところです ん でこういったか9月を結構海外の公園とかだと筆致と表現することが多いです 結構言い4の公演もヒッチということが多いです ですので本公演もそれにならいますまたですねあの言い4で各月前で調べたいときは 言い4筆致とかで検索すると結構有益な資料が当たるまでおすすめです エイ でこの筆致がなぜいつ起きるかな関しましては まずいちばんわかりやすいのがもう非常に負荷が重い処理がかかった時です でまたは負荷がつくないんですけども大量の処理例えば100ことが200個の処理が 1フレームでくると筆致が発生します グラフにするとこんな感じです今まで滑らかに動いていたのに急激にまあ折れ線グラフ がキュッと上がったりしてます つまり常に重たい状態が続いているのは筆致と言いません 安定していたのに急にフレームレートがまあ一気に下がることを筆致と言います そしてよく筆致のまあ解決する上で重たい処理が目立ちがちなんですけれども そうではなくて細かい処理が一気に発生していることも同じくうキルティーになります ですのでこの重たい処理だけではなくてなんか呼ばれてるかっていうのも a 考慮する必要があります ですのでヒッチを回避するためには一番シンプルなのがつかオタク件することです次に 処理を削減すれば筆致も解決します またもし この数を削減するのが難しい場合は1フレームに処理が集中することが問題なのでそれ を複数フレームに分散することも手です またちょっと応用編で例えば起動直後にちょっと処理を行なっておいて実際にその処理 が必要になった際は軽めに行うみたいなことも分散として使えます またさらに重たい処理を分散は複数の処理に分散できるんだったらそれをさらに複数 フレームに分散したりとかということもいろいろ考えられます ですのでこのようにヒッチを回避したい場合はこの負荷を削減したり 分散したりという考えが重要ですけっこうこれからお話しする内容もこの削減と分散 ってことは結構意識した内容になっておりますのでこちらちょっと頭の片隅に置いて おいてください では早速一般的な筆致対策についてです よく起きやすいのはこちら労働党かせいぜいとかガベコレとかあるかと思いますが時間 の関係で割愛します はいあとで小月パレードを見て下さい一気にプログレスバー 伸びますこんな感じですはいよろしくお願いしますつ ただまぁ基本的な内容であったりとか偽造の資料のご紹介になりますので結構シンプル な内容にしております はい ではこちらへ次は本日の本題のモバイル特有の筆記対策についてです まずはどこまでやばいのかをちょっと動画でお見せします ランチャーで配信しているアクション rpg サンプルを4年前の xperia z 5という まあ今だとローエンドになるかも知れませんねその端末で検証した結果です こちらです例えばキャラクターでできたときとか 敵が出てくる時とかなんかかくついてますねちょっとグッ
あと敵が武器降るんですけどその時エフェクトが出るのですが ピッチが発生しています グラフにするとこんな感じです でこちらの筆致の原因が今からお話しするシェーダーコンパイルとかメモリ転送速度の 問題が原因になっています で見ての通り本当に強烈な筆致が発生するのでこういった問題の対応は必須です そして最後に結果を見せしちゃいます本日ご紹介する対応を入れたのがこちらの バージョンです いいですねなめらかでヌルヌルな感じで最高ですね f ふぅこんな感じでヒッチが完全になくなります もうこれはもうやるしかないですよねはいみなさんやってやりましょう はいじゃあ11対策の話をしていきます まずはシューターポンパについてお話ししていきます シェーダーコンパイルフォン公園の3本の位置とか半分くらいがシューターコンパイル の話です はいみなさん頑張ってお付き合いください ではまずはシューターコンパイラなぜ発生するのかについてです こちらからです まず言い4でシェーダーコンパイルって言われると こちらが結構思いつくかなと思いますマテリアルをいじってアプライ押すとなんか シューター困憊で主というまあ テキストが出てきて長時間待たされてようやくなんか 見えるみたいな形がよくあるかと思います でこの間いろんな処理が走ってるんですけどもそれをまとめて本公演ではシェーダー ポンパいると言うようにします ちょっと説明の関係です でこのシェーダーコンパイルは普通の pc 柄立つと editor 上でしか起き ないのですがモバイルの場合ですとなんとこれが実機上でも発生します 例えばアクション rpg る的から生成した時の負荷を計測すると こんな感じでもう真っ赤かです拡大すると こんな感じですシェーダーコンパイルの一部の処理である シェーダーリングタイムが470ミスティックかかっています30 fps の タイトルですと15フレイのヒッチかかると かなり強烈な筆致ですなので解決する必要があります ってなんでそもそもこんな問題が発生するのかに関しましては こちらの2つが原因ですレンダリングに使うグラフィックス api の仕様だったり とか モバイル端末の cpu 性能が問題になってきます でもちょっと詳しくご説明していきます
まずこちらが android ios で採用されている グラフィックス api ですちょっとオープンジェリー s からご説明します いろいろ特性はあるんですがシェーダーコンパネに限った話を押す話しします まず android はさまざまなメーカーがさまざまなドライバーを様々な端末が いろんな区の各機能がごちゃ混ぜになっているという非常にカオスな状況です ですので 事前にシェーダーコンパイルを行うことができませんやろうと思えば全端末に対して 事前に用意すればできるんですけど現実的ではないので実機上で毎回行う必要があり ます ですので実は android の場合はパッケージにソースこうチーターのソース コードが丸ごと乗っています 地域上で今敗として最後に描画に必要なシェーダープログラムというものをつくって するメモリに置きます て2回目以降はメモリに乗っているのでそれを使え回します ですので実は起動号に初めて使われている時だけ シェーダーコンパイル走ります2回目以降のか敵が初めて生成して次に生成するときは シェーダーコンパイル走りません ここは結構 a 今回重要な内容になってきます 次にバルカンですでバルカンに関しましては時間の関係で廃止ません っていうのをですねツイートしたらですね数人からめっちゃ怒られたので少しします 少しだけ少しだけします えバルカンはオープンジェリー s に比べてよりシステムの奥深いところまで触れる グラフィックス api です なのでオーバーヘッドがなくなってパフォーマンスが良い良くなる可能性があります しかしまだバルカンは開発中のま api というところもありまして 古い端末の場合ですと逆にパフォーマンスでない可能性があります ん 次に言い4のバルカン対応状況です一応 ds ノートを見ると昨日の互換性であっ たりとか パフォーマンス良くなる可能性がありますただ gpu 負荷に関しましてはちょっと
まだ対応が不十分なところもありましてこちら ae 対応中という段階ですでこの2 つの状況を見てどの端末でバルカンを有効にするのかしないのかお a 見る人があります ちなみにこちら参考情報ですまあ昨今の1年以内のハイエンド端末だったら パフォーマンス良くなるんじゃないのかなってピックないでお話しています で後ポートレートの場合か galaxy のまあ一番ハイエンドの端末ではバルカン 有効にしているという状況です こちらに関しては今後増えていくかなと思います で詳しい言い4のバルカン対応に関しましてはこちらのあの khronos group の方の公園をご確認ください はいあるか少しだけ話しました以上です次に配列です ios に関しましては オープンジェリー s とメタルがあるのですが 技術に関しましてはアップル側の法令非推奨になったので実はえ次の4.24ではそう ポート対象外になりますですのでメダルを使うことになります でメタルは as バルカンと同じくローレベルなグラフィックス api でが メタルと同じようなあーやっぱり感となじゃあな感じになっています シェーダー今パールに関しましてはなんとあの事前にシーラーコンパでできちゃいます マップ上でシェラーコンパイルを行ってその結果を実機上でも使うことができます なので軸上ではシェーダー今 ファイル走りませんや素晴らしい で使うのも簡単ですマップ上でプロジェクトをつくっている場合はマックでビルドする だけで大丈夫です で windows からマックへ乗りボートビルドをしている場合はプロジェクト 設定のテーブルリモートチーターコンパイルっていうのを有効にすれば ok です ただちょっとさっ直近の a バージョンではちょっと不具合がありまして 23では修正されておりますのでご 注意ください ただメタルに関しましてはこの問題があります そのシェーダーを初めて使う際にそのパイプライン state オブジェクトって いうその gpu に渡す
命令をグループ化したものがあるんですけれどもそれを使うことで 量が肉をより快適に行う仕組みではあるんですがその生成処理がモバイルの cpu 性能ではかなり重くなっちゃいます 例えば iphone 7で検証者の結果ですとこんな感じで200ミリ節句をかかっ ています オープンジェリー s に比べたら少ない不可ではありますがこちらもかなりの筆致を 起こしてしまいます ここまでのまとめですシェーダー困憊で初めて使う時に行われます ただメモリにキャッシュされたので一度走れば大丈夫です でまとめて5つ新情報なのですが es の場合は8アプリを閉じるとそのキャッシュ がクリアされちゃうので 2回目起動時も初回利用時に aca だコンパイルが必要になります っていう問題があります でこれにどう立ち向かうのかといいますとそうですねあの4とないともやはり 党的に建築と呼ばれるいろんなオブジェクトを作るしようがあるのでこのシェーダー コンパイルはすごい 非常に解決すべき問題でした というところで入ったのがこちらのパイプライン生徒オブジェクトキャッシュケース大 キャッシュです 遠心コードを見ると fca だパイプラインキャッシュという名前にもなっています ちょっとややこしいですねはい でこれからその ps 4キャッシュの概要とか流れとか注意点などなどをご説明して いきます bs をキャッシュと聞くとなんかエディターでキャッシュをつくって実機上でつの キャッシュを使うみたいなイメージを持つ方多いかと思います 実際僕も思っていたんですけどもそうではありません ps 4キャッシュっていうのは事前にゲーム上ではアプリ上で使われる シェーダーのリストを作っておいてそのリストを使って事前にシェーダーコンパイルを 行う機能になります なのでまっプリコンパイルとか war マップとか呼ばれます まぁちょっとフロー図例を見せしますね まずない時ですないときはアプリを起動してユーザー村で敵キャラ出てくると初めて 使われるシーター困憊走って日ちゃっ制して激おこになります ただこの間メモリーキャッシュされるので敵がもう1回出てきた時はこのキャッシュを 使えます形になります で次はある時です起動してスプラッシュスクリーンれている間に柄プリコンパイルを 行えます この時点でキャッシュを作りますで遊んで敵が出てくるとその毛足を使いまわせるので
まぁ筆致が起こらずユーザーは快適にプレーを続けることができます数字にすると こんな感じです a 使用前後で4703節句を改善されます ます でいろいろまあこれからご説明するような事前準備とか注意点はあるんですけども ここまでの効果がありますのでぜひぜひですねあの導入をご検討頂けますと幸いです はちょっと具体的な話を今後して繰り返していきます まずはイメージをつかむために流れがこんな感じです はいちょっとね手順が色々あるんですけどこれからちょっとずご説明していきます 各項目に関して説明するんですけどもいろんな細かい情報が出てきますか 用語が出てきますただで今回に関しては無視して大丈夫です 実際に作業する際に見てくださいですので今から言うのはなんかですねあの雰囲気を ですね 何 ん ドントシンクみたいな感じをお願いしますはい じゃまずここからですまずはシェラーのディスク組み合わせゲストを作ります このマテリアルがどういったメッシュに使われてそれが例えばポイントライドに当たっ ているとかスカイライダーだって頭を離れないみたいなシーザーの組み合わせリストを 生成します csv 3色でこんな感じですちょっとカテゴリー分けするとこんな感じ でドナーセットの 例えばエールどのぐらい x api でどういう走ったアッシュになっているかを見ます り次はこちらです 次にバイナリー pso というデータを収集するためのパッケージを生成してそれを 実機上で回します っていうことをしますなのでまりっ ps をキャッシュを使うために何か実機上で ペストプレーをする必要があります そして収集したデータをコマンドレットという機能を使って がちゃんこしたものがパイプラインへたデーターですってこれはこんな感じだ もうよくわからなくなってきます そのパイプ出てきたデータを宿したものをパッケージに入れますここまでが事前準備 です はい で実際にゲームをプレイするときはその圧縮データからシェーダーのリストをとってき てそのリストに含まれるシェーダーをひたすらし得たコンパイルプリコンパイルして めぇーメモリにドンのキャッシュしていくっていう処理になります ざっくり言うとこんな感じですとりあえず開発事前にテストプレイして事前情報収集し ておいて で実際のユーザーの環境ではその事前終始者データを用いてプリコンパイル時前 シェイラコンパイルを行ってキャッシュを作るという仕組みになっております で具体的にどういう作業が必要に関しましては公式ドキュメントありますのでこちらを ご覧ください ただこの過程で例えば端末からデータとってきたりとか コマンドでと称えたりとか結構面倒くさい部分があるので自分用ですがバッチ作りまし た
結構ザツです見れば分かると思いますで後 adb コマンド生え端末からデータ引っ張ってくる editor 拡張も置いとけましたまでお使いください ただですね僕がまだマックに慣れてないというところもありまして ios 版は今ん とこありません 頑張りますはいっ であとこちらの公式ドキュメントは4.22版なんですが 23でちょっと変わりましたこちらの設定ファイルをその&レディーにとか ios エンジン 追記しないとそのシェーダーの組み合わせリストが生成されませんのでご注意ください 電話なんかはてはちゃ説明しましたなんか少し手間がかかりそうだなというイメージは あるかと思いますがまあそれによってシーター今パールようにヒッチは完全に解決でき ます も使い始めたらですねーも最高とかもう結婚症みたいな感じにはなるがなるんですけど も ただですねうまい話だけではないんですよこういうの 手術できことがいくつか ありますっていうのをこれからご説明します だいたいこの3つになりますプリコンパイル時間とあと2つの機能についてご説明し ます まずアプリコンパイル時間に関してです そもそもプリコンパイルはシェーダーのリストにあるまた医療のシェーダーを事前に シェーダーコンパイルをガッツリ走らせる機能です ですのでプリ困憊の対象が増えれば増えるほど プリ困憊の時間が長くなってユーザーが実際に例えば遊べる 画面にタイトル画面とかゲームのメイン画面に行くための待ち時間が増えちゃいます 例えばアクション rpg の場合ですと xperia z 5ではだいたい5秒 ぐらい プリコンパイルかかっちゃいます5分ようならまだギリー 間に合うかなとあ思うんですがやはり中規模大規模になってくると数分レベルの待ち 時間が発生してしまいますですのでこのプリコンパイルの時間に関しては結構 こちらも注意する必要が あります でこの大作です今回ご紹介するのは分散すること シェーダのかと制限削減することです まずは分散に関してです まずそもそも起動直後にプリコンパイル大量に走るのが問題です ですので例えばまずこの上の設定を行ってプリコンパイルを起動直後で走らせないよう にします そしてその下の子まんどを使ってプロジェクトにとって適切なタイミングでプリ コンパイル処理を走らせたり 縦断するのが大事になってきます またプリコンパイルの処理優先度の設定可能です 例えば暗転中とかローディング画面は多少あの プリコンパイルでヒッチが起こってもユーザーのマフリエティなりにくいのでそこは
全力でプリコンパイルを回しますで例えば タイトル画面とかメニューを出してる間は cpu のは余裕があるけど キッチンあまりお子 者来ないのでゆっくり1個ずつプリコンパイラ柱したとか っていう機能があったりします ただこの文才に関してましてはちょっと注意点があります なぜかと言いますと その実際に必要なシェーダーがまだプリコンパイルされてないのにそこにそのレベルに 行き着いてしまう可能性があるからです ですのでその芸能実際に遊びたい必釣法が動かして起こしたくない場面で this for cash を絶対使いたい場合はその前衛だーのプリック全体全然 じゃないですね 対象の全プリコンパイルを待つ必要が必要です なので例えばアクション rpg ではこういうフローが考えられます 気動車タイミングですぐタイトル画面に映ってほしいのでここではプリコンパイルを 行いません でタイトル画面は余裕があるので裏日ゆっくりプリンコンパイルを回します ディスタートゲームってゆうあいぽん酢とメイン画面に行くんですけども そこではちゃんと ps 4キャッシュ全開で支えたいのでその間のローディング画面 で全力で回します そしてプリコンパイルが終わったタイミングで画面を切り替えるという流れがベストに なるかなと思います こうすることでユーザーの体幹ロード時間を削減できます ちなみにこのプリコンパイルの時間はこちらの2つの処理で取得できます 上はデリゲートでしたは残りのプリコンパイル回数を取得する処理なのでこれを例えば ティックティックあまり r ですね一定時間ごとにチェックしたりとかそういうこと で画面を切り替えることが可能です 次に制限する方法です まず先ほどもずらす方法は欠点があります 結局全体のプリコンパイル時間は長いです なので例えばめちゃめちゃ連打するユーザーの場合はワーストケースになるので結局数 度レベルの待ち時間発生する可能性があります でまたちょっとあまり説明しませんでしたがそのプリコンパイルの数が増えれば増える ほど メモリにキャッシュするという言葉へ無理使用量にどんどん悪影響があるということ です ですのでまず ps 今日キャッシュを使ううえで重要なことは すべてとかほぼとかたくさんのシェーダーを対象にしようとするのはなるべく控えた方 が良いです なぜかと言いますと先ほどの問題プリコンパイル not かメモリとかパッケージ
サイズもありますし 事前コスト事前の準備コストが笠間のからです例えば 全部のシェーダー対象にしたい場合は最初から最後までフルでプレーしないといけない ですし すべての端を出したりとか全ての敵だしたりとか全ての敵がすべての場所を出したりと かそういうことをしない といけません しかもですねあのシェーダーコードが変わると使いまわせません android で事前コステストしたものを ios 版で使えません なので2つの os があると苦労もリヴァイになります何かこのネタがもう通じない らしいですね 悲しい 麺なのでスープとの四枝をゲッソーキャッシュの対象にしないといけないのかっていう ことを考えないといけません でそもそもシェーダー困憊で必要なタイミングは大体何かオブジェクト生成した時とか レベルをロードした時が多いかなと思いますで前者はもうご説明している通り筆致が 起きるとストレスになりますただレベルの労働に関しましてはだいたいまあ暗転とか ローディングとか ヒッチが馬場れない気づきづらい 問題にならないことが多いのでこちらは実は優先度低かったりします なのでなるべく優先的に対応したいのはこちらの動的に生成されるものになってきます そしてこの動的に生成するものだけをキャッシュするためにそのピースをキャッシュ 収集用のレベルを用意しておくのが結構オススメです 例えばたけぞうさんの効いたの記事ではこういうものが載ってます コテのタイトルでは動的に生成される武器が筆致の原因になっていたのでその武器だけ 大分レベルを デイテスト収集用のパッケージにしたりしています また8イカロス m というタイトルではよりたくさんの こんな感じでキャラクターを得たりとか ui の待ってから置いたりとか様々なこと をしています このおかげでその1日かかっていたシェーダーの事前準備処理が30分に探索 短縮されたということをお聞きしております またこちらは個人的な検証なんですがその editor スクリプティングっていう 機能を使えばこんな感じで自動収集亜洲主要なレベルを自動的に生成することも出来る かなと思います blueprint これを使うことで例えば指定のフォルダ以下のサティック メッシュを自動的にへれるに配置するみたいなことも簡単にできますのでぜひぜひです ねこういったことも試していただけますと最近幸いです 今ですと python とかでもできるかなと思います でここまでが制限の話でした最後は シェーダーをそもそも全体の数を少なくしようという話になります
まず言い4で開発術でマテリアルの管理は非常に注意する必要があります 注意しないとどんどん膨れ上がっちゃいます逆に言うとそういう管理を気を付けること で シェーダーの数を減らして振り困憊の対象を減らしてで結果的にプリコンパイル時間を 減らすことが可能です でもちょっと説明しますまずシェーダーの組み合わせリストこちらあります で例えばポイントライトを使わないタイトルですと削ればこのようにしデータの数を 減らすことができます 逆に言うと使い道が増えるとどんどんシェーダーの数が倍に増えてきますよいつまで このシェーダーの組み合わせをどんだけ減らせるかっていうのが重要になってきます 例えばこちらの枠の部分を減らすためには マテリアの郵政自動管理する必要があります 例えば助けるためメッシュにつしか使わないマテリアルなのにすべてのいう政治に チェックが入っているとその分余分な市営たが作られちゃいますですので定期的にその まてやるが必要最低限のいう政治になっていることを確認する必要があります 次にこちらの後半部分ですこちらに関しましては 8フィッシュプロジェクト設定のシェーダーパー見てーしょんリダクションて機能が 有効です 例えばステーショナリーのスカイライトを使えばない場合はこちらのチェックをオフに するだけでもその それに館スクール生ダーは生成されませんってまたレベルで実際に使おうとすると エラーが発生するのでそういったヒューマンエラーの削減にもつながります って言った話をこちらの指導で結構詳しくしておりますのでご確認ください でまたですねあの結構トラブルになりがちやすいノーマてやるのこういうインスタンス とかの管理とかも 説明ありますのでぜひぜひ見てください てまたこういった機能もありますこちらはあの4とネイトのように pc から コンソールモバイルまで様々なプラットフォームに対応する場合の a キー 有益な機能です 例えばハイエンド pc で使うような機能はモバイルではまあ動かないというか不要 になります ですのでそういった機能はモバイルバーのパッケージが入らないということを明示的に 使用する指定することが可能ですまあそういうすることで シェーダーも減らせますしパッケージサイズ減らしたりとか処理負荷も減らせますので こちらもぜひぜひを買って使いください ええええええ こちらに関しましてもこちらの資料でご説明しています 月ほどの項目以外にも例えばリッチな lod レベルは a mobile では 取り除いたりとかそういう機能も入ったりしておりますのでぜひ的 こちらもご活用ください でここまでのまとめですプリコン場で長い時は例えばゲームフローに適したタイミング にずらすのが良いです また動的に生成するものとかヒッチを改善したいところだけを対象にするのが結構 ベストです
でさらに不要な設定を着ることでまたプロジェクト全体のシェーダースを減らすことが て来重要になってきます ここまでがプリコンパイルの話でした で次は2つの機能についてご説明していきます まずはこちらプログラムバイナリーキャッシュですこちらは8 android オープンジェル優先ようになっています 他のグラフィックス api ではいい感じにしてくれますが こちら es にはないので自前で用意したという形になります まずちょっと少し前にご説明した通りそのオープンジェリー s はそのシェーダー コンパルの結果を次の起動に使えますことができませんキャッシュクリアされちゃい ますですので起動するために初回のそのソースコードからのせいだコンパイルっていう めちゃめちゃ重い処理を走らせる必要があります ですので次回起動時にもそのキャッシュを使い回そうという機能がプログラムの バイナリーキャッシュになります はいデフォルトは実は今有効になっています4点確か22から21か22から有効に なっています でまずは結果です無効な状態でもちょっとキャッシュが残っているので3回目半分 くらいにはなってるんですが プロガンバイナリキャッシュを使うことでここまで削減することができています でまたとあるプロジェクトの場合ですと2分かかっていたのが10秒まで短縮できまし た 初回はこのキャッシュストレージのキャッシュがないので2分がかかってしまうんです が2回目以降は10秒まで短縮できたという事例があります 処理の詳しい内容は表示1回非公開スライド見ていただきたいのですが ざっくりフローをまとめるとこんな感じですプリコンパイルするときにストレージに キャッシュが残っていたらそれを使いまわします でもしなかったらソースコードからコンパイルしてその結果からそのキャッシュを生成 してストレージから臍それ時に保存するという流れになっております でまたこの機能は最近をする機能があります えっ何言うてんのお前みたいな感じる方言いますがちょっと待ってください こんな感じで再起道を走りますタッチするとこの間には全力でプリコンパイルします それぞれ終わるかなーんて言っ 終わったら中中に再起動しますはい自動的にしかもこれがデフォルトで有効になってい ます これはちょっと正直どうかなと思いますってなんでこんなことをしているかといいます と ソースコードからシェーダーコンパイルを行うと余分なメモリ消費がありますですので 調整的に再起動してそれをリセットして で再起同号はすでにストレージにプログラムバイナリキャッシュのシェーダーかの キャッシュが残っているのでそれを使えまそうという方法になります ただ先ほどのように本当にいきなり西木戸が発車てます ですのでユーザーにとってはなんかバグかなと思われる可能性があります ですので例えば西木戸しますよという通じする画面を出したりとか こちらのエンジンコードをカスタムしてよりユーザーに優しい仕様にするのがいいかな と思います またプラットフォームによっては最近ローそもそもが ng になる可能性があります
ですのでそちらも事前にご確認いただくのがいいかなと思います でまたはこちらに関しては本当に少しのメモリ少しでもメモリ消費を減らしたいという 機能になりますのでメモリに余裕のあるプロジェクトの場合は特にまあ向こうにしても いいかなと思います でここまでがプログラムバイナリキャッシュについてです次はこのちょっと名前見てる んですけども全然違う機能ですプログラム lru キャッシュについてご説明します こちらも open ジェルイエス星様になっております でまずこの機能がなんで入ったのかについてです ファルプロジェクトですとある端末ではプログラムバイナリーからあの 描画に必要なシェーダープログラムデータを生成すると 400メガ以上をメモリを確保しましたがかなりやばい状況です で他の端末のある端末の場合ですとメモリ上にその車レーダーのデータが一定 g を 超えてしまうと右下のように これは実際に破綻したいではないのですがこんな感じの破綻が発生しちゃいます ですのでこのプログラムエラールキャッシュっていうのはその メモリがカツカツになってきたら使用頻度の低い 一番昔に使ったシェーダープログラムをメモリから排除する機能です また分もう使わんから8期初号かみたいな機能になっておりますでこちらデフォルト あのこうです ちょっと流れや欲しいのでまた図で説明します まずメモリちゃんですでエフェクトが出ます シェーダーコンパイルしてメモリ2シータープログラムが出てきます でどんどんエフェクトだしてどのメモリがかつかずになっていきますですのでまず lr キャッシュ君は この一番古いシェーダープログラムからまた再生成するようのプロガーのバイナリーと いうものをメモリ 生成します そしてシェーダープログラムをメモリから刷毛します この影でちょっとメモリが余裕できました ただもう1回この日のエフェクトを使いたいなと思ったらこのシータープログラムを またを生成する必要があります ただこのときにまたソースコードからコンパイルすると きっ子が発生しちゃうので先ほどの再生す栄養のプログのバイナリーから シェーダープログラムを生成します そして再生成語学のプログラバイナリーをやはりから発揮するという形になっており ます ですのでなるべくメモリの消費量を一定値に保ちつつもなるべく筆致のこのないように プラグマバッグがボロ g バイナリーという 再生成用のメモリをガーデータをねぼに確保するという機能になっております はいここまでまとめです by まずプログラムバイナリキャッシュはそれで保存する ことで2回目のプリコンパイルを短縮するという機能です て次にエラールキャッシュの方はメモリの傭兵使用量を一定値に保つための機能になっ ております って誰だこえーこちらの2つの機能を使ってもまだ問題解決しないという場合は
そもそも シェーダの数が多すぎる制限で仕切れてないって言うか場合がありますですのでその 場合は先ほどご説明したようなプリコンパイル時母のもうねの対策などを再度ご検討 ください ヘイトもう28分くらいですねシーター困憊の話をしてるんですがもういいです はいお梅の場合はし得たコンパイル筆致の原因なっちゃいます イエスので pso キャッシュを使って事前にキャッシュを作っておきましょう ただいろいろ注意点がありますしかもその注意点を 結構ゲームフローに影響してきますどのタイミングでプリコンボイで走らせるかなど ですですので 開発終盤でこれ取り入れるのは結構ハードル高いかなと思います ですので食とか中盤から pso キャッシュを組み込んだり検証とかしていくのが 重要かなと思います はいようやくシェーダーコンパイラ終わりました次は全く違う話をします メモリ転送に関してですちょっと頭を切り替えてくださいほんとすいませんはい ただ同じぐらい重要な問題です まずみんな大好きグレイマンが描画されるためにはこのすテクスチャーをストレージ から cpu 目ボレーに渡してそれを gp のメモリはたして 予約描画されます でモバイルの場合はこのメモリからし gpu への速度がめちゃめちゃ遅いです ですので pc の場合は6枚一気に送っても全然問題なかったのがモバイルの場合 ですと日家の芸になってしまうという場合があります でこれに対しこれはともモバイル以外のプラットフォームでもよく起きる問題です で一般的な対策ですこちらモバイル以外でも有効です っていう話をする前に言い4ではテクスチャーストリーミングという機能があります出 て来ちゃうまあ語る上ではこれは避けては通れないのでこれについて簡単にご説明し ます まずまあミップマップという機能がありますベースとなるテクスチャーから体街道の テクスチャを使って適切なサイズだけを使うという仕組みです でテクスチャーストリーミングはそれを適切なサイズだけを目堀に移したりとか gup の続きのですのでそうすることで テクスチャーがめメールを使用する量を一定値に保つことが いきます ですので例えばもともとのテック社が4型でもその4型なテクスチャーが江守に格納さ れるというわけではありませんですのでミッドが生成されていたら 適切なサイズだけが怒られますまあちょっとキャラクターだとアプリをすると4型行っ ちゃうかもしれませんがまあそれはちょっとさておき あそういうことになっています ですので逆に言うとテクスチャー3人が効かないミップがない状態とかそもそも無効に してる時ですともう
問答無用でこの4型がストレージとかメモリとか gpu に渡されますピストでその 待ち時間とか筆致とか労働時間とかメモリ使用量の様々な問題が発生します ですので良い4でテクスチャ扱う上で大事なことはこのテクスチャソリー潜んのどん だけ仲良くできるかを気持ちを知ることが死刑大事になってきます でまずは具体的にどういうことをしていくのかについてです まずはテクスチャーのサイズとか圧縮設定に関してです まず圧縮は大事ですが塩かけていきましょう der 食のためには サイズを4の倍数にする必要があります でさらにミップマップを作るためにはに述べ基調にすることです動画あります でこれを守っていないと例えば左下謎のように中國6名がくらい消費しちゃいます ただそれを適切なサイズ圧縮にしておくことで一気にねば2 mb いいかになったり とかという感じになります またその他にもだとエヴァ実際のゲーム画面では全然遠くにしか映らないのに 4型て愚者作ったりするのは確かにテクスチャーストリーミングさんがそれはいらな いって吐きはしてくれるんですけども パッケージサイズのほうに皇帝影響しちゃいますのでそういった観点からも テクチャーのサイズは調整する必要があるかと思います ん でまた面白い事例です徳野ロービングイメージとかはなかなかこの兄の劇場とかし づらいとは思いますがこのイカロス m の場合はこんな感じで変形させて最後 マテリアルで復元することでてクシャナ宿をかけようということをしたりしています そうすることで重要目が合ったのが レグ2 mb まで削減できています で詳細に関しましてはこちらの記事をご覧下さい実際の待ってやるの事例とかも載って います ただですねあの韓国のタイトルですので全部韓国語です あの宮先生を頼って頑張りましょう 出会っ食に関しましてはモバイル専用のまあ機能がいくつかあります でこれから作るようなタイトルの場合ですと a stc で大丈夫かなと思いますが 例えばし5年前の端末までカバーしたい場合は もしかしたら etc とか1 c 2とかもう検討しないといけないかもしれません がまあ基本は stc がいいかなと思います 次にテクスチャーストリームができるだけ使いましょう テクスチャーストリームの弊害としてロードが間に合わないとキャラクターが一瞬呆け てにある上で見えたりとかそういうことが起きがちです ですのでその対策として結構やりがちなのがこのネイバーストリームって言った項目を
有効にして テクスチャソリ無効にすれば全部元のベースなテクスチャーも来られるのでボケない でしょうという tips がよく 紹介されます ただこのネイバー3の有効にすると前 vip が贈られます 4型だよんけどます美音系のしかもそこから作られた低解像度日本も全部一気にメモリ に怒られますですのでかなりのロードとか きっちが発生車のそれでなるべくネイバーストリーマー避けて 母系の解決に取り組むのがいいかなと思います でそちらに関しましては公式ドキュメントとか弊社の雨きいたのブログとかますワイド 仕上げ載せてますのでそちらのをご確認ください ネイバー3枚くらいするんじゃなくてここ行った記事を参考に調整をお願いいたします ただまぁ ui みたいななるべくそのボケたり絶対したくないというテクスチャーもあるかなと 思います でそういう場合はネイバーストリームにするのはアリではあるんですけども ミップマップは不要かと思いますので必ず切ってください 例えば米があったのがミップマップ切ることで四女がに 1 mb 削減できますまあこうして見るとちょっとした違いではあるんですけども チリツモで結構メモリとか同時間に影響してきますのでぜひぜひ英語確認お願いします でここまでがどのプラットフォームでも有効なティップスでした で次がモバイルまぁだいたいモバイルぐらいですねモバイル向けの tips になり ますそれはこちらです メモリから gp に送信するテクスチャー枚数を制限するっていう鳥栖があります は 僕も思いました何言ってんだお前とちょっとご説明します 例えばレベルからどうぞ流浪した時とか大量のテクスチャーがメモリから gpu に 転送されますデフそうするとモバイルみたいなメモリから gp の転送速度をそう いうような端末ですと 筆致が発生します 例えばアクション rpg くんですけ検証するとこのメモリから gpu への転送 するそのストリーム員という処理で160メートルぐらいかかっちゃってます ここに重要なのがこの68回ストリーム員が呼ばれて合計が160ミリ節句ということ です ですのでこの呼び出し回数を減らせば負荷を削減できます っていう機能がこちらになります1フレーム間でその転送量を制限することでまぁその
1フレームにおける負荷を制限しを削減しようて機能になっております でまぁ結果はこちらになります160ミリ節句あったのが生み出し回数を5まで抑える ことで10ミリ節句まで抑えることができました 素晴らしい せっかくなのでどういった流れの処理が起きているのかを図で説明します ただちょっと簡略化している部分があるので一部が正しくない部分もあります はいなので突っ込まないでくださいはいイメージでましょう まずは柄2枚のテクスチャーが労働対象の場合です まずはテクスチャーストリーミングとは関係なく1番ティー解像度が gpu まで怒られます 次にテクスチャーストリーミング君が適切と判断したテクスチャーを cpa メモリーに送りますこんな感じで優先度順に送っていきます で次に民6モディメモリの来られたてブッシャーを gpu に贈りたい所ですが モバイルの場合ですとここの処理が遅いのでヒッチが発生しちゃいます ただ先ほどの設定を on にすると少しずつ送っていくので 1フレームにおける非 cpu 負荷を削減してピッチを回避することができます こんな感じで良い なのでざっくりするとまぁ一気に送っちゃうと遅くなるからちょっとゆっくりを クローネ みたいな機能になっております ただちょっと注意点があります低解像てクーチャーがユーザーにバレてしまう可能性が 増えます つまり gp に起こる頻度が少なくなっちゃうので 例えばこのグレイマンはもっと高解像テクチャーで描画したいのにまだ gp に送ら れてないのでボケた状態で 量がに使われちゃうっていう可能性が増えちゃいます しかもその制限の枚数を増やせば厳しくすれば厳しくする騒動 ブルーマン金が贈られるのが数霊夢先になったりするのでユーザーにバレやすいという 副作用があります ですのでこの設定は慎重にするのがいいかなと思います 例えばある程度余裕のあるハイエンドの場合はちょっと制限をちょっと多めに取ったり とか まあそもそも制限しないとかっていうこともありでスシローエンドの場合は た靴多少て空者ボケてもいいけどボケてを強要しつつ ピッチを回避するために制限強めにとかそういう 戦略があるかなと思います またカットシーンとか極端にキャラクターボケちゃうとサマーそもそもそれがきつい なあっていう場合はそこだけ 制限オフに資することもありかなと思いますその愛前にローディング画面と母さまと そこらへんは緩和できるかなと思います こちら設定の例になっておりますまあローエンドの場合は細いにして入るの場合は20 枚機のクローネみたいな設定になっております こちらご参考になれば幸いです
でここまでのまとめですモバイルの場合は今森から gp の転送速度 まあ遅いので生き残ると必死になった発生しちゃいます ですのでまずはテクスチャーストリーミングのお気持ちを理解して焦っとの調整であっ たりとか システムな調整するのがベストですでモバイルの場合はまあ特に厳しいのでその当て クーチャーの送信数を制限することも結構検討ください はいここまでが40分 s もアイシス対策のまとめです シェーダーコンパイルと眠り転送速度とについてお話ししました 非常に長い戦いでしたでその成果を改めて兵を見せます 左が a その対策入れの前右があってきて対策でた後です ちょっと比較しやすいように左を先に再生するようにしております なので目を左右左右みたいな感じで動かしてくださいはい 頑張ってください左はやはり殻つきます 右は配線ぬですねは本数ムースですねです えっ へって感じですグラフにするとこんな感じです まあ筆致が前座を着てないかなと思いますまあ一番ここはできてるんですけどもまぁ そもそもここはブロッキングロードレベルを呼び出しているのでまぁここは避けれませ んでまたローディング画面中なのでここはまあ 政府としますユーザーの悪影響を及ばさないのでセーフです そこはシェーダーコンパイル走っていたのですが ps 4キャッシュで事前に キャッシュを作った足 作っていたので停止得た困憊のつかなくなりました 次にこちらは a テープチャーの転送が原因だったのですがそちらも改善されてい ます ただしその曲たいのも買ったものを複数フレームに分散したという形になりますので 右側の図の赤箱のようにちょっとフレームレートが安定しない ところが数例も続くみたいな感じになっておりますただまぁ強烈な筆致はこれで回避 すること が出来ました もちろんこの他にも例えばいろんな機能を切ったりとか アセット調整したりとかではありますが一応この2つの対策だけでヒッチの回避はでき ました はい やってやりました 映画みましょうはいはい はい実は外を見てみると色々手間はありますがこのように 手違いで毅然かなと思いますですのでですねあの ps をキャッシュとか siku 社の対応とかはぜひぜひ取り込んで頂けますと幸いです ですねあと15分なのになんか全然違う話をします はいちょっとこちらも頭を切り替えていただけます幸いです ただですね実はこの千枝コンパイルとかテクスチャーわー
ちょっといろいろ話せた通りメモリとは結構密接につながっている問題であったりし ます ですのでこのメモリの問題はちょっとぜひ話したいと思ったのでねじ込みます まず基本的な話をしますどんなプラットフォームでも眠り使用量が一定値を超えると クラッシュします わかりますこれは でモバイルの場合はメモリ容量がそれぞれ端末ごとに違ってくるので上限値も異なって きます しかもへモバイルはさまざまなアプリを裏で立ち上げるので上限値が=メモリ容量で ありません でその使える割合が端末ごとに全然違います しかもそのルールがわかりません 例えばエピック車内で検証した結果です寂しー s eat の場合は75%使えるの に excel 2の場合は半分しか使えないとこういうのが端末ごとの細かい違いがあり ます しかもそもそもメモリ使用量っていう概念が曖昧です 一つの値がクラッシュに影響するんじゃなくてさまざまな値が謎の式で 導かれて導かれた値が謎の上限を超えるとクラッシュします 厳しいきついっすねー はいで例えば1年ほど蔓延1年半ぐらいに gdc 20180正本社の方が講演した こういった指針もあるんですけども これをそのまま使うのは非推奨です 端末ごとに上限値は変わってきますしそのゲームの内容とか車レーダーの使い方によっ てその絶対のクラッシュを の基準となる使用料っていうのは変わってきますですのでこちらの値はあくまで参考に するのがいいかなと思います でつらい状況ではありますがレギュレーション imalu budget は決める 必要があります そうしないとテクスチャーの枚数名前使ったらとかモデルとかっていうのを組みづらい です でまた普段の開発でも計測はするかと思いますがそういった指針がないと計測しても それが問題なのか悪いのかよくないのか みたいなことは分かりません ですのでまぁ大事なことはこの2つです まずはプロジェクトのターゲットのある端末ごとに絶対実機上で計測係数 計測継承するのが大事ですそして計測する際は計測に使う2の特性を把握した上で使う のがベストです 前者の場合はこのようにプロジェクトにとっては例えば数10代とか20代回って くらい まあターゲットする端末あるかと思いますがその端末ごとにこれからご説明する 各ツールのどの値がどのぐらいになったらくらいするのかみたいなことをチェックする のがオススメです 次に鋭角ツールに関してですまずは言い4標準のツールについてご説明します ただ実はちょっと微妙に中のコードがプラットフォームごとに違うので 今からご説明する内容が実は別のプラットフォームではちょっと挙動が変わる可能性が
あります そちらご注意ください まずは一番基本なスタートユニット今ですこの使うことでメモリっていう女ぶっていう ところでメモリしを突っつきますここで面白いのがこちらの値は良い4のエンジン機能 でとってきた値ではありません ゆ4が android とか ios の os に江守州で今ナンボって聴いて とってきた値になります でまたさとユニットは毎フレーム更新するので実はこれは会員版です 精度が低いっていう形になっております 次に stat lm ですローレベルメモリートラッカーっていう ufo が用意 しているメモリ追跡システムになっております でこちらカテゴリー分けされてますので例えば テクスチャーが何どのぐらい使ってるとか横領どのぐらいとかメストレこないとかそう いう細かい単位で調べることができます しかもみんな大好き csb 形式で吐き出してくれるので a マイバーのチェックの時に またグラフを作ったりとかそういうこともできます あ こちらに関しました号 c ドキュメントとか弊社の不可能が公開している 機種とかをご確認ください 次は os 標準のメモリプロファイラーですまず android 今は adb 知るため静め b 4という a command がいい感じです こちらは結構信頼できる値になっております まあ覚悟を木に関しましては公式ドキュメント顧客にいただきたいのですが 基本はこのふと持ちの部分をチェックするのが良いかなと思います トータルとトータルスワップ pss が合計するとだいたい消費している メモリ使用量になるかなと思います
ですので例えばエール r キャッシュを導入することで ええええ 代打一体200名ぐらい減っだなあみたいな光景ソクはこのツールを使うことで行う ことができます 次に ios くんです is の場合はまず xcode のメモリゲージとところ で切っ かなり倉木からに見ることができます さらにへ処理総裁なプロパティする in それ年つのアクティブモニターでは その対象のプロセスがどのぐらい種のブリックっているのが見えます キャプティブモニターのいいところはシッピングでも見ることができます しかも app store で配信されたらアプリのメモリ使用量も見ることが出来 ますこれけっこう面白いです でしかもさらにインストルメンツなロケーションの vm サッカーという機能を使う とより細かい単位で眠りの消費量をみることができます でこんな感じでああいう s の場合はプロファイラーツールはへいくつか存在します ってこれはどう使い分けるかについてです まずは xcode アクティブもいたの場合は見ての通りすごいシンプルで分かり やすいです アクティブモニターの場合はアタッチしなくていいので結構準備も楽だったりします ただこのあたりがどう屋台なのか不明ですこれがどういう値で導かれたあたりなのかで しかもそれが暮らしに影響するのかしないのかっていうのも不明です なんとなくの当たりが出て してくれます 水なロケーションですこちらはすごい詳細に出してくれますが各レジデントとか dirty とかスワップとかバージョンさいつか ios の os 管理に関する ううう雨降り管理に関する深い知識が必要になってきます そういう正 ハードルが高いにもかかわらず結局この値のどれが暮らしに作用しているのかは不明 です
結構 ios で会社はそういった面で結構辛い状況だったりします しかも好ま管理とか浄源寺とか使用料に関しては シェーダーとかゲーム内容によって大きく変化します ですのでエピック内部でも実はあの自信を持ってお伝えできるようなルールとか方針は まだありません ちょっとまあ今頑張って1年以上頑張っていろいろやっているのですがまだ っていうところです ゲストただまあ個人的な考えとしましては もちろん ios に詳しい方がチーム内にいれば アロケーション2でチェックしてそこからなんとなくの budget を導き出すの が良いかと思いますが ただまあそういった学習とかも手間が無理だと まあ予算ないよっていう場合はまあ xcode アクティブモニターで妥協するの もまあ悪くない選択肢であるかなと思います 尿路プロパイダからするまとめです 言い4標準の場合はこんな感じでグラフィカル甘みや水2いつものスタッドで見ること ができます ただスタッドの場合は8実は gpd そうずに関しては計測することができません そして os の場合はそういった結4の標準機能ではトラッキングできない秘境駅も 計測できます ただまぁ深い知識が必要だったり結局暮らしの判定で使えるような値表示してくれませ ん という状況を把握した上でプロジェクトにとって適切なバグ方を構築する必要があり ません あります 例えばこれはあくまで例でありますが さて黎明 os 法人ツールで日々プロファイリングをしてもシスターて霊夢上がって いないのに 後者の標準ツールの方が上がっていたらたぶん gpu 理想像の方に問題があるけど 描画回り問題ないかなあみたいな感じのそういう感じでプロファイリングして問題を 調査するの が良いかもしれません またこれまでご説明した内容はあくまで例えばテクスチャーがなんか問題あるなぁとか そういうざっくりした カレゴリーでしかチェックすることができません ですので例えばテクスチャーに問題があるって分かったらそこから具体的にどの アセットテクスチャーセットが問題になっているのかというところをプロファイリング する必要があります でそれに関しましてはこちらを参考資料をご確認ください
第タイムレポートフルを使うことになるかと思います でおまけです なんと最新の xcode いる分では眠りプロファイル機能が新しく追加されました ちょっとまだ詳しく検証できていないのですが こんな感じでですねグラフィカルに入れます何とどのモンテクチャーが問題になって いるのかも入れます しかもてくるちゃんリストも出してくれます結構いいんじゃないですか ちょっとまあ試してないんですけど結構いいかなと思います ただ xcode イレブンはつか奪えば4.23にしてください 22の位に以前の場合はちょっと不具合が出るって報告受けてますのでご注意ください はい ここの後目です結構メモリーに感謝はすごい複雑な問題で明確なことは超式出せません ただまぁいろんな手法であったりとかでもありますのでそちらをまあ色を使って頂け ますと幸いです あと5分です 55分間おつかれさまでしたはいようやく最新情報の話を 最後ぐらいですねあの楽しい話では言ってるぞ e 賞でちょっと終わりたいと思います はい読んで23にあたる入ったオート員さん信号も前でついてご説明します こちらエクスペリメンタルなんですけど結構動いてますちょっとご説明しますその複数 のメッシュをまとめてドローコールを削減するという tips は特にモバイルでは 有名かなと思います入り4標準機能では例えば static 名刺をまとめるマージ actor とかインスタンス化するイーター2組一種と遠景は一つにまとめる heard またポリッジた時を得られます まあこちらの機能調子のって使うと逆に不買う増えるケースもあるんですけどまぁそれ は置いと言っていい まぁちょっといろいろ制限がありました static なティック目集を オブジェクトず限定だったりとか 事前のセットアップまた融通が利かないセットアップした後にちょっと微調整したりと かっていうのが面倒くさかったですでこれを解決するのがこのオート員さん寝具を モバイルです可能な場合ではありますが勝手にドローコールまとめてくれますしかも 事前中 f 8でこの設定追加するだけです ちょっと検証してみましたまた xperia 高に動いてもらいますチューブ500 個だしてみました 結果です拡大するとなんとドローコールが良いトマトもられて エトロスエットの差が一気に10ミリチェック削減されました
せっかくがゲスなのでもっと派手にやってみました iphone 店で動画は6倍速 にしています はい ひゅーい こんな感じと見づらいかもしれませんが大問差しがオンのときは一気にまとめられます たぶんこの箱で努力オリオンぐらいですで泥セットも中34ミリ節句になってます できると一気に住民石火があってますいまも5千後でてますね ただ員さん信号にするとめちゃめちゃ余裕ですご興味のある方は後でお声かけ いただければ 枚 本店を用いられているので実機で見せれます いいところは事前セットアップ表ですしかも今まで無理だった movable なぁ スティックメッシュもスイン三振が対象にできますじゃめちゃいいです ただ注意点いくつかありますざっくりまとめると銀さん新するための事前準備コストが あったりとか モバイルの場合はされてくらいと無効にしたりとか同じマテリアルじゃないと対象に ならないとといろいろありますが 結構強力な機能ですあと一部のまり端末では数回あります 4.24で以降で修正予定です他にも広いありますのでご確認ください で本日のまとめです皮脂対策まずご説明しました シェーダーコンパイルでメモリ転送問題です前者は ps 4キャッシュなどを使って 事前に今 困憊行うことでキャッシュを生成してそれで弾いて削減できます のバリトンそれ関しましてはテクスチャーストリームと仲良くする必要があります ですのでプログラマーさんだけではなくアーティストさんと一緒に 対応することが大事ですでみもり対策非常に厳しい状況でありますが色々てはあります 頑張っていきましょう であとはエイサー4個4燃えるといういい感じの機能をご紹介しました あと参考値はいくつかいっぱいありますあと速にこのアジアサミットおすすめです ただ全部韓国なので google 先生に食べてくださいはい以上になれます今日は おつかれさまでした はいご静聴ありがとうございます [拍手] [音楽]
