何番煎じかわからないけど、試してみました。
一応、"Webエンジニア/ARがちょっとできるフレンズ"でやっているので。
#8thWallWeb ってローカルサーバで試せたんすね。
— jyuko (@jyuko49) 2019年4月17日
three.jsで書けるし、サクッとデモ環境作るには楽ですね。@Query_chan #WebAR pic.twitter.com/NiBQEaoS3D
8th Wallとは
8th Wall社のARプラットフォームで、8th Wall XR for Unity(Unity SDK)、8th Wall Web(Web SDK)が提供されています。
8th Wall | Powerful Tools to Create Extraordinary WebAR, AR, WebVR Experiences
この記事では、8th Wall Webにフォーカスを当て、8th Wall XR for Unityにはちょっと触れる程度にします。
8th Wall XR for Unity
Unity開発者向けのSDKです。Uniry向けにはARKit、ARCoreのSDKがありますが、対応デバイスは一部に限られます。特にARCoreは対象ユーザがまだ少ない印象です。
8th Wall XR for Unityでは、ARKit/ARCoreに対応している場合は利用し、ARKit/ARCoreに対応していないデバイスでも8th Wall SLAMと呼ばれる独自のライブラリで機能を実現しているため、より多くのデバイスで実行ができます。
その代わり、ARKit/ARCoreと比べると、提供される機能は6-DoFトラッキング、HitTestなどの基本的なものになります。
8th Wall Web
WebGLでARを実現するJavaScriptのSDKです。Webの利点として、アプリをDLせずにユーザをコンテンツに誘導できるところが大きな差異になります。
開発者視点では、ARコンテンツをA-Frame、three.js、Sumerianで作成することができるところもARKit/ARCoreと異なります。
対応デバイスについては、閲覧するブラウザに必要な技術要素がRequirementsに記述されています。
これらに対応したブラウザはCan I useなどでチェックできます。
WebGL - Can I use
getUserMedia/Stream API - Can I use
DeviceOrientation & DeviceMotion - Can I use
WebAssembly - Can I use
モーションセンサーについては、こちらのエントリが話題になってますね。
https://qiita.com/ikkou/items/a193d13250d9e3d51473
余談(WebARとiOS Safari)
Webの新技術はGoogleやMozillaが先行してブラウザに実装し、AppleがSafariにいつ実装するかで市場が動く傾向にあります。
WebGLがiOS Safariで使えるようになったのはiOS8(2014年9月)で、MozillaがA-Frameを発表したのが約1年後の2015年12月。当時ARと全く無縁だったWebエンジニアの私がthree.jsを触りだしたのもこの時期からです。
Mozilla、WebVRコンテンツ開発フレームワーク「A-Frame」を発表 | OSDN Magazine
getUserMediaやWebAssemblyはもっと最近で、iOS11(2017年9月)から。 8th Wall Webが発表された時期を調べると、そこから1年後の2018年9月でした。
1つのアプリで複数対応 ARクロスプラットフォーム『8th Wall XR』 | Mogura VR
・・・というように、Safariの機能実装から1年後くらいに3rd PartyのSDKやプラットフォームが登場する流れは感じてます。
で、次の重要なイベントはというとWebXR APIのSafari対応です。iOS13で発表されたらいいなと思いつつ、過去の感じからするとiOS14 or 15あたり(2020年9月-2021年9月)と予想しています。
WebXR API - Can I use
WebXR Device API
なお、余談の余談でARと直接関係ないですが、WebP(.webp、ウェッピー)もずっとSafariでの実装待ちです。こっちはiOS13で来てほしい!!
WebP - Can I use
WebP - Wikipedia
8th Wall Webを使う
前置きはこれくらいにして、実際に8th Wall Webを利用して評価してみました。
料金
まず気になるのは料金ですよね。
8th Wall | Pricing and Plans - WebAR, AR, WebVR Developer Tools and SDK
Freeプラン
Web Developer向けにもFreeプランが用意されています。ただし、1,000 View/Monthの制約があり、ローカルでしか利用できません。
試しに使った感じだと、実機デバッグでトライ&エラーしないと動作が読めない部分があり、約3日の利用で150 Views近くに達していました。
個人利用でも注意しないと超えそうな範囲かなと思います。
Proプラン
$99/Monthの固定費 + Viewに応じたCPV Feesという料金体系になっています。
Freeプランと異なり、自身のサーバにホストできるので、$99/Monthの固定費はその分のコストと考えればよさそうです。CPV Feesの方はView(PV)にかかるコストで、ボリュームディスカウントになっています。
金額感を掴むために、Viewが一定量に達した場合の総コストを出してみました。
Monthly Views | Total Costs |
---|---|
2,000 | $99 |
10,000 | $499 |
100,000 | $2,749 |
1,000,000 | $11,749 |
2,000PVまでならCPV Feesは無料で固定費の$99で使えますが、有料のレンジに入るとまあまあいいお値段です。
2019/4/22時点の為替レートだと、1万PV/月で約5.6万円/月、10万PV/月で約30万円/月ですかね。100万PV/月だと料金も100万円/月を超えます。
使い方
公式のチュートリアル通りに行えば、問題なく動きます。
- Tutorial
8th Wall Documentation
Tutorialと順序は逆になりますが、先にWorkspaceでやることの一覧です。
8th WallのWebコンソールにログインして作業します。
- Web Appの作成
- App名を入れるだけ
- APIキーの取得
- Web App登録したら自動で発行されている
- テストデバイスの登録
- "Device Authorization"ボタン押して、表示されるQRコードをデバイスで読み取る
準備ができたら、Githubからサンプルプロジェクトをcloneしてローカルで動かします。
Macで実行する場合のコマンドは以下になります。
※Node.js、npmはインストール済み
# git clone https://github.com/8thwall/web.git # cd web # cd serve # npm install # cd .. # ./serve/bin/serve -d examples/threejs/placeground/ -p 7777
実行すると、port:7777でローカルサーバが起動します。
QRコードも表示されるので、こちらからアクセスも可能。
上記に登録したデバイスでアクセスすると、公式のデモと同じサンプルアプリが開きます。
試作(three.js)
three.jsで何か作ってみます。
A-Frameでもよいのですが、three.js/examplesが充実しているので、A-Frameが必要な用途以外ではthree.jsをメインで使っています。
VRM
three.jsサンプルのTap to place(placeground)は、タップした位置にglTFモデルの木が生えます。
このモデルのパスはindex.js内で定義されています。
const modelFile = 'tree.glb'
VRMはglTFベースなので、モデルをVRMファイルに置き換えると普通に表示されます。
#8thWallWeb ってローカルサーバで試せたんすね。
— jyuko (@jyuko49) 2019年4月17日
three.jsで書けるし、サクッとデモ環境作るには楽ですね。@Query_chan #WebAR pic.twitter.com/NiBQEaoS3D
使ったVRMは、以前の記事にてクエリちゃんSDモデルのFBXファイルをUniVRMでエクスポートしたものです。
three.jsでWebVRを行うための基本的なところ - じゅころぐAR
MMD
three.jsでいつもやってるMMDのAR表示です。お借りするモデルによって利用規約もありますし、Freeプランはどっちみちローカルでしか使えないので、個人で遊ぶ用です。
WebAR x もぐ式りな#8thWallWeb #threejs #MMDケムリクサ pic.twitter.com/sGnJGYvLSA
— jyuko (@jyuko49) 2019年4月20日
MMDモデルはもぐ式りなをお借りしました。かわいい。
3d.nicovideo.jp
必要なthree.jsのライブラリはindex.htmlの<head>
に追記で読み込めます。
<script src="//cdn.rawgit.com/mrdoob/three.js/master/examples/js/libs/mmdparser.min.js"></script> <script src="//cdn.rawgit.com/mrdoob/three.js/master/examples/js/libs/ammo.js"></script> <script src="//cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/TGALoader.js"></script> <script src="//cdn.rawgit.com/mrdoob/three.js/master/examples/js/loaders/MMDLoader.js"></script> <script src="//cdn.rawgit.com/mrdoob/three.js/master/examples/js/effects/OutlineEffect.js"></script> ...
スクリプトもthree.jsと同じ感覚で書けるので、three.jsのexamplesを参考にして実装しています。詳細は割愛。
three.js/webgl_loader_mmd.html at master · mrdoob/three.js · GitHub
Image Targets
画像検知も試してみました。
マーカーとなる画像はWebコンソールのWorkSpaceから登録します。My Web ApplicationsでAppを選択すると、APIキーの下に"IMAGE TARGETS"ボタンがあります。
画像をドラッグ&ドロップでアップロードすると、Name
やMetadata
を自由に編集できます。
設定した値は、後述するリスナにてdetail
として渡され、detail.name
、detail.matadeta
で取得できます。
画像を登録したらスクリプトの実装になります。
画像検知のイベントを受け取るには、XR.XrController.pipelineModule()のDispatched Eventsに対するリスナを登録すればよく、リスナはXR.addCameraPipelineModules()
で定義できます。
サンプルに倣うと、placegroundScenePipelineModule()
のreturn
でリスナを登録して、XR.addCameraPipelineModules()
に結果を渡す形になります。
return { // Pipeline modules need a name. It can be whatever you want but must be unique within your app. name: 'placeground', listeners: [ {event: 'reality.imagefound', process: onImageFound}, {event: 'reality.imageupdated', process: onImageUpdated}, {event: 'reality.imagelost', process: onImageLost}, ],
試しに画像を検知したら、画像のnameをポップアップ表示する処理を書いてみます。
const onImageFound = ({name, detail}) => { alert(detail.name) }
あとは、onImageFound
でモデルを読み込んで、onImageUpdated
で追従、onImageLost
でモデル削除の処理を書いてあげれば実現できます。
画像検知 pic.twitter.com/iL8NNzGOQ2
— jyuko (@jyuko49) 2019年4月22日
Tips
カメラモジュールのライフサイクル
8th Wall Webのthree.js実装では、CameraPipelineModuleのライフサイクルに対して、メソッドを定義することでARコンテンツが動作するので、この動きを理解してからは実装やデバッグが楽になりました。
onStart -> onCameraStatusChange (requesting -> hasStream -> hasVideo) -> onProcessGpu -> onProcessCpu -> onUpdate -> onRender
一例として、レンダリング時にeffectをかける処理は、onStartで開始したループ処理ではなく、onRenderに記述することで動作しました。
onRender: () => { effect.render(_scene, _camera) }
まとめ
8th Wall Webの利点
- Webブラウザで動作するため、アプリ不要
- 幅広いデバイスでAR体験が提供できる
- 比較的手軽に使える
- three.js、A-Frameで開発ができる
対象デバイスが広く、WebサイトやQRコードからスムーズにARコンテンツに誘導できるため、WebARの特性を活かした製品になっていると思います。
個人的には、three.jsの資産やノウハウを活用できるメリットが結構大きいです。
8th Wall Webの課題
- 大規模に使うと利用料の負担が大きい
- アプリに比べて体験の質が低い
体験の質について、ARKit/ARCoreで開発していた感覚からするとトラッキング精度は正直よくないです。少し動いただけでもコンテンツの位置がずれてしまうため、見せ方に工夫が必要になりそうなのと、ユーザが動き回るようなコンテンツはそもそも厳しい感じがします。
また、ARKit/ARCoreと比べて、そもそもの機能が少ないです。
どう活用していくか?
現時点でできるだけ多くのユーザにARサービスを提供したいとなると、有力な選択肢になり得ます。
ただ、決して気軽に使える料金ではないのと、提供したいユーザ体験の質に耐えうるかは、Freeプランでしっかり評価した方がいいと思います。
開発に必要なスキルはthree.jsやA-Frameに強く依存しつつ、8th Wall Web独自のAPIについても学習コストが多少発生します。先にthree.js、A-Frameを触ってからでないと独自の仕様に混乱するかもしれません。
逆に、three.js、A-Frameの経験者には使いやすいSDKです。
最後に将来性に関して、余談で少し触れたWebXR APIが標準化されてiOS Safariでも動作するようになると、Web SDKは役目を終える可能性が無きにしも非ずです。といっても1-2年は動きがないと思うので、この間にシェアを獲得できるかが分岐点になりそう。
製品に組み込む際には、将来的なSDKの置き換えも視野に入れておいた方が無難かと思います。