20200929のUnityに関する記事は10件です。

投稿日：2020-09-29T18:53:23+09:00

レンダリングレベルの設計方法

今回の主な話題：モバイルゲーム開発におけるPBRの適用性、レンダリングレベルの設計方法（発展編）、ハードウェアのGPU Instancingサポートの判断方法、回避する必要がある25個のDrawCall成長問題。

レンダリング

Q1:今はプロジェクトのレンダリングレベルを設計する方法を考えており、誰か経験のある先輩がShaderLODなどの方法を教えてください！他に何かアイデアはありますか？ありがとうございました！

私たちのゲームの効果レベル分けの内容を整理しました、参照できます。

レンダリング

Q2: 2017.2.0を使用して一枚のマップをレンダリングしましたが、なぜ時々にXiaomi 4のCamera.Renderは高い時間コストがあります？一つの空きシーンですが、なぜCamera.Renderの時間コストはそんなに高いですか？

一つの簡単なテストをしてこの問題を研究しました。すなわちシーンに一つCubeのみレンダリングします。

設備：
（1）Huawei 6Plus
（2）Xiaomi 4

Profilerのスクリーンショットは次のとおりです。
青枠：Huawei 6Plus
赤枠：Xiaomi 4

上図から見ると、Xiaomi 4のCamera.Render時間コストは不安定で、時々に10＋msのピーク値は出ます。

Unity Profilerをチェックしてまたは他の設備と比べると、次の2点はXiaomi 4で時間コストが不安定になる原因であることは分かりました。

1)Cullingが不安定
下図はXiaomi 4およびHuawei 6Plus設備で、Culling操作の時間コストの比較です。青枠はHuawei、赤枠はXiaomiです。Timelineからは、シーンSceneNodeの計算は原因であることが分かりました。

2)Drawingが不安定
レンダリングの時間コストも不安定で、下図のように：Timelineで「Xiaomi 4設備では、メインスレッドのレンダリングプロセスがサブスレッドの完了を待ってから後続の操作を実行することが多いこと」がわかります。しかし、Huawei 6Plusで同じアプリを実行する時この問題はありません。

Xiaomi 4:

Huawei 6Plus：

上記のテストをまとめします：
●CullingにあるSceneNode計算操作は、Xiaomi 4でより多くの時間のかかるCPUコストを伴うことがよくあります。
●Xiaomi 4でメインスレッドのレンダリングが子スレッドを待つ状況はよくあります。

上記の2点は問題の主な原因ですが、よりディープな説明は、おそらく携帯メーカーまたはチップハードウェアメーカーと連絡必要があります。ただし、これは簡単なテスト例で、複雑なシーンに適用ではない可能性がありますが、テストまたは分析方法は同じで、問題主が欲しいなら自分でテストして答えを見つけることができます。

レンダリング

Q3: 使用したUnity 5.5シーンにはレベル2のLODがあります。Lightmapを使用してシーンをレンダリングして、結果第二LODモデルがレンダリングされたシャドウ面は真っ黒でした。どうすればよいですか？
Untiy公式は、バージョン5.5ではLOD Lightmapをサポートしていません。バージョン2017.4でも、公式ドキュメントではLight Probesを使用することをお勧めします。
https://docs.unity3d.com/Manual/LODForBakedGI.html

もちろんこれも言いました：
“When you use the Progressive Lightmapper, there is no need to place Light Probes around the LOD Group to generate baked indirect lighting. However, to make Realtime GI affect the Renderers in the LOD Group, you must include the Light Probes.”

私たちもUnity 5.5バージョンも使用していますが、Progressive Lightmapperを試していませんでしたので、効果は分かりません。ですから、一つ目の解決策はUnity 5.6またはUnity 2017にアップグレードして、Progressive Lightmapperを試すことです。
Unity 5.5で実行したい場合は、ベイクされたscaleとoffsetを手動コピーして実現します。つまり、実行時に元モデルの照明マップ情報ををLOD低レベルモデルにコピーすることです。ただし、これには非常に強い制限があります：2つのモデルのUV2が完全に対応できることを確認する必要があります。そうしないと、UV2に混乱が生じる可能性があります。Simpylgonなどのミドルウェアを使用すると、UV2をできる限り変更しないでおくことが保証できます。

これには2つの問題があります。
●一つのコンポーネントの削除など、多くの面が削減されたモデルの場合、露出した面は以前にブロックされていたため、黒くなります。ただし、ほとんどの場合に削減された面が多いLODモデルは遠く離れており、一般的に納得できます。
●実行時に照明情報を設定するマテリアルは静的にバッチ処理できません。そうしないと、デバイスに問題が発生します。

もう1つ問題は実行時に変更されるため、エディターモードで設定コンポーネントを実行できるようにしないなら、プレビュー効果が正しくない問題が発生する可能性があります。実行状態では正しいことを保証できます。

オリジナルのLOD0ベイク効果：

LOD1は、黒を避けるためにベイクエフェクトに参加しません。

実行時のライトマップパラメーターを変更した効果。

ライトマップパラメーターを変更するComponentコード。
コード
public class RendererLightMapSetting : MonoBehaviour
    {
        public int lightmapIndex;
        public Vector4 lightmapScaleOffset;
        public void SaveSettings(SceneLightMapSetting setting)
        {
            if (!IsLightMapGo(gameObject))
            {
                return;
            }
            Renderer renderer = GetComponent<Renderer>();
            if (setting)
            {
                lightmapIndex = setting.GetGlobalIndex(renderer.lightmapIndex);
            }
            else
            {
                lightmapIndex = renderer.lightmapIndex;
            }
            lightmapScaleOffset = renderer.lightmapScaleOffset;
        }
        public void SetSettings(Renderer renderer)
        {
            if (renderer != null)
            {
                lightmapIndex = renderer.lightmapIndex;
                lightmapScaleOffset = renderer.lightmapScaleOffset;
            }
        }
        public void LoadSettings()
        {
            if (!IsLightMapGo(gameObject))
            {
                return;
            }
            Renderer renderer = GetComponent<Renderer>();
            renderer.lightmapIndex = lightmapIndex;
            renderer.lightmapScaleOffset = lightmapScaleOffset;
        }
        public static bool IsLightMapGo(GameObject go)
        {
            if (go == null)
            {
                return false;
            }
            Renderer renderer = go.GetComponent<Renderer>();
            if (renderer == null)
            {
                return false;
            }
            return true;
        }
        void Awake()
        {
            if (Application.isPlaying)
            {
                LoadSettings();
            }
        }
    }
そして、アーティストにワンクリックで設定およびクリーニングできる機能を提供します。ロジックは自分で作成できます。例えば、LODコンポーネントを修復する静的照明情報、LODコンポーネントを修復する静的設置など。
レンダリング

Q4: どの場合にTransparentのマテリアルがRender.OpaqueGeometryの過程中にレンダリングされますか？

Render.OpaqueGeometryとRender. TransparentGeometryの執行は、RenderQueue <2450によって区別されています。RenderQueueのサイズは、オブジェクトのレンダリングの順序を完全に制御できます。たとえば、半透明オブジェクトのレンダリング順序を不透明オブジェクトの前に調整しますこと、またはGrassをTerrainの前に調整しますこと。マルチレイヤーテクスチャを使用する一部のプロジェクトでは、比較的良い選択です。RenderQueueを使用してオブジェクトのレンダリング順序を制御し、RQを変更して特別な目的を実現します。

2D

Q5：以前、私はUWAの動画を見ましたから、このスクリプトをプリセットに掛けました。しかし、今回のテストの結果で解凍する時にこの関数がとても高いヒープメモリを占有していることがわかりました。この関数はアセットが解凍する時にもコールされますか？

さらに、昨日UWA GOTを使用して解凍中のヒープメモリの問題を追跡したところ、Webサイトで報告されたPolygonImageの問題が発生していませんでした。これはどうしてですか？

PolygonImageの実現は一つのMeshEffectとして対応するImageのジオメトリを変更します（四辺形をポリゴンに変更）。過程に一定量のヒープメモリ割り当てが発生します（ポリゴンが複雑になるほど、より多くのヒープメモリが割り当てられます）。
MeshEffectのトリガーは、対応するImageが再構築されたときにのみ発生します：アクティブ化、変更された色（透明度）、変更された長さと幅など。
ですから、大量のヒープメモリが割り当てられますから、この効果を頻繁に変更されるImageに使用することはお勧めしません。

しかし、問題主はUWA GOTでこれを発見していません。この原因は、PolygonImageを使用する一部のインターフェイスが開かれていない（アクティブ化されていない）可能性があります。

UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。

UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T18:06:21+09:00

パフォーマンス最適化、歩きは止まらないーーメモリ編2

前回の記事では、プロジェクト開発中のメモリ割り当て状況を紹介しました。その以外、開発チームが注意すべきより重要なところはまだ三つあります。それは、メモリリーク、Mono無効的なヒープメモリコスト、およびアセットの冗長性であります。これは、ほとんどすべてのチームが開発中に遭遇する問題です。今日は、これらの問題の解決策について詳しく説明します。

メモリリーク

メモリリークは、開発者がプロジェクト開発中に遭遇する最も頻繁や最も遭いたくない問題です。今から見れば、プロジェクトにメモリリークがあるかどうかを判断することについては、まだいくつかの誤解があります。

誤解１

プロジェクトのメモリ下がりは、シーンに出入りする前後に一貫ではありません。たとえば、シーンに入った後、メモリは40MB増加し、出た後は30MB減少しますが、システムに戻されないメモリが10MB残っているため、メモリリークが発生しました。

誤解2

プロジェクトがシーンに出入りする前後で、Unity Profilerのメモリ下がりは正常でしたが、AndroidのPSS値は完全に戻りませんでした（シーンを出た後のPSS値は、シーンに入る前のPSS値よりも高い）。つまり、メモリリークがあります。

上記は、開発チームが私たちにフィードバックする典型的な問題です。ほとんどの開発チームが同様の状況に遭遇すると思います。 ここで、上記の2つの状況のどちらもメモリリークを示していないことを説明する必要があります。メモリが一定期間に増加し続けても、メモリリークがあると単純に判断することはできません。メモリが完全に下がれないことを導く原因が多いです。例えば、後で使用しやすいためにロードされたアセットがメモリに駐在すること、Monoヒープメモリは上昇するだけで下降しないことなど、これらの状況がメモリの完全下がりに妨害があります。一般に、メモリがリークしているかどうかを判断するための推奨方法は次のとおりです。

1、アセット、特にテクスチャ、メッシュなどの使用状況を確認します。

UWAがやったプロジェクトのディテールな最適化の過程で、リソースリークがメモリリークの主な形式です。具体的な原因は、ユーザーがロードされたアセットを保存する（たとえば、Containerに入れる）が、シーンを切り替える時にはRemoveやClearしませんでした。そのため、エンジン自体でも、Resources.UnloadUnusedAssetsなどの関するAPIを手動的にコールしてもアンロードできず、リソースリークが発生します。プロジェクト内のリソースの量が多すぎて、リークされたリソースを見つけるのが難しいですから、この状況を確認することは非常に困難です。そのため、UWAレポートでは、プロジェクト内の各アセットの詳細なモニタリングを実施し、「ライブサイクル」指標を通じて、プロジェクト実行中における各アセットの使用範囲を明確に把握することができます。

このようにして、アセットの「ライフサイクル」属性を使用して、メモリ内に「常駐」しているアセットをすばやく確認でき、そのアセットが「プリロードする」アセットであるか「リークする」アセットであるかを判断できます。

同時に、プロジェクトで使用されるアセットの総数は多い場合、数百または数千であり、すべてのアセットを人工的に1つずつ確認するのは非常に面倒です。そこで、アセットの「シーン比較」機能をリリースしました。次の2つの方法でアセットを比較して、「リーク」の問題があるアセットをより迅速に見つけることをお勧めします。

●同じシーンまたは同じタイプのシーン間の比較

一般的に、ゲームプロジェクトのメインシティシーンやメインインターフェースシーンなどの同じシーンまたは同じタイプのシーンのアセット使用量はほぼ同じです。同じシーンのアセット情報を異なる時間で比較することにより、アセット使用量の違いをすばやく見つけることができます。このように、これらの「異なる」アセットの存在が妥当であるかどうかを判断するだけでよく、リークが発生しているかどうか、およびリークされていたアセットをすばやく究明できます。

●異なるタイプのシーン間の比較

一部の常駐アセット以外、タイプが異なれば、アセットの使用量も完全に異なります。たとえば、一つゲーム内のメインシティシーンと戦闘シーンでは、部分の常駐アセット以外に両者が使っている大部分のアセットは全然違っています。したがって、2つの異なるタイプのシーンを比較することにより、比較結果で「共通アセット」を直接表示して、それが実際に事前設定された常駐アセットであるかどうかを判断できます。そうでない場合は、アセットが「漏洩」している可能性が高いため、プロジェクトのアセット管理に盲点がないかどうかをさらに確認する必要があります。

2、ProfilerでWebStreamまたはSerializedFileの使用状況から検出します

AssetBundleの不適切な管理は、ある程度のメモリリークを引き起こす可能性もあります。つまり、前のシーンで使用されたAssetBundleは、シーンの切り替え中にアンインストールされず、次のシーンに移動します。この場合、Profiler MemoryにあるTake Sampleを使用して検出することをお勧めします。WebStreamまたはSerializedFileにあるAssetBundleの名前を直接に確認したら、「リーク」状況があるかどうかを判断できます。

3、Android PSS / iOSInstrumentからフィードバックしたアプリスレッドメモリで確認します

上記の「誤解2」を続けると、「Unity Profilerのメモリ下がりは正常でしたが、AndroidのPSS値は完全に戻りませんでした。」は可能です。この原因は、Unity Profilerがフィードバックするのはエンジンが実際に割り当てる物理メモリでありますが、PSSに記録されたものには、システムキャッシュの一部が含まれます。通常の状況では、AndroidまたはiOSはすべてのアプリのアンインストールデータを適時にクリーンアップしません。次回の使用をスムーズにするために、OSは一部のデータをキャッシュに入れます。自身のメモリが不足している場合、OS KernelはLowMemoryKillerみたいなルールを採用してキャッシュを照会したり、一部のプロセスを強制終了してメモリを解放したりします。だから、一回や二回の「PSS値は完全に戻らない」状況でメモリリークの問題を説明することはできません。
UWAが推奨する方法は、メインシティシーンと戦闘シーンなどの2つのシーンを切り替えることです。理論的に、同じシーンを複数回切り替えると、Profilerに表示されるUnityメモリが正常に戻れますなら、PSS / Instrumentメモリ値の変動範囲も安定する傾向があります。しかし、PSS / Instrumentメモリが増え続けますなら、注意を払う必要があります。この原因は、2つの可能性があります：

●Unityエンジン自体のメモリリーク問題。

この確率は非常に小さく、以前はいくつかのバージョンでしか発生していませんでした。

●サードパーティのプラグインを使用しているときにメモリリークが発生しました。

この可能性は高いです。ProfilerはUnity自身のメモリしか監視できず、サードパーティライブラリのメモリ割り当てを検出できません。上記のメモリの問題が発生した場合は、最初に使用しているサードパーティのライブラリを確認することをお勧めします。

無効なMonoヒープメモリコスト

現在、Unityで使用されているMonoバージョンには一つの大きな問題があります。メモリが割り当てられると、システムに戻されません。これは別の問題につながりますーー無効なMonoヒープメモリ。Monoによって割り当てられたヒープメモリですが、実際には使用されていないため、「無効」と呼ばれます。では、プロジェクトに「無効なヒープメモリ」が大量にあるかどうかを確認するにはどうすればよいですか？

UWAレポートでは、次の図に示すように、プロジェクト実行中のメモリ割り当て状況を提供します。その中に、青い線と紫色の線の分離状況は、無効なヒープメモリの割り当てサイズを反映しています。たとえば、図で選択した時点で、青い線のReserved Totalは現在のプロジェクトが占有している物理メモリの合計でありますが、紫色の線のUsed Totalは現在のプロジェクトが使用している物理メモリの合計であります。つまり、現在のプロジェクトの空きメモリは57.1MBです。（200.4-143.3）、これは主に2つの部分、空きUnityエンジンメモリと無効なMonoヒープメモリで構成されています。ぞの上、空きUnityエンジンメモリは17.1MB（92.0-74.9）であるため、現在選択されているフレームの無効なMonoヒープメモリは40.0MBです。さらに、図から、実行中に青い線と紫色の線は常に分離していることも分かりました。これは、「無効」状態になるMonoヒープメモリは常に存在していることを示します。メモリの「高価」モバイルデバイスにとって、これは非常に無駄なことです。

では、どうやって過剰な「無効なヒープメモリ」の割り当てを回避または削減できますか？UWAからの推奨方法は次のとおりです。

1.ヒープメモリの一次性の大き過ぎの割り当てを回避します。

Monoメモリの割り当ては「要求次第」で徐々に割り当てられます。ただし、大き過ぎの割り当てを一次性に開けると（例えば、一つの比較的大きいContainerをNewすることや一つの比較的大きい配置ファイルをロードすることなど）、必然的にMonoのヒープメモリが直接上昇することを導きます。そのため、開発チームは常にヒープメモリの割り当てに注意を払う必要があります。

2.必要のないヒープメモリのコストを回避します。

UWAレポートには、プロジェクト実行中のヒープメモリ割り当てTop10の関数をリストされています。文章の長さの限りで、ここでは繰り返しません。開発チームは前回のメモリ最適化に関する記事を見てください。

アセット冗長性

メモリ管理の方に、注意すべき点はまだ一つありますーーアセット冗長性であります。私たちがテストした多くのプロジェクトでは、95％以上のプロジェクトがさまざまな程度のアセット冗長性を持っています。いわゆる「アセット冗長性」とは、特定の時間にメモリ内に同じアセットの2つ以上のコピーが存在することを指します。この状況には、主に2つの原因があります。

1．AssetBundleのパッケージ化メカニズムが導く

一つのアセットが複数のAssetBundleファイルに入力されます。例えば、一枚のテクスチャが異なるNPCによって使用され、各NPCが個別のAssetBundleファイルに作成されている場合、テクスチャの依存関係パッケージ化しないなら、テクスチャは異なるNPCAssetBundleファイルに表示されます。これらのAssetBundleがメモリに次々にロードされると、メモリにテクスチャアセットの冗長性があります。これについて、開発チームにアセットの冗長性問題を発見した後に関するAssetBundleの作成流れを検査することをお勧めします。

同時に、UWAレポートで各アセットに一つの判断標準を導入しましたーー「ピーク数」。これは、同じフレーム内の同じアセットの最大数を指します。1より大きい場合は、アセットに「冗長アセット」がある可能性が高いです。この列で並べ替えると、プロジェクトのアセットの冗長性をすぐに確認できます。

2．アセットのインスタンス化が導く

Unityエンジンでは、特定のGameObjectのアセット属性を変更すると、エンジンはこのGameObjectのMaterialやMeshなどのアセットを自動的にインスタンス化します。マテリアルを例にすると、開発中にこのような仕様はよくあります：キャラクターが攻撃されたら、マテリアルの属性を変更して特定の攻撃を受ける効果を取得します。この仕様により、エンジンは特定のGameObjectbに一つのMaterialを再インスタンス化し、サフィックスにinstanceの文字を付きます。それ自体は特に大きな問題ではありませんが、Material属性を変更する要求のあるGameObjectが増えていると（例えばARPG、MMORPG、MOBA等ゲーム）、メモリの冗長性が大幅に増加します。

下図のように、ゲームが進行するにつれて、インスタンス化されたMaterialアセットは333に増加します。Materialは多くのメモリを占有しませんが、過剰な冗長リソースは、Resources.UnloadUnusedAssetsAPIのコールする効率にかなりの圧力をかけています。

一般的に、アセット属性の変更状況はランダムではなく固定されています。例えば、GameObjectが攻撃されたときに、そのMaterialの属性変更は受ける攻撃タイプ次第で三つの異なるパラメータ設定があります。では、その要求に対しては、3つの異なるMaterialを直接作成し、Material属性を変更するのではなく、Runtime状況でコードを介して対応するGameObjectのマテリアルを直接置き換えることをお勧めします。こうすれば、何百何千個のinstance Materialがメモリ内で消え、代わりにこの三つのMaterialアセットがあることがわかります。この利点は、コチラまで読むあなたに、もう説明する必要はないでしょう。

：）

UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。

UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T17:12:12+09:00

UnityPluginのデバッグ

windows

UnityでWindows向けNative Pluginをデバッグする

UnityネイティブプラグインをVisual Studio でステップ実行デバッグする
http://satoshi-maemoto.hatenablog.com/entry/2019/07/30/155847

Unity/Android

Unity + Visual Studio環境のAndroid実機デバッグ方法

Unity-[Build Settings]のオプションはここを参照する

・Export Project : AndroidStudio用のprojectを出力する
・Symlink sources :

・Wait For Managed Debuggerにチェックを入れておくと、デバッガーが起動するまでアプリの開始を待ってくれるので、アプリ起動直後の挙動を実機で確認することができる。

・Scripts Only Build : 現在のプロジェクトのスクリプトだけをビルドします。

AndroidStudio : 別モジュールのC++のステップ実行

デフォルトでは非対応

 UnityでGradleを使ったAndroidプラグイン開発

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T15:34:00+09:00

[Unity] Component GUI Layer in Main Camera for Scene Assets/****.unity is no longer available.

TL;DR

Cameraにアタッチされている，Flare Layerを削除(無効化)すると治る！

なんでなったの？

Unityのバージョンを2019.4.8f1にあげたところ，エラーが発生しました．

ビルドするときに，一応ビルドは完了するが，毎回このエラーが大量にでるのはうっとうしいので，使っていないなら消したほうがいいと思います．

やり方

無効化するときは，チェックボックスを外すとできます．

削除するときは,　右の3点マークをクリック(or右クリック)でremove componentを選択するとできます．

無効化している時点で，使っていないはずなので，削除してあげるほうがいいと思います．

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T15:07:53+09:00

[unity/VRC]巨大なアバター(bot)がいるワールドを作ったので簡単に手順を書いた

0.前書き

非実在レベルのおっきな女の子のVRChatのワールドがもっと増えて欲しい。つまりは巨大娘よな。
ということで作ったのですが、なかなかに躓く事が多かったのでそこに辿りつくまでに
苦労した点をピックアップしてHowToを作ろうかなと思った次第。
調べればすぐに出てくるものは割愛します。
（ほんまワールド系の情報（文章）少なすぎるよぉ）

目標

10000倍の女の子の凄さをVRC(public)で味わえるようにする。

10000倍で動けば10も100も1000も一緒だからね。10000が一番大変。
（100000は…たぶん死ぬほど思いのでpassさ...)

対象

VRCにアバター上げたことあるけどワールドは作った事はないレベル

用意するもの

●お金（MAX約１万円※）
　Assetとかはわりとセールするので、狙えば安くなる。
●Unity
　VECだから当たり前だよね。
●VRMアバター
　おっきくさせたいアバター。
●のVRC系Asset(VRCSDK2package)
　アバター入れたなら持ってるはず。
●アニメーション作る系のソフトもしくはasset
　頑張ればblenderでいけるらしいけど、さすがに面倒なので、僕はVeryanimation（Asset）買いました。
●terrain系asset
　それなりの地形を作る用。
　面倒なので地形自動生成のassetを入れると楽。僕はGaia2のAsset買いました。
　そこにこだわらないなら不要。
　（だけど、やっぱ山とか海とかあったほうが気分が盛り上がるので良いです）
●その他Asset
　あとはお好みでこだわりたければこだわってください。
●大きなディスプレイ
　２画面あると捗ります。分割して色々な画面を外出しして見れるので。

１．ワールドの基盤を作ろう

とりあえず下準備しましょう。

必要なassetやパッケージをインポートしよう

　アバター作った人ならわかると思うので割愛

必要なprefabを突っ込もう

　VRCで使うならVRC_WORLDというprefabが必須なので入れましょう。
　ここがスポーン位置になります。
　（VRChat Examplesの中にあります）

地形を作ろう

　人によって違うと思うので基本的に割愛。
　Gaia2の場合は「Gaia2 作り方」とかでググってください。
　（僕もまだよくわかってないので）
　地形を大きくしすぎると重くなるのでほどほどに。
　テストが大変になります。

建物を作ろう

　好きなAssetを使っていい感じのにするといいですね。

アバターを入れよう

　適当にVRMファイルをD&D。

２．巨大化させてみよう

巨大娘ちゃんを生み出してみましょう。
animationとanimator(animator controller)を利用して仕掛けを作ります。

animationとanimatorの関係を知ろう

　animation…アバターのアニメーション。そのまま。ポーズもアニメーションに含まれる。
　animator…アニメーション遷移の管理。フラグによって行先を決めたりする。
　そんな感じ。

とりあえずアバターを巨大化させてみよう

　とりあえずアバターを巨大化させてみましょう。

まずは棒立ちにさせてみる

　まず下のAssetに適当なAnimatorを作りましょう（右クリック、Create→AnimatorController)
　そうしたらScene（左画面）にあるアバターのprefabをクリックして、
　InspectorのAnimatorのコンポーネントのControllerに作ったAnimatorを突っ込みましょう。
　これでこのアバターはこのanimatorControllerに準じて動く。ということが紐づけられました。

　そしたら上のタブからanimatorをクリックしましょう。
　そうするとanimatorの画面が出てくるので適当な所で右クリックして、CreateState→Emptyを選びましょう。
　するとEntryから線がのびたオレンジ色の箱が出てくると思います。このオレンジ色の箱はリスポーン直後の初期アニメーションです。
　かなり重要になるのでよく覚えておきましょう。

　オレンジの箱を選択した状態でinspector画面（右画面）を見るとMotionの欄がNoneになっていると思います。
　ここに実際のanimationをぶち込むことになります。
　でもまだanimationはないのでExampleのモノを適当借りましょう。右のボタンを押してIDLEってやつを選びましょう。
　これでキャラクターは棒立ちになったと思います。
　（IDLEで実際にやってないので嘘だったらごめんなさい。仕組みだけ理解してくれればいいです。どうせ仮なので）

アバターを巨大化させるアニメーションを作ろう

　animator画面で上と同じ要領でもう一つ箱を作ってください。そうすると灰色の箱ができると思います。
　そしてそこにぶち込む為のアニメーションファイルを作りましょう。
　作り方はAsset画面で右クリック→Create→Animationです。
　作ったら灰色の箱のInspectorにあるMotionにぶち込みましょう。
　そうしたら、Animationタブをクリックします。（Sceneでアバターを選択していること）
　Animation画面ではアバターに紐づいたアニメーションを上のタブで選択できます。
　そこで今作ったアニメーションを選択しましょう。

　何もないのでAdd Propatyからtransformation→Scaleを選択しましょう。
　そうしたら、右のタイムラインの白線を動かして、適当なタイミングまで動かします。
　動かしたら、ScaleをXYZ軸すべて大きくしましょう。適当です。
　これで大きな女の子になるアニメーションができました。
　ポーズが嚙み合ってないと思いますが、気にせずに。
　とりあえず、基本はこれだけです。
　また、大きくなる速度に変化をつけたい場合は、Animation画面の下にあるタブから
　Curvesを選んで好みの曲線に変えましょう。

３．アニメーターのフラグ管理をしよう

　今のままだとVRCに入ったタイミングで直ぐに大きくなってしまうので、
　フラグが立った時に大きくなるようにしよう。
　そろそろ勝手がわかってきたと思うのでちょいちょい省きます。

スイッチを作ろう

　何でもいいのでオブジェクトを作ってスイッチにしよう。
　オブジェクトのInspectorのAdd Componentをクリックして、VRC_Triggerを選択しよう。
　VRC_Triggerを選択しよう。VRCTriggerでOnInstantを選択。
　（これはクリックするとフラグが入るタイプ）
　その中（タブ）にあるInterectionTextは近づいた時にでる単語。
　そしてActionsにはAnimationBoolを選択してReceiversにアバターを選択、
　Variableはフラグ名なので自分で決めよう（忘れないように）。
　Operationはとりあえずtrueで。
　これでスイッチの完成

スイッチに対応するフラグを作ろう

　アバターのAnimator画面左側にParametersタブがあるのでそれを選択して、追加する。（bool)
　名前を先ほどのスイッチと同じ名前でセットしよう。間違えると動作しないので注意。
　（右側のチェックボックスはよくわからないけどチェックしない方がよさそう）

Animatorでフローを作って、条件をセットしよう

　Animatorの箱から別に箱に遷移する為には、フローを作ってあげる必要がある。
　まず伸ばしたい箱を右クリックしてmakeTransitionを選択。
　宛先まで伸ばしてあげればOK。
　今回だとIDOLから巨大化の箱に伸ばしてあげる。

　そして条件は中のConditionsでセットできるのでtrueになったら巨大化するようにしてあげよう。

あれ？ループするんだけど。

　この状態で動かしてスイッチを入れると巨大化するけど、
　おそらく巨大化アニメーションがループしてしまう。
　これを解除するのはanimatorで該当の箱をダブルクリックしてLoopTimeを外してあげれればOK。
　これで基本的なanimationとanimatorの設定方法が雰囲気理解できたと思う。

4.アニメーションを作ろう（Very Animation)

　Blenderとかでの作り方はようわからんのでvery Animationでの話
　基本的にバグらないようにするためにやっちゃいけない事とかを書く。

とりえあず適当に動かしてみよう

　まずは動かしてみよう。でチュートリアル動画とか解説ページをサクサクっと読んでみよう。
　で実際にちょっと動かすと凄い便利。簡単にアニメーション（ポーズ）が作れちゃう！！
　ここでIKとかの意味を理解出来ておくと良い。
　（IKは子ボーン主体で親のボーンに自動的に補正をかけてくれるやつ。のはず）

とりあえず使っとけ機能

　●OptionalのMirror
　　左右反対で色々やってくれるすごいやつ。手の動きはこれがないとやってられない。
　●PoseのSave機能
　　その時のポーズをSaveしてくれる(asset形式)
　　後ほど使いたい時やポーズは同じだけど、アニメーションの途中で分岐かけたい時に重宝する。
　●selection
　　実際にやるとわかるがボーンの角度とかの調整は謎のフィルターに阻まれる事が多いので、
　　selectionで変更するのが楽。

Conflictに気を付けよう

　VeryAnimationを起動した状態でTransformation系をいじろうとすると、Conflictと表示されて拒否される。
　なので、位置・方角・大きさを変更する時はVeryAnimationを切った状態で行おう。
　（RootXとかはいじらない方がよさそう。リファレンス読んだ感じ。わからないけど）　　

巨大アバターでは使ってはいけない機能

　Collision…色々と動かなくなるのでNG
　IK…バグるのでNG

その他よくわからないけどやってること

　アニメーションのLoopを設定する画面の下のRoot云々については、リファレンス読んだ感じ
　全部ONにしてOriginalにしておくとよさそう。よくわかってないけど。

5.超巨大アバターをちゃんと見るために

　ここを書く為に書いたと言ってもよい。
　だって書いてないんだもん。

とりあえず1万倍アバターを作ってみてみよう

　やってみましょう。
　なんか途中で切れてるし、途中で色がなくなっていると思います。
　これを解消していきます。

Cameraの設定を変えて、見切れないようにしよう。

　まず、VRC_WORLDのRefarence CameraにCameraをセットしよう。
　これはVRCプレイヤーの視点について、どれを参照しますか？という内容。

　で、CameraのClipping Planesのfarの値を十分に大きくしよう。
　これはどこまで見える用にしますか？という値なので大きくすると見切れにくくなる。（なお処理速度）

Fogの設定を変えて色がなくならないようにしよう。

　windowからRending→LightingSettingを選択。
　FogのEnd欄を大きくすると色がなくならなくなる。
　いい感じの値にすると大きさが際立って凄いので調整しよう。
　面倒だったあら切ってもいい。

ついでに

　Gaia2持っている人限定になるが、GX設定のSkies設定のocullusionの部分を入れて、
　色々調整するといい感じの色合いになったりするのでお試しあれ。
　

6.アップロード

　規約違反してないことを確認して、アップロードして終わり！終了！！
　みんなたくさんつくってアップロードしてくれよな！遊びに行くから！（instanceで）

おまけ：今のところわかってないこと

　情報プリーズな話
　●エフェクトのかけ方
　　魔法陣とかさ。欲しいじゃん。そういうの。
　　オブジェクトのスタートとかエンドの仕方がよくわからないので、
　　有識者助けて…。
　●オブジェクト（スイッチ）の一時的撤去
　 DestroyObjectで消して、Prefab化したやつをSpawnさせるのかと思ったんだけど、
うまくいかなかったので謎。
●テキスト出せるのか。
　やっぱシチュエーション楽しむにはテキストとか欲しいじゃん？
　音声はできるけどさ。テキストほしいよね。できないのかな？

とりあえずザクザクっとメモみたいな感じになったけど、
こんな感じで終わり。
とりま作ったワールドの参考動画。
(publicにするにはtrustレベルが足りなかったよ…悲しいね)
[https://youtu.be/yTGI9LVi92E]

よくわからねぇとかあったらコメントくれればできる限り回答します。
　

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T14:43:22+09:00

説明書に載ってない本当のClothコンポーネント～VRChatで使うClothコンポーネント～

（2020/09/29 仮公開。少しずつ参考画像などを増やしていきます。）

VRChatでの揺れ物表現、その中のClothコンポーネントについての深堀りです。

公式ドキュメントはこちらですが、ご覧の通りほとんど説明らしい説明がありません。これだけで使いこなせというのはあまりに無茶なもの。他の情報源に当たるほかありません。

Unityは物理シミュレーションにPhysXを利用していますが、公式ブログからUnity 2019.1以前ではPhysX 3.4のPxClothを、Unity 2019.2以降ではPhysX 4.xのNvClothを使用していることがわかります。

Unity 2018 4.20f1を使用するVRChatではPxClothことPhsyX 3.4のClothモジュールを参照することになります。PxClothのドキュメントはこちらで見られます。

TL;DR

Clothは布のリアルタイム演算のためのコンポーネント

1シーンに頂点数2000、Solver Frequency 300(Hz)で12個が目安

Self-Collisionは演算時間の大部分を占める。

目安を守って正しい設定をすれば、リアルで高速な布シミュレーションができる。

前提

執筆時点の環境は以下のとおりです。

Unity 2018 4.20f1

VRChat 2020.3.3p1, build 994

VRChatでの揺れ物

Unityで髪の毛や尻尾、衣装などを揺らす揺れ物表現には様々な方法がありますが、VRChatで使えるものとなるとかなり絞られてきます。有料アセットであるDynamicBone、Unity標準のCloth。他にもJointを使った方法なども見られますがここでは触れません。

DynamicBoneは有料アセットながら様々なVRChat向けアバターに採用されており、動作の安定性や何より資料の豊富さが利点と言えます。一方でボーン単位の処理のために1次元的な構造となり、平面的な物体での衝突判定は不得手なようです¹。例えばスカートと脚の接触では、大きく脚が動いた際にスカートを突き抜けてしまいます。

一方、Unity標準搭載（つまり無料）のClothコンポーネントは布に特化したリアルタイムシミュレーションを提供します。布らしく上下左右が繋がっており、相互に作用し合います。基本的にはコライダーが突き抜けることもありません²。しかしながら利用者が少ないのか資料が少なく、何よりUnity公式のドキュメントも明らかに説明が足りていません。そこで、Unity内部で利用されているPxClothのドキュメントやこれまで筆者が実験した結果をもとにClothコンポーネントの概要を記すことにします。

Clothは重いのか？

特にVRChatに関する情報では「Clothコンポーネントは重い」といった声がよく聞かれます。ですが、Clothはリアルタイムシミュレーションのためのコンポーネントであり、十分に軽量化されています。接触ありのスカートの表現においては、他の手法より軽量化が見込めることが示唆される実験結果³もあります。

Clothコンポーネントは一部のプロパティーが計算量に大きく影響し、またパラメーターの意味が十分に説明されていません。このため、本来の設計から外れた使い方によって「重いCloth」が発生しているのではないでしょうか⁴。

プロパティー

まずはClothコンポーネントの各プロパティーについてその概要を記します。Unity公式のドキュメントをもとに、PhysXのドキュメントで補完したものになります。

Stretching Stiffness / Bending Stiffness

直訳すると引張剛性と曲げ剛性で、伸びにくさと曲がりにくさを0～1で設定します。小さいほど柔らかく、大きいほど固くなります。1だとほとんど動きませんが、小さすぎると形が崩れてきます。どちらも0.8から始めると良さそうです。

PxClothにおけるDistance Constraintsを設定していると思われます。Stretching Stiffnessが縦横の接続、Bending Stiffnessが縦横ひとつ飛ばしの接続に対応するはずです。対角線からなるねじれに対するパラメーターは存在しないようです。

Use Tethers

テザー制約を有効化します。PxClothは省略されたシミュレーションのために必要以上に伸びることがあります。テザー制約はこれを防止するもので、計算量が非常に少ないものです。有効化すると頂点が元の位置から離れ過ぎないようになります。基本的にはTrueのままで使うべきでしょう。

Use Gravity

重力を有効化します。無重力世界に生きている人以外はTrueにしましょう。

有効にするとシーン（ワールド）の重力加速度が適用されます。無重力のシーンでは0に、反重力では上方向の力がかかります。
⁵これを無視したい場合は無効にし、External Accelerationを使用することもできます。

Damping

速度の減衰係数です。各頂点の揺れの収束が早くなる。高すぎるとコライダーについて行けずに突き抜けてしまいます。0.1～0.5程度で試すと良さそうです。

External Acceleration / Random Acceleration

固定か、ランダムな加速度（力）を加え続けます。特別な表現をする場合を除いて0にします。

World Velocity Scale / World Acceleration Scale

速度、加速度の影響量⁶を調整します。どちらも0にすればどんな激しい動きでもめくれ上がる事はありません。特にVRChatではワープのような移動が頻発するため、制御が難しいと感じたら0すると良いでしょう。布の質感に応じて0.1～1.0の範囲で調整すると良さそうです。

Friction

コライダーとの摩擦係数です。微妙な差ではありますが、引っかかりが気になるなら0に、ひかっけたいなら1にしましょう。

Collision Mass Scale

各頂点の質量を増やします。布の重さの表現に使うものと思われます。ドキュメントによれば、使う場合は20から試すと良いそうです。

Use Continuous Collision

連続的接触を有効化します。高速で動く物体に対しての接触判定の精度が上がります。計算量は2倍になります。

Solver Frequency

計算の頻度で単位はHzです。Clothの挙動と計算量に大きく関わります。この値を大きくすることで改善する挙動が多いですが、計算量に直結するため他の方法を用いるべきです。一般的には120～300です。計算量はこの値に比例して増えます。

Use Virtual Particles / Virtual Particle Weights

バーチャル・パーティクルによって衝突判定の密度を上げます。Solver Frequencyや頂点数を増やさずに突き抜けを防止する機能です。衝突時だけに周囲の3頂点から生成されます。基本はTrue、Weightsはそのままにするべきです。

バーチャル・パーティクルの位置はVirtual Particle Weightsで定義されていますが、Unity 2018 4.20f1では3重になっているようです。バグでしょうか。

Sleep Threshold

スリープ状態になる頂点速度のしきい値を設定します。目に見える変化は少ないですが、現在1に上げて運用中です。

Capsule Colliders / Sphere Colliders

布と接触するコライダーを設定します。利用できるコライダーはカプセル、スフィア、テーパーカプセル（スフィアのペア）の3種類です。カプセルはテーパーのないテーパーカプセルの簡易表現と考えられます。ClothのコライダーはRigidBodyのそれとは別の概念であり、その形状だけが使われます。他のRigidBodyへの影響を避けるためにIsTriggerを有効にするべきでしょう。また、テーパーカプセルは同じスフィアコライダーを共有して連続した形状を作成できます。PxClothはこれを使うように推奨しています。

Constraints

Cloth全体のパラメーターの他に、頂点ごとの制約を加えられます。Max DistanceとSurface Penetrationの2種類が利用できます。
これらはPxClothの上に実装されたUnity独自の機能でありながら、ドキュメントがほぼ存在しません。この仕様を探るには、コミュニティーフォーラムに投稿されたUnity5に関する解答が参考になります。（情報提供：いしだえいとさん）

画像：https://answers.unity.com/questions/956610/excluding-vertices-from-cloth-colliders-in-unity-5.html より引用

Max Distance

頂点が元の位置から移動できる最大の距離を設定します。単位はmで、0～無限大が設定できます。オブジェクトのスケールの影響を受けます。スカートのウェストなど、固定する部分は0にします⁷。その他の部分は挙動の調整に使われたりもします。0で固定されていても、コライダーの影響は受けます。

PxClothのMotion Constraintsを簡略化したものと考えられます。中心がメッシュの頂点座標、半径がMax Distanceに対応します。

Surface Penetration

複雑な割に解説が存在しない制約です。その上、使い方を間違えるとどこかで頂点座標がNaNになり、メッシュが消滅します。値は0～無限大で、単位はmだと思われます。

上記の画像を紐解くと、メッシュの「内側にめり込める距離」と考えられます。頂点の法線の反対方向に移動できる距離を制限します。法線方向には制限しません。片側に限定したMax Distanceとも言えます。

PxClothにはこれを直接実現する機能は存在していません。そのため、Separation Constraintsを使って頂点が侵入できない球を設置しています。この半径はMax Distanceの2倍で、その表面で最も近い点と頂点との距離がSurface Penetrationとなります。半径がMax Distanceに依存しているため、Max Distanceが初期値の無限大のときこの球の半径は無限大となり、頂点はどこにも存在できなくなります。このためNaNが発生すると考えられます。

Self Collision / Inter Collision

PxClothのドキュメントに

計算の大部分を占める可能性がある

とある通り、重い処理です。よくわからずに使うべきではないと思われるのでここでは省略します。

パフォーマンス（軽量化）

PxCloth、すなわちClothコンポーネントの計算量は頂点数とSolver Frequencyに比例⁸します。Continuous Collisionで計算量はさらに2倍になります。PxClothのドキュメントによれば2000頂点、Solver Frequency 300Hzが目安になり、12個までリアルタイムにシミュレーションできます。頂点数が多いほど、Solver Frequencyが高いほどリアルなシミュレーション結果に近づきますが、その分負荷も激増します。これらは可能な限り低く抑え、他のパラメーターで調整しましょう。

具体的な値は示されていませんが、Self CollisionとInter Collisionは他の計算よりかなり重い処理になります。

メッシュの頂点とClothパーティクル

ここまで頂点という表現を使ってきました。各ドキュメントを読んでいる方は違和感を覚えたことでしょう。Clothコンポーネントのシミュレーション対象はパーティクル（UnityのParticle Systemと混同を避けるため、以降はClothパーティクルとします）と表現されています。これは、内部で使用されているPxClothはメッシュと関係なく任意のClothパーティクルをシミュレーションの対象としているためです。この概念を利用すれば、レンダリング用の高解像度なメッシュとシミュレーション用の低解像度のClothパーティクルを組み合わせることができるはずです。しかし、UnityのClothコンポーネントはメッシュの頂点をすべてClothパーティクルにしてしまいます。結果としてメッシュ自体のモデリングにも頂点数の制限が課されてしまっています。資料の少なさに加えて、こういった制約がClothコンポーネントのハードルを高めているのかもしれません。

まとめ

ToDo: いかがでしたか？ってひつようですか？

DynamicBoneの詳しい資料を見つけられていないので、あくまで動作から見た推測です。 ↩

あまりにも激しいワープのような移動があると突き抜けてしまい、かえって突き抜けないことで元に戻らないという特性もあります。 ↩

https://twitter.com/y_esnya/status/1291638689571827713?s=20 ↩

2020/09/29現在「VRChat Cloth」で見つかる多くの記事で計算量を激増させる値が記載されています。 ↩

情報提供：いしだえいとさん ↩

RootBoneの？ ↩

どこも固定しなければ当然どこまでも落ちていきます。 ↩

「概ね比例」 ↩

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T13:24:39+09:00

Unity2019.4.1 Visual Studio Codeでのコード補完（インテリセンス）が聞かない場合

問題

Unityのバージョンアップを行ったらVScodeでインテリセンスが効かなくなっていた。
※インテリセンス（コード補完）・・・クラス名や変数名などが予測で表示される機能

確認環境

Unity2019.4.1f1
macOS Catalina 10.15.6
Visual Studio Code 1.49.2

解決方法

Package ManagerにデフォルトでVScodeをサポートする様になっていたのでそれが問題を起こしていた様だ。

対応方法は
[Unity] -> [Preferences] -> [External Tools]
を開いて

Genarate .csprj files for のチェックをいれる。

これでvscosdeを再起動すると直りました。

Genarate .csprj files forがない場合はPackage Managerから「Visual studio Code Editor 」をインストールする事で表示されます。

Package Managerは
Window -> Package Manager
から選択して

RemoveやInstallが可能です。

以上

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T13:24:39+09:00

Unity2019.4.1 Visual Studio Codeでのコード補完（インテリセンス）が効かない場合

問題

Unityのバージョンアップを行ったらVScodeでインテリセンスが効かなくなっていた。
※インテリセンス（コード補完）・・・クラス名や変数名などが予測で表示される機能

確認環境

Unity2019.4.1f1
macOS Catalina 10.15.6
Visual Studio Code 1.49.2

解決方法

Package ManagerにデフォルトでVScodeをサポートする様になっていたのでそれが問題を起こしていた様だ。

対応方法は
[Unity] -> [Preferences] -> [External Tools]
を開いて

Genarate .csprj files for のチェックをいれる。

これでvscosdeを再起動すると直りました。

Genarate .csprj files forがない場合はPackage Managerから「Visual studio Code Editor 」をインストールする事で表示されます。

Package Managerは
Window -> Package Manager
から選択して

RemoveやInstallが可能です。

以上

　 Tweet
Qiitaで続きを読む

投稿日：2020-09-29T08:31:55+09:00

UnityChanSSUをAndroid実機ビルドした際シェーダのコンパイルエラーで失敗した時の対処法

個人的に偶然キレイなビジュアルが作れたので、PCではなくスマホで動かしたくなりました。

購入したUnityアセットを組み合わせたら、UnityChanのダンス影練に遭遇みたいな絵になった。#Unity #madewithunity pic.twitter.com/u7wKPoiN8H
— 大庭俊介@UXエンジニア (@ohbashunsuke) September 24, 2020

Androidビルドした所、UniversalToonシェーダのコンパイルエラーで失敗。

Shader error in 'Universal Render Pipeline/Toon': invalid subscript 'vertexSH' at /Unityプロジェクトまでのパス/Packages/UnityChanToonShaderVer2_Project-release-urp-2.2/Runtime/Shaders/UniversalToonBodyDoubleShadeWithFeather.hlsl(41) (on gles3)

上記のようなエラーが出力されていました。

シェーダの確認

エラー内容に従ってシェーダを調査します。

UniversalToonを選択してインスペクタを確認。

おおお、、エラー沢山。。。
とりあえずinvalid subscript 'vertexSH'が原因ぽい。

シェーダのReimportで解決

UniversalToonを右クリックからReimport実行。

なぜかと言われると答えられませんが、UniversalToonシェーダをReimportすると直ります。

するとこのようにきれいなインスペクタに戻ります。

ビルドは成功しませんでした

インスペクタ上ではコンパイルは成功しているのですが、実機ビルドでは失敗します。また、再度シェーダのインスペクタを見てみるとエラーは元に戻っていました。

OpenGLES3.1をターゲットにする

Require ES3.1にチェックを入れることでビルドが成功しました。
詳しく調べられてはいませんが、ES3.0以下では対応していないシェーダがあったということだと思われます。

無事に動いた！！

無事にUnityChanSSUがAndroid実機で動くようになりました。

何もチューニングせずにPixel3aで動かしてみたが6FPSくらいしか出なかった。。。(重いだろうな〜っていうことは分かってた。)
何が一番のボトルネックなのか調査してみよう。(おそらくGPU負荷だと思うけど)。#Unity #unitychan pic.twitter.com/4j0RR0E9xQ
— 大庭俊介@UXエンジニア (@ohbashunsuke) September 28, 2020

　 Tweet
Qiitaで続きを読む

20200929のUnityに関する記事は10件です。

人気のプラグインの紹介（アセット編）

Mesh Baker

Texture Packing

Mesh Batching

Skinned Meshのバッチ処理

SimpleLOD

バッチ処理モデル

ベーキングアトラス

モデルの簡易化

レンダリングレベルの設計方法

レンダリング

レンダリング

レンダリング

レンダリング

2D

パフォーマンス最適化、歩きは止まらないーーメモリ編2

メモリリーク

誤解１

誤解2

1、アセット、特にテクスチャ、メッシュなどの使用状況を確認します。

●同じシーンまたは同じタイプのシーン間の比較

●異なるタイプのシーン間の比較

2、ProfilerでWebStreamまたはSerializedFileの使用状況から検出します

3、Android PSS / iOSInstrumentからフィードバックしたアプリスレッドメモリで確認します

●Unityエンジン自体のメモリリーク問題。

●サードパーティのプラグインを使用しているときにメモリリークが発生しました。

無効なMonoヒープメモリコスト

1.ヒープメモリの一次性の大き過ぎの割り当てを回避します。

2.必要のないヒープメモリのコストを回避します。

アセット冗長性

1．AssetBundleのパッケージ化メカニズムが導く

2．アセットのインスタンス化が導く

：）

UnityPluginのデバッグ

windows

Unity/Android

AndroidStudio : 別モジュールのC++のステップ実行

UnityでGradleを使ったAndroidプラグイン開発

[Unity] Component GUI Layer in Main Camera for Scene Assets/****.unity is no longer available.

TL;DR

なんでなったの？

やり方

[unity/VRC]巨大なアバター(bot)がいるワールドを作ったので簡単に手順を書いた

0.前書き

目標

10000倍の女の子の凄さをVRC(public)で味わえるようにする。

対象

用意するもの

１．ワールドの基盤を作ろう

必要なassetやパッケージをインポートしよう

必要なprefabを突っ込もう

地形を作ろう

建物を作ろう

アバターを入れよう

２．巨大化させてみよう

animationとanimatorの関係を知ろう

とりあえずアバターを巨大化させてみよう

まずは棒立ちにさせてみる

アバターを巨大化させるアニメーションを作ろう

３．アニメーターのフラグ管理をしよう

スイッチを作ろう

スイッチに対応するフラグを作ろう

Animatorでフローを作って、条件をセットしよう

あれ？ループするんだけど。

4.アニメーションを作ろう（Very Animation)

とりえあず適当に動かしてみよう

とりあえず使っとけ機能

Conflictに気を付けよう

巨大アバターでは使ってはいけない機能

その他よくわからないけどやってること

5.超巨大アバターをちゃんと見るために

とりあえず1万倍アバターを作ってみてみよう

Cameraの設定を変えて、見切れないようにしよう。

Fogの設定を変えて色がなくならないようにしよう。

ついでに

6.アップロード

おまけ：今のところわかってないこと

説明書に載ってない本当のClothコンポーネント ～VRChatで使うClothコンポーネント～

TL;DR

Skinned　Meshのバッチ処理

説明書に載ってない本当のClothコンポーネント～VRChatで使うClothコンポーネント～