サウンドエンジンWwiseとCriwareの違い

1）サウンドエンジンWwiseとCriwareの違い

2）Unityの読み込みシーンのフラッシュバックの問題

3）Animation Transition規則

4）Qualcomm GPU Adreno650 にあるテクスチャ表示が異常です

5）Live2Dのスムーズなグラデーションのスキーム

Audio

Q：現在、WwiseとCriwareの2つの音声（サウンド）エンジンから選択できますが、通常の開発、熱更新、効率、およびデカップリングの観点から、どっちをすすめますか？それとも、得意な方を使われば良いでしょうか？

A1：実際、オーディオミドルウェアツールには、この2つだけでなく、多くのオプションがあります。たとえば、「Apex Legends」はRad Milesを使用し、「Wind Traveler and Light Encounter」はFMODを使用し、「Half-Life Alyx」はミドルウェアを使用しなく、自社エンジンのオーディオモジュールを使用しています。

Criwareは比較的長い歴史があり、有名なゲーム開発者Segaと深い関係があり、かつてSegaの公式オーディオおよびビデオ開発ツールセットに含まれていたとさえ言えます。Segaの影響を考慮すると、Criwareは今の日本でも相変わらず大規模なユーザーベースを持っています。

Wwiseの歴史は比較的に短く、その開発会社であるAudiokineticが2019年にSIE（Sony Interactive Entertainment）の子会社になったのは興味深いことです。実際にはWwiseを使ったプロジェクトがたくさんあり、毎年TGAの受賞プロジェクトの約半分はWwiseを使って開発されていますが、顧客にLogoを強制することはなく、存在感がそれほど高くなくなっています。

Wwiseを使用した例をいくつか挙げられます（順位は前後を問わず）：Death Stranding、Resident Evil 123 Remake、Resident Evil 8、Monster Hunter Rise、Ghost of Tsushima、God of War、Honkai Impact 3、Genshin Impact、Honor of Kings 、CODM、ミステリアスケース、レインボーフォール、モニュメントバレー2、Gris、Quantum Break、Control、ウィッチャー3、サイバーパンク2077など。

開発の観点からもオーディオチームの観点からも、Wwiseの方がより良い選択であると思います。

開発

業界をリードする空間オーディオツールの集め、広義Object Basedのオーディオパイプラインをサポートする最初のオーディオツール：

https://www.audiokinetic.com/zh/library/edge/?source=SDK&id=spatial_audio.html

https://www.audiokinetic.com/zh/products/plug-ins/reflect/

業界をリードする自動車エンジンのサウンドデザインプラグイン：

https://www.audiokinetic.com/en/products/plug-ins/crankcase-rev/

オーディオデザイナーのクレイジーなアイデア、多数の成功したユーザーケース、テクノロジーの共有（Wwise Tour、GDCなど）を実現できる強力なクリエイティブツール：

https://www.bilibili.com/video/BV1RE411K7nT

公式ウェブサイトのQ＆AとLauncherのBug reporterは、公式によってサポートされた無料の質問フィードバックと送信のチャネルです。技術サポートと創造的な技術サービスは、プロジェクトのカスタマイズしたニーズを満たせます。公式に維持されているUnity/Unreal統合では、Launcherを介してWwise SDKをプロジェクトにすぐに統合できます。

フルプラットフォームをサポートし、豊富なオーディオコーデックオプション、豊富なSDKドキュメント、明確で習得しやすいヘルプドキュメント、認定チュートリアルドキュメントにより、ユーザーは初期化設定を調整して、必要に応じてオーディオ遅延を減らすことができます。

ホットアップデート

File Packagerツールは、PCKを作成してホットアップデートを介して公開されたコンテンツを管理します。、Wwise2021.1はすでにUnity Addressablesをサポートしています。

効率

デザイナーにとって、WAQL（Wwiseオーサリングツールクエリ言語）を使用すると、プロジェクトの規模が特定のレベルに達したときに配置が必要なアセットをすばやくクエリしたり、問題の原因となるアセットを特定したりすることができます。

https://www.audiokinetic.com/en/library/edge/?source=SDK&id=waql_introduction.html

強力で柔軟な音声制限機能とProfilingツールにより、パフォーマンスの最適化とトラブルシューティングが容易になり、エンジニアの負担が軽減され、豊富なバッチ処理機能が備わっています。

エンジニア向けに、WwiseにはWAAPI（Wwise Authoring Tool API）があります。これは、開発ツールの作成に使用でき、膨大なデータ構成をすばやく処理するのに便利で、プロジェクト開発のニーズを満たすためにアセットをバッチでパッケージ化するのにも役立ちます。

https://www.audiokinetic.com/en/library/edge/?source=SDK&id=waapi.html

Wwiseは動的なメモリ管理を備えており、事前に固定サイズのメモリプールを申請する必要がないため、可能な限り使用することができます。メモリ分類システムにより、ユーザーはメモリコストに関連する問題をすばやく特定することができます。

デカップリング

Wwise APIはシンプルで使いやすく、イベント後の動作はオーサリングツール側のデザイナーが設計できるため、エンジニアはそれについて心配する必要はありません。通常、デザイナーのためにコール必要があるインターフェースは次のようなものがあります。

PostEvent

SetState

SetSwitch

SetRTPCValue

Load/Unload bank

詳細なドキュメントについては、以下を参照してください。

https://www.audiokinetic.com/en/library/edge/?source=SDK&id=workingwithsdks_integratingelements.html

Wwiseは、サウンドデザイナーに優れたクリエイティブな空間を提供します。空間オーディオデザインに関連する多くの設定は、デバッグのためのプログラムの介入を必要とせずにクリエイティブツール側に配置され、一般的なサウンドジェネレーターのように処理するだけで済みます。

デザイナーは、Profilingツールを通じてパフォーマンスの低下を明確に理解し、パフォーマンスの問題を引き起こす可能性のある設計を事前に特定し、リファクタリング処理を行うこともできます。

A2：技術的な観点からすると、A1は本当に良いです。簡単に私の意見を述べさせてください。

インターフェイスの見栄えが良いかどうかに関係なく、後で変更できます。どのテクノロジーでも、その市場を考慮する必要があります。現在はいうまでもなく、Wwiseのシェアは高いのです。たとえば、会社に採用される可能性が高いのは、Wwiseができるオーディオエンジニアか、またはCriwareができるオーディオエンジニアですか。

プログラムは同じで、人気があるのはWwiseのみができるの方か、Criwareのみができるの方か。この分析を通じて、どのソフトウェアを使用すべきかがわかります。

Crash

Q：最近、プロジェクトで非常に奇妙な問題が発生しました。あるシーンから別のシーンに切り替えると、Android 64ビットの実機でクラッシュし、シンボルテーブルを使用して最後のクラッシュがUnityのil2cpp / vm/liveness.cppのファイルにあると発見ました。

UnityやPCバージョンにはフラッシュバックはありません。

エンジンバージョン：Unity 2018.4.10

パッケージ化デバイス：MacOS

クラッシュの原因を特定するために、次のテストが実行されました。

Monoを使用してパッケージ化すると、ラッシュバックしません。
V8クラスライブラリを削除し、V7クラスライブラリを完全に使用すると、ラッシュバックしません。
V8ライブラリを使用して、空のシーンに切り替えてフラッシュバックします。

3では、Application.LoadLevel、Applicaiton.LoadLevelAync、SceneManager.LoadScene、SceneManager.LoadSceneAyncのいずれを使用しても、フラッシュバックします。この問題には今のところ手がかりがありません。誰かがこの問題に遭遇したことがあるのか。

フラッシュバックログ：il2cpp :: vm :: LivenessState :: AddProcessObject（Il2CppObject、il2cpp :: vm :: LivenessState）

残念ながら、Unityをアップグレードした後でも、クラッシュは解決されません。

参照URL：

https://forum.unity.com/threads/il2cpp-crashes-at-garbagecollectsharedassets-and-loadlevel.316775/page-2

A：Unity 2018.4.35バージョンにアップグレードする必要があることがわかりました。このバグは、このバージョンで修正されています。

Animation

Q：Animation Transitionについて質問させて頂きます。現在、State Aには、Aからのすべての遷移線に優先順位を付けることができます。では、Aに入るすべての遷移線にも優先順位を付ける方法はありますか？

たとえば、Aの場合、AnyState->AとB->Aという二つの線があり、それらの条件は同じです。したがって、条件が真の場合、上記の線のいずれかの使用を指定する方法はありますか？

現在、公式ドキュメントには対応する方法はありません。Bに入るときに状態をDisable AnyStateに設定し、Bを出るときに元に戻すことができるという主張がありますが、より良い方法があるかどうかわかりません。

A1：「Aに入るすべての遷移線にも優先順位を付ける」という言い方は間違っているところがあります。ステートマシンの定義によれば、同時に2つの状態にいる状況は存在しなくて、両方ともState Aに入る必要があります。

問題を詳細に説明するとき、重要なのはAnyStateノードの存在であるとも述べられました。Unityのアニメーションステートマシンスキームでは、Entry、AnyState、Exitノードはシンタックスシュガーに似ています。Runtimeアセットを生成する場合、一連のノード拡張プロセスがあります。

この質問に戻ると、State B -> State Aの場合、「Aに入るすべての遷移線に優先順位を付ける」または「Bから出る遷移線に優先順位を付ける」ではありません。B-> Aに2つのTransition線を設定すると、優先順位を付けることができ、AnyStateは展開後にB->AのTransitionも生成します。ただし、エディターレイヤーはこの視覚化レイヤーを公開しないため、調整できず、拡張プロセスは表示されず、拡張はサポートされません（少なくとも私はそれを見つけられませんでした）。

AnimatorControllerを使用し、関数を実現する方法を見つける必要があるという前提で、次のようにします。

B-> AでAnyStateのTransitionを実行しないようにする場合は、Distable AnyStateのステートマシンスクリプトを記述し、AnyStateの条件に割り当てるパラメーターを宣言するのが最も簡単です。面倒なのは、Anystate-> Aを使用する代わりに、Sub-Smを使用して接続数を減らすことです。

AnyStateのTransitionの優先度を上げたい場合は、同じ配置の同等の遷移TransitionをB-Aに追加して調整できます。

A2：意味的には、AnyState->AにはB->Aが含まれます（条件が同じ場合）。つまり、B->Aはステートマシンの冗長なTransitionです。現在の状態は1つだけで、条件が満たされると次の状態に移行し、優先度の問題はありません。したがって、B->AがAnyState->Aのサブセットにならないように、B->Aを他の条件に設定する必要があります。

Rendering

Q：現在、Qualcomm GPU Adreno650デバイスでは、テクスチャ表示がぼやけていることがわかりましたが、解決策がありますか？（Mipmapsのlevelエラーのようです。）

Unityバージョン：2019.4.10LTS、

URPバージョン：7.5.3

画像設定圧縮形式：RGB(A) astc compressed

Qualcomm Adreno650：

他のデバイス：

A：おそらくGPUの問題です。Shaderの浮動小数点精度を下げてみてください。それが、当時私たちが解決した方法です。一部のHuaweiスマホにもこの精度の問題があります。

Rendering

Q：Live 2Dによって公式に提供されているCubismRenderControllerは、Opacityを設定することでCubismの透明度を設定できますが、以下に示すように、過渡は非常に硬く見えます。

現在の解決策は、RTを介してパネルにCubismをレンダリングし、パネルの透明度を制御することでスムーズな過渡効果を実現することです。良い解決策はありますか？

テスト後、イージングカーブ関数を使用してこの値を設定することはできず、中間プロセスでは相変わらずバレます。

A1：いわゆる透明性の「スムーズではない過渡」の本質的な理由は、元のロジックは、cubism_ModelOpacityを体の各小さな部分に個別に適用してから、各部分を混合することからです。コアコードは次のとおりです。

体は部分ずつ描かれています：

問題主の欲しい効果は次のとおりです。全体的な結果がレンダリングされた後、透明効果が全体に適用されます。したがって、「全身を描いた後、再度透明度を使用する」ことは避けられません。その本質は、ボディの各部分が描画された後、FrameBufferを取得してから、透明度を使用して1回処理する必要があるということです。したがって、「RTを介してパネルにレンダリングし、パネルの透明度を制御すること」は合理的です。

したがって、主な問題は、このプロセスを最適化するためのより直接的な方法があるかどうかです。ここでは、より良い最適化方法を考えていません。Builtin-RenderPipelineはそれほど柔軟ではないか、最適化が必要かどうかを検討する必要があるかもしれません。

UWA公式サイト：https://jp.uwa4d.com

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

UWA公式Q＆Aコミュニティ(中国語注意)：https://answer.uwa4d.com