More than 3 years have passed since last update.

Unityでサウンドエンジン(ADX2, Wwise, FMOD)を扱う際におさえたい事

Last updated at 2021-03-08Posted at 2018-01-29

はじめに

本文書は、Unityでサウンドまわりを実装する際に各種(ADX2, Wwise, FMOD)を採用するさいに検討したい事と、実装する際に懸念すべき事についての私見です。定性的な部分が多いので定量的な情報をお持ちであればご指摘いただけると幸いです。というか情報がもっとほしい。

結論

はじめに結論をのべておくと、「ほとんどの場合Unityならサウンドエンジンいらない」そして「ある程度したい演出があって楽にやりたいならADX2」「WWiseはつかうならちゃんと使いこなさないと損」「FMODは使うと楽しいけど情報はすくない」「どれを使うにしても発音数をなにも考えずに増やしてはだめ」となります。ある程度使ったことのある人には何をいまさら？というのことをこれから長々と書きます。

環境

MacBook Air (11-inch, Early 2015) OSX 10.12.6
Unity 2017.3.f3
ADX2 Unity Plugin/AssetStore 2.24.00
Wwise 2017.2.0.6500
FMOD 1.10.02

各エンジンの特徴

世の中にはUnity公式ノンリニアオーディオデモというすごくかっこいいデモがあります。ただ、これの実装はそこそこ大変です。さらにUnity上でオーサリングして調整するとなるとかなり大変そうです。これを各サウンドエンジンで実装することで各エンジンの特徴を再確認しました。

※ページビュー乞食

ざっくり表にすると

項目	オーサリング負荷	組み込み負荷
Unity	X	X
ADX2	◯	◯
Wwise	△	◯
FMOD	◎	○
※便宜上、Unityでもの状態を一番つらい、にしてます。

という感じでした。正直Wwiseのオーサリング負荷はXにしてもいいくらいにつらいものでした。大規模になってくると段々つらさが均されていくのですが、このデモ程度の規模だとちょっとのことのためにメンドくさい部分を直に触ることになるためです。また、オーサリング負荷がADX<FMODなのはUXがわかりやすくてなんとなーくやっても上手くいくからです。実装負荷は正直どれもおなじくらいです。用意されてるコンポーネントもどれも一緒な感じですし。

2020/10/12:お値段の話

聞きかじったお値段の話を書いておきます。
インディーだとだいたいどれもタダです。
商用の方は予算3億、売上5億くらいで考えてみます。
(夢があるような内容な絶妙なライン..モバイル売切だと夢ありすぎて非現実的..)

項目	インディー環境	商用価格
Unity	-	(追加費用なし)
ADX2でSteam	LEなら0,AssetStore版なら$100	5億円0.7(Steam税引)/1.1(税引)0.0095(ADX料)≒300万円≒$28,000
ADX2でiOS/Android売切	LEなら0,AssetStore版なら$100	75万円、あるいは売上ストア税0.04の大きい方例)5億0.7(ストア税)/1.1(消費税別)0.04=1272万≒ $121,000
ADX2でiOS/Android アイテム課金	LEなら0,AssetStore版なら$100	販売価格-ストア手数料の0.95% x 販売本数、上限25円/本。基本無料・アイテム課金ゲームは月0~80万円の売上連動型
ADX2でF2P	LEなら0,AssetStore版なら$100	販売価格-ストア手数料の0.95% x 販売本数、上限25円/本。基本無料・アイテム課金ゲームは月0~80万円の売上連動型
Wwise	$150K規模まで0	$900(＋ロイヤリティ)~ 21,000(ロイヤリティなし)
FMOD	$500k規模まで0	$5,000~15,000

ちなみにお値段は公式サイトからの引用です。

以下にもうすこし詳しい内容を書いておきます。

素Unity

長所

中身はFMOD
AudioSource, AudioClipなどのわかりやすいAPI
Unity標準装備のプロファイラで最適化できる
AssetBundleとも親和性高い
音数がふえたら優先度順に消す、くらいはやってくれる

短所

細かな発音制御しようとするとスクリプト書く必要がある
Wavをバージョン管理に含むとプロジェクトが肥大化するのでサブモジュールにしたり、AssetBundle化したりと苦労が多い

ADX2

長所

だいたいなんでもできる
日本のゲーム業界のシェアが高い
独自コーデックの圧縮率高い
Androidの低遅延再生に優れる(標準40msecに対して15msecくらい)
プロファイラーもつかいやすい
パッキングシステムも用意されてる

短所

商用でもUnity用に添付されてるサンプルなどは乏しい
パッキング用のサンプルはとくに乏しい
StreamingAssets前提
機能制限版ではMac用エディタがない=>2021年現在、追加されたそうです。

Wwise

長所

大体なんでもできる
世界標準なので漁るといろんなプラグインとかある
GDCとかで最先端情報を探るとWwiseが前提
VR用ソリューションへの対応も早かった
使用者の目的にあわせたレイアウトプリセットが多い
公式チュートリアルがめちゃくちゃ詳しい

短所

日本語情報が少ない
使用目的ごとにレイアウトプリセットを切替えてもなお溢れ出るオーサリングツールの情報量
ほかドライバにくらべて常駐メモリ量がやや多い

FMOD

長所

オーサリングツールのUXわかりやすい
世界的にはそこそこ採用されてる
発音制御、3Dサウンド、ランダム再生、インタラクティブ...だいたいのことはできる

短所

マイナー
日本語情報はめちゃくちゃ少ない
最近までモバイル用がなかったりとやっぱり足が遅い

補足

作業負荷だけでなくエンジニア的にはマシンリソース負荷もきになるところなのでその辺補足しておきます。本当の最適化は各エンジン添付のプロファイラーでおこなうべきですが、公平になるようにUnityプロファイラーから見えるところで比較します。
なお比較は各サウンドエンジンの組み込みで作成したもので、コーデック：ADX2=独自コーデック、FMOD&Wwise=ogg、再生方式いずれもStreamで作成してあります。

ざっくりプロファイラーでみると

Audioプロファイラーでみるとこうなります。

全部いっしょ。しってた。

それぞれ独自のPluginで走ってるので当然UnityProfilerからは確認できません。

CPU

もちろんこの程度のデモでは1%たりともCPUをつかわないので比較はあまり意味がありません。

※正直オーディオバッファのfillって1frameないに3frame分つめるくらいで動作しないとプチプチいう世界なので、まともなサウンドエンジンを普通に動かしてるかぎりあんまり負荷ってあがらないんですよね。

ADX2

基本はCriAtom.Initializer、Cri.Listener、Cri.Updateがはしる。追加で音源数が増えるとSourceの処理がはいります。

Wwise

おなじように音源数によって処理が増えます。

FMOD

どれ？

基本的にはどれも音源数によって増える。ということは実は数百〜数千規模になるならあらかじめ刈り取ってあげたほうがいいという中身であろうと思われる。当たり前。

メモリ

####　概要

ざっくりみるとADX2とFMODが10MBに対して、Wwiseが30MB近いように見える。やっぱり若干おおい。

ちなみにWwiseのテクスチャがおおいのは標準プラグイン画面のアイコン

はずすの面倒だったんですごめんなさい。そのへんを差し引いてもWwiseは10MB程度は多めに食うようです。

詳細

ADX

よくみると結構興味深いです。CriExPlayerが結構多めに食っています。CriAtomPlayerEx=CriAtomSouce.player=音源にかかわるので音源をprefabなどに埋め込んでリクエストとして利用するとこのResourceがおおくなり、またそのGCによって処理が低下することが予測されます。可能ならAudioSourceを使い回すような作りにしていたほうが良い事がわかります。当たり前ですね。

Wwise

そりゃプロファイラ上でメモリ負荷が高くなるよ、という状態です。
Windows用とMac用の便利機能やエディタ用のオブジェクトがたくさんいます。このあたりはReleaseビルドなら消えるので先ほどの数字より若干マシになるはずです。

また、音源用オブジェクトサイズは15kB程度とそこまで大きくなく、Callbakなどのマネージャーが大部分をしめています。これがWwiseをいれると大した事やってないのに多くメモリを食われる理由のようです。もう少し大規模なプロジェクトであればこのあたりの割合が下がるため採用してもよい、という判断になります。

FMOD

こんどはまともに見るものがありました。イベントのキャッシュは発音イベントのキャッシュで、一回しかリクエストしていないからか、対して大きくありません。Assetモニタではそのかわり250kBとドカッと確保しています。ADX2が細かく確保している分をひとまとまりで確保している感触です。細かいところがみたい。。

要するにどのエンジンでも、音源を何も考えずにふやすとGCでメモリと処理負荷を食われていきそうなのがわかります。

まとめ

デモの完成度などからも、Unity単体でだって色々なことができることはわかります。しかしその実装・調整負荷を下げるためにはサウンドエンジンを採用するという判断が有効です。

その際にADX2は独自コーデックや低遅延といったニッチなニーズに応えてくれ、プロジェクトの規模によってもスケールしやすいため、とりあえずコレと選んでしまってもよいサウンドエンジンです。

Wwiseを採用する場合はコンポーザーとエンジニアががっつり腰をすえてやらないと、コンポーザーの負荷が高く、またマシンリソース的にももったいない結果になっていしまいます。

FMODはUnity環境において正直まだおすすめしにくい状態ですが、UXのわかりやすさからインタラクティブミュージックのモック作成などにはアリです。

参考

日本のモバイルやインディーでもかっこいいサウンド演出が増えていけばいいですね。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up