• ホーム
• 購読申込
• ヘルプ
• アーカイブ

BOW cARd：AR（拡張現実）を使った「遊んでもらえる名刺」

制作会社「BOW」さんの名刺の裏には、ちょっと大きめのカラーコードが印刷されています。そのカラーコードを Webカメラ にかざすと、なんと、かわいいキャラクターが映像上に登場して呟いています！　今話題の AR（拡張現実）を使った名刺「BOW cARd」なのです。その仕組みについて、BOWさん に解説していただきましょう。

このコンテンツの制作に取り掛かったのは2008年の11月、我々 BOW が活動を始めて少し経ってからでした。
「渡した相手に遊んでもらえる名刺」を目指して、当時流行のきざしを見せていた FLARToolKit を使うことにしました。名刺なら自然な形で相手にマーカーを渡せるため、FLARToolKit との相性が良いと考えたからです。
テストは順調に終わり、メンバー3人のマーカーパターンに個別の3Dモデルが出せたところで、「名刺交換した人の名刺も作ることができる」というアイデアが追加されました。

マーカーパターンが増えても対応できるようにする

このアイデアの実現には二つの壁があります。
FLARToolKit が標準的に備えている複数マーカー識別の仕組み (FLARMultiMarkerDetector) は、カメラに写る可能性のある全てのマーカーパターンを初期化時に登録する必要があります。
このため、マーカーパターンを動的に追加することが難しく、またそれが可能になったとしても、登録されたマーカーパターンの種類が膨大になった際にパフォーマンスが低下することが明白でした。

そこで、登録したパターンから探す代わりに、パターンに共通の法則を持たせることで認識を行い、その後パターンを読み取ることで名刺を識別するという方法を採ることにしました。

カラーコードの設計

パターンを読み取ることでデータが取り出せるということは、つまりバーコードや二次元コードのようなものです。当初は QRコード が使えないか考えてみましたが、低解像度の Webカメラ で認識するには細かすぎるため、カメラを自由に動かしたい AR には不向きと判断し、独自設計することにしました。

独自設計に当たって、以下のようなことを考慮しました。

• 色（白黒にするか、カラーにするか。カラーなら何色使うか）
• 方向識別
• 誤り検出・誤り訂正
• グリッドの分割数

まず色ですが、白黒だと認識の精度を保ちやすく、カラーだとセルごとのデータ量を多くできます。
今回4色のカラーコードにしたのは、QRコード を使わなかった理由に同じく「できるだけグリッドの分割数を減らして単純な模様にしたい」という判断ですが、名刺に刷った場合の見栄えも考慮に入れてあります。
使用する色は、家庭用プリンタでもきれいなコントラストが出せるように 100% の CMYK を選びました。

次に方向識別です。カメラにマーカーが写った際、90度単位で倒立した状態を見分ける必要があります。
マーカーの天地が分からないとコードを読み取れないし、3Dモデル を表示する際もどちらに向けるか決定できないからです。
今回はルールを単純にするため、「4隅のセルのうち、左上は常にシアン。残りは黒かイエロー」と決めました。

誤り検出・誤り訂正ですが、これは予め余分なデータを持たせておくことで、一部が正しく伝わらなかった際に、そのことを知る（検出）または元に戻す（訂正）という仕組みです。この段階で試作したマーカーを認識してみたところ、時折1セル程度の色判定を失敗することがあり、誤り訂正が有効と判断しました。
誤り訂正にもいろいろな方式がありますが、実装の容易さと動作の軽さから、ハミング符号を使用しています。

最後に、ここまでの決定事項と目標とするデータ容量からグリッドの分割数を決定します。 グリッドを5分割し、25セル から方向識別を抜いた 45bit のデータビットを使い、(15,11) ハミング符号を3ブロック収めると、33bit の情報ビットが確保できました。名刺の ID を表現するのには十分なサイズです。

こうして、カラーコードの仕様が決まりました。
折角なので、メンバー3人のカラーコードは意味のある見た目にしようと思いつき、5*5 のセルに収まるドット絵を数点描きました。しかし適当に描いた絵ですので、適切な ID をエンコードしたものと違い、データ上の誤りを含みます。そこで絵を描くとデコード・再エンコードしたカラーコードを隣に表示するツールを作り、左右の絵が同じになるまで色を変更して調整しました。その結果、吉川と高橋の名刺は笑顔のマーク、石崎の名刺は漢字の「石」になっています。

アバター同士がつぶやき、挨拶する

名刺は「挨拶」するためのツールですので、その上に表示されるアバター同士にも、勝手に挨拶をさせようというアイデアが出ました。名刺の上に出るアバターは普段ぼーっと立っているだけですが、その前に別のアバターがいる場合はそちらに駆け寄り、お互い相手の前に立つと挨拶を始める、というルールです。

「自分の前に別のアバターがいる」という条件判断は、FLARToolKit がマーカーから計算した姿勢行列を使うのが順当かと思いましたが、この方法はうまく動きませんでした。現実の空間で2枚の名刺を向き合わせた場合でも、微妙な誤認識から、まったくかみ合わない2つの姿勢行列が返る場合があるからです（カメラからの距離が大きくずれ、スケールも異なるため、投影すると自然に見えます）。

そのため 3D での判定はあきらめ、マーカーの4隅のスクリーン座標から計算した 2D 上の「視野ボックス」に相手のマーカーの中心が入っているかを計算するようにして解決しました。

さらに、名刺の持ち主の Twitter での発言を表示することで、アバターにしゃべらせるようにしてみました。目の前に別のアバターがいる場合、その持ち主への発言が表示されます。

ユーザが自由にアバターをデザインできるように

サイトに来てくれた人でも自由に自分のアバターが作れるような仕組みを作ることにしました。

典型的な FLARToolKit アプリケーションと違い、BOW cARd では PV3D を使わずに Flash Player 10 の 3D描画API を直に呼び出しています。動作の軽さと、後々面白いことができるのではという読みがあったためですが、これらの 描画API には制限も多いため、それに合わせた作り方を選ぶ必要がありました。

具体的には、描画に使う Graphics#drawTriangles メソッドの呼び出しが複数回にわたっていると、パフォーマンス上のメリットが得られにくくなり、またZソートが複雑になるため、アバター1体を1回の呼び出しで描画しています。
アバターの 3Dモデル は Metasequoia で行い、mqo ファイルを Perl スクリプトで AS3 のクラスに変換しています。

胴体や足や耳など、全てのパーツバリエーションをひとつの頂点 Vector として保持し、レンダリング時には必要なパーツの頂点インデックスだけをマージして、Zソート して drawTriangles に渡しています。

ユーザがアバターに直接お絵かきできるように

ユーザが作ったアバターがサイトに増えてきて、パーツの組み合わせだけでは個性が出せないので、お絵かき機能を作ることにしました。テクスチャそのものを展開図として表示し、そこに描き込んでもらう方法を良く見かけますが、今回はそれをせず、3D 表示されているアバターに直接描き込めるようにしています。

処理の手順ですが、まず描き込む際にマウスのスクリーン座標を取得します。次に各ポリゴンをカメラに近い方から走査していきます。もしそのポリゴンの3頂点のスクリーン座標が、マウスの座標を内包していた場合、3頂点の UV値 から現在の UV値 を一時補完してテクスチャ座標を得ます。

ここで、これらの処理がレンダリング直後に行われる場合を考えます。レンダリング直後では Zソート が済んでいるため、各ポリゴンがカメラに近い順に並んでいます。また、ポリゴンの3頂点のスクリーン座標も計算が終わっているため、これらの走査が非常に低コストで行えます。

こうして直接描き込める仕組みができました。投影変換の逆変換を考慮していないので若干思い通りに描けない部分もあるのですが、それでも直接描き込めるのは楽しいです。

などなど、「自分たちの名刺を作りたい」というところから始まって、気がつけば色々な機能を追加していました。

Flickr と連動した記念撮影機能や、プリンタが無くてもその場でマーカーが出せる iPhone サイトなど、ここで紹介しきれなかった機能もあるので、ぜひ自分のアバターを作って遊んでみてください！

‹ 戻る