他の調査と実装も平行していることが大きな原因の 1 つですが、Tango を用いた開発についての情報が少ないことや (公式ドキュメントも説明が足りない)、Android での 3D グラフィックス実装に対する経験のなさから難儀しています。
Unity から Java への移行
始めは Unity で開発を進めていましたが、途中から Java での開発へ移行しました。
このまま Java で進めようかなと。
3D の経験は僕自身が趣味レベルですし、まして会社はその分野に何一つ関係していないため、OpenGL を直接使うよりも Unity をベースにした方が適切だろうと始めは考えたのですが、最終的にはやりたい事が Unity にマッチしないという判断をしました。
今はツール的な意味合いの強い AR アプリを目指している所で、Android の標準 API で提供される UI との統合がどうしても欲しくなります。
また、クラウド サービスを前提にしており、多様なデータのリアルタイムな送受信や同期なども必要です。
Java ならば Android 標準 API で簡単に出せる UI があるのに、Unity 上で同等の UI を自作するのはナンセンスですし、僕らはクロスプラットフォーム開発を必要としていないため、Unity のプラグインを作ることもナンセンスです。
また、Unity では通信関連ライブラリが充実しておらず、これにも自作やプラグインの問題がまとわりつきます。
どのようなツールもライブラリにも想定する利用方法が必ず存在し、その想定にマッチする場合は恩恵を得られ、さもなくば足枷になります。
そして、僕らのやりたい事は Unity の想定から外れているため、他の方法を選択すべきということです。
でまぁ・・・それはそれでキツイなぁ、と。
Rajawali の利用
Android の OpenGL API を直接使うのもキツイので、今は Tango の公式サンプルで利用されている Rajawali という 3D ライブラリを利用しています。
Rajawali/Rajawali | GitHub
Rajawali は、Android OpenGL API のラッパー群を用意し、更にシーンを作るためのフレームワークや各種 3D モデルのロード機能などを備えている感じです。
Rajawali のソースコードを見ていると、Android での 3D 実装未経験の僕にとって勉強になりますね。
Java には構造体がなく、プリミティブ型以外の全てがオブジェクトとなるため、GC 効率に対する考慮が随所に見られます。
Vector3 や Matrix4 では、あえてメソッド元オブジェクトの状態変更で new を避けられるようにし、オブジェクトを new したい状況のためには専用の静的メソッドが提供されていたり、clone メソッドが用意されていたりします。
あるいは、演算中に発生する短命オブジェクトを避けるために、クラス内部でキャッシュを設けて上手く処理している部分が多く見受けられます。
でもなぁ・・・と。
ラッパーを使うと、どうしてもラッパー オブジェクトの new が発生するんですよね。
Tango から得られるベクトル配列や行列配列に対してラッパー オブジェクトの new が発生しますし、ラッパー メソッド内部では Android OpenGL API からの戻りで得られる配列に対するラッパー オブジェクトの new が発生します。
まぁ、あまり拘り過ぎると物が出来なくなるので、まずはこれでやってみようという感じです。