カートゥーンレンダリングの制作の流れ

11192 ワード
Physics animation CPU Rendering uGUI animation テキストリンク

今回の主な話題：カートゥーンレンダリングの制作の流れ、物理モジュールを採用していないけどなぜ物理エンジンの時間コストがある、SpriteAtlasのlate bindメカニズム、AndroidプラットフォームでのASTCの使用可能性、UIパフォーマンス分析。

制作

Q1: 最近Unityでキャラクターのカートゥーレンダリング効果を作成しました。現在の流は下記のように：１）プログラムがUnityでShaderを書いて効果を調整します。2）アーティストモデルの頂点カラーと法線などのアセットを3dmaxで変更し、プログラムに渡します。3）プログラムがアセットをUnityに導入して効果を検査します。現在、アセットを頻繁に変更し、エクスポートおよびインポートする必要があり、効率は比較的低いです。

だから私は次の2つの質問があります：
1.3ds maxでシェーダーを作成し、アートでモデルを変更した後、すぐに効果を確認できることはどうすればいいですか？
2.成熟した制作の流れとは何ですか？

①

これは難しいことではありません。レンダリングプログラマーにMayaまたはMaxのドキュメントを見てもらいましょう。基本的には数時間で完了します。MaxまたはMayaにはサンプルとドキュメントがあります。たとえば、Maxの場合はDirectX Shader Materialを使うことです。これを難しいものに考える必要はありません、ドキュメントを見てください。

本質的に、あなたが見るものを直接にあなたの目的になさせたいですと感じています、すべての仕事はこの目的のためのものだと思います。カートゥーレンダリングによるアートリリースのほとんどは、ストロークを制御するための頂点カラーのブラッシング、ライティングを改善するための頂点法線の変更などのカスタマイズを必要とします。したがって、シェーダーがMaxに実装すれば、常にインポートとエクスポートすることの代わりに、アーティストの制作流れも大幅に改善できます。一般的な流れは、エンジンプレビューエフェクトと同じのMax（またはMaya）をメンテナンスして、一つのカスタムの法線エディタツールを加えて（自有のツールは十分でないとアーティストが感じた場合、たとえば、Maxの法線エディタことは難しい）。これで、アートリリースを変更して、効果の一貫性を確保すれば大丈夫です。

②

最初の問題について、読書さんが一つの方法を提供しました：MaxにはHLSLで書けます、DX9/11のSampleがありますが、問題がたくさんあります。Driverに対してはNitrous Direct 3D 9をお勧めしますが、Gamma/LUTとSSAOを必ずオフにしてください。

参照ドキュメントへのURLを添付します：http://docs.autodesk.com/3DSMAX/16/ENU/3ds-Max-SDK-Programmer-Guide/index.html?url=files/GUID-0C7A600E-7954-42B0-86EE-586A379A2CAD.htm,topicNumber=d30e34269

UI

Q2:UIインターフェイスを開くと、Profilerのピーク値は、Canvas.SendWillRenderCanvasesがCPUコストの50％を消費し、Canvas.SendWillRenderCanvasesが80msを消費し、Graphic.Rebuildが72msを消費することを顕示しました。最適化する方法はありますか？

これは、多数のUIインターフェース要素の再構築コストです。提案は次のとおりです。
（1）まず、「動と静を分離」の原則を通じて、不要な静的UIメッシュが再構築に関係しているかどうかを確認します。
（2）UIインターフェースが複雑すぎるかどうか、UIレベルまたはメッシュの数が大きすぎるかどうか。
（3）UWAパフォーマンスレポートで対応するソリューションと関連動画を確認します。

物理

Q3:下図のように、物理モジュールに衝突ペアもRigidbodyも何も使用していませんが、なぜ物理モジュールの時間コストまだありますか？

問題主のUnityバージョンは何ですか？Unity 5.4バージョン以降の場合なら、Unityエンジンが物理システムを調整していたため、確かに正常ではありません。

Unity 5.4より前のバージョンの場合は、可能性があります。使用するかどうかに関係なく、物理モジュールがすべてのフレームで実行されるため、アイドリングとして理解できます。これに関して、問題主にレポートにある「重要なパラメータ分析」⇨「エンジンパフォーマンスパラメータ」の「Physics.Processing」または「Physics.Simulate」ページを確認することをお勧めします。このページには、これら2つの関数のコール回数が含まれています。多くの場合、物理モジュールはあまり使用されていなくても、20msごとに（デフォルトで）実行されるため、同じフレームで何度も実行されます（下図のように）。だから、物理モジュールには一つの特性があります。プロジェクトが重っていると、もっと重くさせます。この場合、問題主は他のモジュールを最適化するだけで済みます。他のモジュールの時間コストが減りますと、物理モジュールの時間コストも自然的に降ろします。

アセット管理

Q4: 最近、Unity 2018.1.0 Beta 13バージョンで問題が発生しましたが、以前のバージョンでも同じ問題が発生する可能性があると思います。Unity 2017の新しいSpriteAtlasをSpriteのパッケージ化に使用し、AssetBundleを生成しました。この方式はtagとは異なることがわかりました。遅延バインディングも処理する必要があるため、SpriteAtlasManager.atlasRequestedのコールバックを自分で実現する必要があります。

そのため、SpriteAtlasのすべてのInclude Buildを削除し、AssetBundleをパッケージ化しましたが、SpriteAtlasManager.atlasRequestedの実現に問題が発生しました。これは、同期インターフェースを使用すると、つまり、AssetBundle.LoadFromFileとAssetBundle.LoadAssetのインターフェースがSpriteAtlasをロードし、SpriteAtlasManager.atlasRequested内部に直接actionをコールバックすると問題は発生しません；非同期インターフェースを使用すると、つまりAssetBundle.LoadFromFileAsyncとAssetBundle.LoadAssetAsyncを使用し、ロード完了後にactionをコールバックします（つまりSpriteAtlasManager.atlasRequested以外）と、画像がロードできないことを導きます。エディターまたはパッケージ（私がテストしましたのは Windowsパッケージ）も、UGUIのインターフェースをぼやけさせます。

公式に聞きましたけど返事はありませんでした。
https://forum.unity.com/threads/spriteatlasmanager-atlasrequested-is-not-invoked-in-editor.524801

だから、これがUnityのバグなのか、それとも私の理解または操作に問題はありませんか？

まず、「このメソッドはタグとは異なることがわかりました。遅延バインディングを処理する必要があります。」は違います。ここでは「必要」ではありません。[Include in build]をオンにすると、bindingを自分で処理する必要がなく、直接ロードしてインスタンス化するだけで大丈夫です。ただこのバグを注意するだけで、今はBundleのアトラスを冗長になさせる可能性があります。https://answer.uwa4d.com/question/5a822325847802258a06509e

問題主がlate bindingをやりたい場合、説明から伝えたいのは、SpriteAtlasManager.atlasRequestedに必ず直接にactionをコールバックしますと有効ですが、非同期を使用した後（数フレーム後に相当）にコールバックしますと無効になりました。

再現のために例を作成しましたが、類似な問題は発生していませんでした。テストコードは下記のように。UI Prefab（あるSpriteを使いました）と対応するSpriteAtlasに依存パッケージ化され、prefabBundleとsaBundleとして記録されました。ロードされたコードは以下の通りで、バージョンは2017.2.2です。

IEnumerator Start ()
    {
        var loadOp = AssetBundle.LoadFromFileAsync(Application.streamingAssetsPath + "/" + prefabBundle);
        yield return loadOp;
        var prepre = loadOp.assetBundle.LoadAsset<GameObject>("prop_parachute");
        GameObject.Instantiate(prepre);
    }
    void OnEnable()
    {
        SpriteAtlasManager.atlasRequested += RequestLateBindingAtlas;
    }
    void OnDisable()
    {
        SpriteAtlasManager.atlasRequested -= RequestLateBindingAtlas;
    }
    void RequestLateBindingAtlas(string tag, System.Action<SpriteAtlas> action)
    {
        StartCoroutine(LoadFromAssetBundle(tag, action));
    }
    IEnumerator LoadFromAssetBundle(string tag, System.Action<SpriteAtlas> action)
    {
        var loadOp = AssetBundle.LoadFromFileAsync(Application.streamingAssetsPath + "/" + saBundle);
        yield return loadOp;
        var loadOp2 = loadOp.assetBundle.LoadAssetAsync<SpriteAtlas>(tag);
        yield return loadOp2;
        var sa = loadOp2.asset as SpriteAtlas;
        action(sa);
    }

アセット管理

Q5: 現在、AndroidプラットフォームでASTCの使用可能性はどうですか？公式ドキュメントによると、いくつかの主流のGPUはASTCをサポートするための高い要件を持っていません。Android端末でASTCを使用するときに注意が必要なことは他にありますか？

ASTC圧縮方式に関しては問題ありません。テクスチャサイズの要求しなく、複数の品質レベルがサポートされています。しかし、問題はOpenGL ES 3.2以降のみサポートしています、つまりRedmi 2やXiaomi 4など、大部分のローエンドおよびミッドレンジコンピューターにはできません。iOSプラットフォームのiPhone 6以降でサポートします。サポートされていない結果は、テクスチャが自動的にRGB24 / RGBA32に変換されることです。そのため、私たちのプロジェクトはASTCを試しましたが、ETC2を再び使用しました。

UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。

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