座標(ライトマップテクスチャの場所を示すもの)と、個々のメッシュのオフセットとスケールをワンセットで作成します。ライトを再ベイクするたびに、座標は変化します。チャンネルの仕組みと、それを最大限に活用する方法についての知識が役に立ちます。チャンネルと呼びます)を持つことができます。座標セットを追加する以外の方法がないこともあります。座標を使うことの欠点は、メモリの消費量が増えることです。アップロードされます。使って、通常のライトベイキング機能で座標とライトマップを生成します。チャンネルに書き込まれます。座標セットが使えないことに注意することです。モデルをアンラップする必要があるからです。すべての面に同じテクスチャを使っている箱を想像してみてください。箱の各面にはそれぞれの光の当たり方と影のつき方があるため、これはライトマップされたオブジェクトでは機能しません。各面について、それぞれのライティングデータに基づくライトマップ内の独自のスペースが必要なのです。セットが必要になります。このため、新しくライトをベイクしたプレハブの設定に必要なのは、行方不明にならないようにテクスチャとその座標を保存して、それをプレハブにコピーすることだけです。チャンネルに書き込みます。メッシュを更新するためのコードは、次のように比較的単純です。modifiedUV2s;少しだけ説明を加えると、これはメッシュのオリジナルではなくコピーに対して実行されます。ベイキングプロセス中のメッシュの最適化が目的だからです。コピーが自動的に生成されてプレハブに保存され、新しいマテリアルにはカスタムシェーダーと新しく作成されたライトマップが割り当てられます。これでオリジナルのメッシュには触れないまま、ライトをベイクしたプレハブはすぐに使用できる状態になります。カスタムライトマップシェーダーこれでワークフローがとてもシンプルになります。グラフィックスのスタイルや見た目を更新するには、該当のシーンを開いて納得いくまで変更を加えたらコードを実行して、自動化されたベイクとコピーのプロセスを開始します。このプロセスが終了すればすべて完了です。ゲームでは更新されたプレハブとメッシュが、更新されたライティングで使用されるようになります。実際のライトマップテクスチャは、カスタムシェーダーにより追加されます。番目のライトテクスチャとしてモデルに適用します。シェーダーはとてもシンプルで短く、カラーとライトマップを適用するだけでなく、低負荷のフェイクスペキュラー/グロスエフェクトの計算を行います。"Diffuse"}次の画像は、上のシェーダーを使ったマテリアルのセットアップ画面です。つの異なるシーンを使います。私たちのゲームには熱帯、氷原、砂漠など、さまざまな生物群系があり、それに従ってシーンを分割しています。皆さんのゲームでは、要件に応じてシーン数は異なるはずです。つのライトマップを共有します。加わることになります。つのドローコールで実行できるようになりました。エディターのベイクレベル)すべてのタイルや建物が設定されているライトベイキングシーンには、ローカライズしたハイライトを生成するために光源を追加しています。いずれにしてもベイクダウンすることになるので、セットアップシーンには必要と思った分だけいくつでもライトを配置しても構いません。ダイアログで進めます。おかげで以下のことを忘れずにいられます。コピーしてプレハブを作成するすべてに正しく名前を付け、必要なファイルをバージョン管理システムからチェックアウトする(簡易ワークフローとしてのカスタムインスペクター)適切に命名されたプレハブがメッシュから作成されるので、ゲームコードでそれらを直接読み込んで使うことができます。このプロセス中にメタファイルも変更されるので、プレハブのメッシュへの参照が失われることもありません。このワークフローのおかげで、好きなだけ建物を調整し、好きなようにライティングして、スクリプトですべてのことを処理することができます。メインシーンに戻ってゲームを実行すると、何ら問題なく動作します。手作業で何か行ったり、他の部分を更新したりする必要はありません。動的オブジェクトやモーションを使用しにくくなることです。影を投影する要素はすべて、リアルタイムでライトや影を計算する必要があります。言うまでもなく、これは何としても避けたいものです。環境は静的で活気のない世界に見えてしまいます。見栄えするビジュアルを高速レンダリングで実現することが最優先なので、ある程度の制限は仕方ありません。した動きのあるスペースコロニーや都市という印象を生み出すためには、大量のオブジェクトをすべて実際に動き回らせる必要はありません。動かすものの大部分を影がなくてもよい、または少なくとも影がなくても気にならないものにします。つのプレハブに分けました。静的プレハブで、頂点の大部分とメッシュの複雑なビットがすべて含まれます。つが動的プレハブで、含まれる頂点はできるだけ少なくなるようにします。プレハブの動的な部分は、アニメーション化されたビットで、静的な部分の上に配置されます。一切ライトベイクされず、非常に高速で負荷が軽いフェイクライティングシェーダーを使って、オブジェクトが動的にライティングされているかのような錯覚を作り出します。"Diffuse"}また、オブジェクトには影を持たせないか、動くビットの一部としてフェイクシャドウを作成します。私たちのケースではサーフェスの大部分がフラットなので、これが大きな障害になることはありませんでした。(動的オブジェクトを追加で使用している建物)動くビットに影は付いていませんが、影が付いていないと知ったうえでよく見て、かろうじて気付く程度です。動的なプレハブのライティングも、完全にフェイクです。リアルタイムのライティングはまったく使われていません。最初に私たちは負荷を軽くするための近道として、光源(太陽)の位置をフェイクライティングシェーダーにハードコーディングしました。動的な値を使うより定数を使った方が、当然処理は早くなります。これにより基本的なライティング、メッシュの明るい面と暗い面が得られました。スペキュラー/グロスもう少し光沢を加えるため、私たちは動的オブジェクトと静的オブジェクトの両方のシェーダーにフェイクのスペキュラー/グロス計算を追加しました。スペキュラー反射は金属感を演出する効果があるだけでなく、表面のカーブを表現するのにも役立ちます。スペキュラーハイライトは反射の一種なので、カメラと光源の相対的な角度を正しく計算する必要があります。カメラが移動したり回転したりすると、スペキュラーは変化します。計算を行うすべてのシェーダーで、シーン内のカメラの位置とすべての光源へのアクセスが必要になります。ゲーム内では太陽は動かず、また、ディレクショナルライトとみなすことができます。して、ポジションと入射角が固定されているとシンプルに想定したことで、シェーダーを大幅に簡略化できました。Colonies』のカメラが、多くの都市建築ゲームと同じく見下ろし視点でシーンを映すタイプのものであることも功を奏しました。カメラは若干傾けたりズームインやズームアウトしたりできますが、上方軸を中心に回転することはできません。全体的に見れば、カメラは常に環境を上から見下ろしている状態です。スペキュラーの見た目を低負荷で偽装するため、私たちはカメラが完全に固定されていて、カメラとライトの角度が常に一定であるということにしました。この方法で、改めて固定値をシェーダーにハードコーディングして、低負荷のスペキュラー/グロスエフェクトを実現できました。(フェイクのスペキュラー/グロスエフェクト)スペキュラーに固定角を使うのは、もちろん技術的には正しくありませんが、実際にはカメラの角度がほぼ固定の場合と見分けはつきません。プレイヤーにはあいからわずシーンは問題なく見えるわけで、リアルタイムライティングではそれだけが重要なのです。リアルタイムビデオゲームでの環境のライティングは、物理的に正しくシミュレートされていることよりも、正しいように見えていることの方が常に重要なのです。つのマテリアルを(ライトマップと頂点に由来する多くのディテールと合わせて)共有していたので、私たちはシェーダーにスペキュラーの値をいつどこに、どのくらいの強度で適用すればよいのかを伝えるためにスペキュラーテクスチャマップを追加しました。チャンネルを使ってアクセスするので、座標セットを追加する必要はありません。それほどディテールもないので解像度を非常に低くでき、ほとんどスペースを使いません。自動ダイナミックバッチング機能を利用して、レンダリングをさらにスピードアップできました。ライトをベイクしたプレハブにライトをベイクしたプレハブを重ねるベイクした影は、どれも新しい問題を引き起こす可能性を秘めています。比較的モジュール化の度合いが高い建造物に使う場合です。ある時私たちは、プレイヤーが建築できる倉庫の前に、保管されている商品の種類を表示させようとしました。これが問題を引き起こしました。ライトをベイクしたオブジェクトにライトをベイクしたオブジェクトを重ねたからです。ライトのベイクに例外が発生したのです!別の負荷軽減テクニックを使ってこの問題に取り組むことにしました。多少の制限は我慢できる方向けこの方法でプレハブを構築してベイキングしたことで、ドローコール数を驚くほど少ない水準に抑えつつ、数百もの建造物がある巨大なマップを実現できました。方がたくさんのドローコールを使うほどです。レンダリングしなければならないマテリアルが少なければ少ないほど、ゲームのパフォーマンスは向上します。これにより、パーティクル、天候効果、その他の装飾的な要素を追加する余地が生まれます。維持したまま数百もの建造物が立ち並ぶ巨大な都市を作ることができます。(ライトをベイクしたプレハブを使ってプレイヤーが作ったコロニー)ゲームが快適に動けば良しとする賑やかな都市であふれる巨大な惑星をレンダリングするため、私たちはゲームに合わせたカスタマイズを行いました。自分たちのゲームで機能すれば良いという発想です。つにすることで、シェーダーの複雑さを大幅に軽減しました。これによりアングルが固定され、動的オブジェクトのライティングやスペキュラーの計算の観点から無駄を省くこともできました。動的オブジェクトの数を減らして、残りのオブジェウトは静的にバッチ処理しました。それから、少ないポリゴン数とカラーのみでビジュアルを構築するスタイルにより、さまざまな作業が楽になったことも言うまでもありません。ほとんどすべてのオブジェクトでマテリアルを共有でき、スタティックバッチングもダイナミックバッチングも可能になるからです。ここで紹介した解決策を、皆さんのゲームにまるごと転用することはできないでしょう。そのつもりで紹介したわけではないのですから。これらの解決策を、皆さんのゲームを最適化するベストな方法を探るためのたたき台にしてください。ゲームで切り詰められる要素や我慢できる要素を探し出して、それをゲームの高速化に役立てましょう。講演動画)詳細を見る今後のためにうかがいます。ニュース配信プライバシーポリシーおよび個人情報の取り扱いと利用に同意もうすぐです...入力したアドレスに確認メールをお送りします。ニュースの配信が始まります。おっと...支障がありました。一度やり直してください。その他の名称またはブランドは該当する所有者の商標です。OK弊社のウェブサイトは最善のユーザー体験をお届けするためにクッキーを使用しています。詳細については、クッキーのポリシーのページをご覧ください。