REALITY Avatarを支える技術と支えきれていない僕の手の話 - ReDo

2018年9月28日

REALITY Avatarを支える技術と支えきれていない僕の手の話

未来の話については「関係各位の発表をお待ちください!」ではあるのですが、現時点でのお話についてはだいじょうぶやろ、ということで、主に技術的な観点において先に見解(?)をエモちらかしておこうと思います。

○iPhone X限定

順番と、「ターゲットが増えると手間が増える」という、単純な開発コストパフォーマンスの問題です、申し訳ありません。

Vision frameworkで目処がたてば非XのiPhoneへの対応が一番容易だろうという気配で、次いで4:3問題を解決すればiPadかなという感じです。
Androidはフェイシャルキャプチャの話もありますが(ML Kitの顔内ランドマーク認識を期待しています)、画面・マイクキャプチャとストリーミング部分の話も機種バリエーションもあるので色々がんばらないと、という状況です。


○画面・マイクキャプチャ

キャプチャはReplayKit、ストリーミング部はHaishinKit.swiftです。

ライブ配信を行うとすぐ気づくと思いますが、配信する画にUIが乗ってしまう点について、RenderTextureからネイティブで・・・あたりを一応おいかけたのですが、(主に僕の技術力が無いせいで)パフォーマンス観点で大丈夫そうなやり方が見つからず、ひとまずiOSネイティブ側に全部を任せる方式に倒しました。
レンダリングパイプラインとかネイティブの描画まわりのポインタの扱いについて、完全に理解してから再戦したいと思います(フラグ)。

ReplayKitはiOSのバージョンが上がるたびにちょいちょいと別物になってるので全容が掴みづらかったりしますが、なんとなくで使う分には楽しい子だと思います。
なんとなくじゃなく使う際には融通が効かないし、権限確認まわりが通常のカメラ/マイクと全く関係ないし、Swiftだとerror code隠れてますし、まだ飼い慣らせておりません。最終的には「お世話になったな、さらば!」と言いたいのですが。

HaishinKit.swiftは、「そもそも昨今のストリーミング配信ってどういうものなの?」を理解するのに最高でした。nginx-rtmp-moduleでさっくりとRTMP-HLSサーバが立つので、こちらと組み合わせて色々遊んでみるのはオススメできます。
とはいえ、色々な歴史のあるRTMPまわりについてはまだよく理解できないところもあり、おかしな使い方していたらこっそり教えていただけると嬉しいです・・・


○ARKit Facial Trackingと脅威のパフォーマンスの話

今の所iPhone XのA11パワーに頼りきっている本アプリですが、そのiPhone Xをもってしても、「ARKit Facial TrackingのアライグマのデモがXcode測定でCPUを80%もっていく」という数字を叩き出した際には、これはさすがにダメかと思いました。

・Xcodeのパフォーマンス表示はあくまでCPU、ネイティブを繋いでiPhoneのハードウェアに処理を追い出せると、処理を追加してもあまり負荷としては上がらない
・アライグマ(sloth)は16万ポリゴンな上に顔の表面だけではなく、モデル全体がBlendShape対象という、あまりつくりのよくないモデル。
・それでもシステム60fpsは色々無理があって断念しました。30fpsに設定しています。

ARKit Facial Trackingそのものについてはどこか別のところでお出しできればと思っています。


○Unity?

Unityです。

スタジオサイドはUnrealなのでこちらもUnrealでやりたかったのですが、以下のような感じで、端的にはUnreal力もC++力も足りずにギブアップしました。

・Unrealは「自前でUE C++だったりNative C++だったりロジックを内包する」のは十分に対応していると言えるのですが、「外部のライブラリ」を繋ぐのには(とくにAndroid/iOSのモバイルにおいて)十分にサポートされているとは思えませんでした。
・UnrealはSwiftをサポートしていません。ビルドシステムがモバイルの動的ライブラリに対応していない、という認識ですが正直この見解に自信がありません。将来しれっとSwiftサポートが入ったらそれはそれでいいことだと思います。
・Xcodeプロジェクトを出力するので最悪、独立して編集後にxcodebuildコマンドが有効なUnityと比較して、clangでゴリゴリとcppやmm(Objective-C++)をコンパイル後、リンクして署名まわりのXcode側のビルドシステムを使う感じのため、通常のiOSアプリとはかなり違うXcode力を要求されます。どちらかというとクロスコンパイルな組み込み屋の感覚に近いかな・・・と思いつつ、ビルドシステムをドッカンドッカン壊しながら繋ぎましたが、「これをUnrealがメジャーアップするたびに追従するのか?」と考えた際に登れる山に思えませんでした。
・余談ですが、Androidは「Javaコードをxmlに書いてエントリポイントのActivityに文字列マージなinjectする」という「マジで?」というようなIFで、これはこれでつよつよだったりします。

色々他の話もありましたが、プロジェクトとしては結論としてUnityに振りました。


○差分アップデートの話

いわゆるAssetBundleの話です。α版を利用された方はすぐ気づいたかもしれませんが、現状差分ダウンロードに対応しておらず、絶賛バトル中です。

通常のゲームとアセットの概念もアプデ方針も違いますし、「そもそも主機能であるライブ配信でギガをもりもりと消費する」本アプリについて、何が正解なのかハッキリしていません。「今ライブ配信をしたい!」という人が、利用予定のない新衣装のダウンロードに「○○MBダウンロードを行っています(○○分おまちください)」というのもナンセンスです。

アレコレを無視すればいくらでも無限に欲しくなるパーツカスタマイズのバリエーションですが、ユーザの通信帯域もデバイスの空きストレージも無限にあるわけではないということで、日々わいわいしております。

# それと、ipaの表示サイズと実際のダウンロードサイズと、インストール後のストレージサイズ、どういう計算になってるのかよくわかりませんね?BITCODEってこういう動きするものでしたっけ???


○モデルとカスタマイズの話

Unityでバラバラのパーツを組み立てて動かす際には「共通骨構造を決めておいて、SkinnedMeshRendererがもっているbone配列の情報を差し替える」が基本方針となります。

edo氏とちえぽむ氏の以下のエントリが参考になります(ぶっちゃけ作った後にやっと話が分かるようになりました)

SkinnedMeshとBoneWeightについてメモ - e.blog http://edom18.hateblo.jp/entry/2017/06/09/080802
ボーンの差し替えによる着せ替え - chienote https://chiepomme.gitbook.io/chienote/animation/dressing-up-by-bone-replacing

Unityとか、そもそもの3DCGのweightまわりに詳しい諸兄であれば常識なのかもしれませんが、僕はサンプルを引き継いだ際に「SkinnedMeshRenderer管理下になっているはずのbone配列をいったん外に取り出して元に戻す」というのがなかなか理解できず、「よくわからないけど動いている」状態が長く続きました。

パーツ管理システムは今後運用にずっしり響いてくるため、エディタ/アセットビルド/ランタイムまわりは綺麗に作り直したかったりします...


○「誰でもVTuberになれる」という話

謳い文句としてこうは言ってるのですが、僕個人は別にみんながVTuberにはならないでいいと思っています。
「バーチャルですごす人」みたいな意味のちょうどいい単語がないので、代理として「VTuber」という単語をお借りしている認識です。

リアルアバターよりSNSのプロフィールアイコンが本人を示す世界があるように、自由にアバターを選ぶことができて、コミュニティ毎に好きな自分で生きていける世界がつくれたら楽しいな、と思っています。

コメントする