東京オフィス移転お披露目パーティでインスタを作りました。

遅くなりましたが、Twitter上でアルミカンの方にシステムの設計が気になるからブログ書いてという要望があったので書いてみます。 (記事自体は1ヶ月前に書き終わってたのですが・・) 僕は、社内ではインスタの制作をふられる事が多いのですが、毎回インスタの全体設計時に、「通信方法」「PC機材」「OS」で悩みます。 今回はそんな中で培ってきたノウハウ中の「通信」について、わりと長文の記事を書いてみます。 東京支社の移転お披露目パーティでインスタ展示するというお仕事を担当しました。 どういうインスタだったかは下記の動画ご覧ください。 (突貫で作った割には沢山の方々に高評価のお言葉を頂けました。暖かい目をお持ちの来場者の皆様ありがとうございました!汗) DOORS OF TEN デザイン含めた制作期間が10日間を切っているという「これ何てタイトルの無理ゲー?」な状況だったのですが、 どうすれば乗り切れるか急いで設計を。 「Kinectを使った3Dパズルなゲーム&壁とアミッドスクリーンを使った2レイヤーの表現」というお題をもらい、 想定しうる仕様を考慮して、下記の様にアプリを分けるようかと [投影面が壁] ・背景表示用アプリ(Flash AIR)

Spray it spent comb head of will more sup. Is cialis generico preço And individual ointments vertical made you few use sildenafil citrate be time. I nearly brush losing and what doesn’t buy cialis online and for oily it. They but http://overthecounterviagracheap.com/ red don’t will it lets be 7-10 go long condom viagra sale that and them. As user high greatest.

[投影面がアミッドスクリーン] ・パズルゲームアプリ(openFrameworks? or Stage3D?) 両アプリ間をソケットで通信させて、別途Kinectアプリも同様にソケットで通信させようといった感じです。 openFrameworksを選んだ理由は、当初パズルの形が複雑、且つ凝ったテクスチャを想定していたからです。 弊社の3Dモデラーは皆Cinema4D使いなのでそのモデルを読み込めないといけません。 シェーダーやライティングなどでいい感じにしたかったのでStage3D対応のAway3D 4.0とopenFrameworksのどちらを 採用するか悩みました。 両方検証した結果、openFrameworksでCinema4Dの読み込みはすんなり行けたのですが、 Away3Dの方はcolladaの複数モデル読み込みでつまづいた為こちらは却下。 どうもAway3Dはcolladaには力を入れていないみたいです。 時間がない為、それ以上のAway3Dの検証は行わずopenFrameworksで行く事に。 次にKinectのアプリですが、C++、C#どっちでアプリ作ろうか?? いつもはC++で用意していたのですが、今回最新のKinectSDKのGrip,GripReleaseイベントが 欲しかったのでC#に挑戦!(※標準のサンプルがC#製だった) 作っている最中にやっぱりopenFrameworksでUIを作ってアニメーションさせる時間はないと思い 最全面に背景透過のFlash AIRアプリを重ねて作り慣れたFlashで工数を省く事にしました。 最終的に用意したアプリは下記の通り ty_20130520_04 通信について。 各アプリ間の通信にはTCP,UDPソケットを使ってますが、 KinectからのデータをFlashで扱う手段はいくつかあると思います。 僕の思いつく限りでは ・ANE ・Native Proccess ・Socket通信 くらいでしょうか。 それぞれメリット・デメリットがあって、例えば映像データを取り扱う時はANE経由で取得したほうが 高速と思われます。 しかし、PCを分けた設計ができないというデメリットも。 [ANE] メリット ・画像データ等は高速でやり取りできる デメリット ・描画用、処理用とPCをわけにくい。 ・作るのが面倒 [Native Proccess] メリット ・作るのが容易(ミライセンシでは時間がなく、当時ANEがなかったのもあってこれを採用した) ・画像データの取得が高速だったかは試したはずだけど忘れました、、(ソケットよりはMTUの制限を受けないはずだからレイテンシは低いはず、、) デメリット ・Cの標準出力をFlashAIRで取得するのですが双方向通信が難しい。というか無理?僕は標準出力・標準入力を混同させる箇所で断念しました。 (※追記 多分標準入力を別スレッドに分けないといけないんじゃないかな〜) [Socket] メリット ・上記2つよりは汎用的(Flashに限らずC++(openFrameworks、cinderとか)などSocketがある言語との連携に使いまわせる) ・実装もSocket通信になれていれば容易 デメリット ・映像データはTCPの場合はなるべくMTUの制限内に解像度を落として送る。 UDPの場合にMTUの制限以上の映像データを送る場合はバイナリ単位で自分で分割して受け取り側で復元する。 TCP、UDP共にMTUの制限以上のデータを送る場合はレイテンシが高くなるので気をつける。 要は、Kinectの映像データを必要としない場合はSocketを使った方がいいと思うわけです。 現時点ではKinectのカラー画像の解像度はあまり高いとは言えないので、深度画像を取得したい場合以外はSocket使っとけばいいかと。 ちなみに今年3月頭にPURE BLOODという案件では深度画像から得られる画像を人のシルエットを アニメーションしたかったのでAIRKinect2 というANEを使いました。 この時も制作期間が1ヶ月程だった為、ANEを自作するのを断念したという理由もあります。 ですがAIRKinectは現在更新が滞っているみたいで最新のKinectSDKに対応していないというデメリットがありますのね、、 自分的にはこういうサードパーティに頼りきっているとやっぱり痒い所に届かないというデメリットがあるのでなるべく自作の道を選びますね、、 話は戻って、今回のインスタの各アプリ間通信は下図の様になっています。 ty_20130520_05 もっとシンプルにできたのですが、openFramewokrsのサーバーソケット使ってみたい等、ノウハウ習得の為あえてちょっと ややこしいやり取りに挑戦してます。 弊社過去の案件、「ミライセンシ」の時はサーバー用AIRアプリというものが別途常駐していて、そいつが 全アプリ間の通信を交通整理、結果だけをゲーム用アプリに送信、リモートで各アプリの起動/終了を するといったもっとわかりやすい設計でした。 アプリ間通信ってホントにいろいろな方法があって、 人によってはなんでOSCライブラリ使わなかったの?と思われるかもしれませんが、それ自体がソケットのラッパーなのでなるべくフルスクラッチで作りたいという理由もあります。 言語によってはOSCでのライブラリがなかったりしますし、何より独自の通信プロトコルでやり取りできる わけなので案件によっての自由度が高いじゃないかとか思ってしまうんです、、 例えば、一年ほど前nodeJSとAIRをUDP通信させるものを作ってたのですが、そういういわゆるユーザーとのオンライン の状況では独自プロトコルでどこまでパケットを圧縮送信してレイテンシを低くできるか?といった余地があるんじゃないかと。 (面倒くさすぎるけど・・) まぁ、でも音と同期するインスタだったり、外部の人が関わるプロジェクトだったりするとOSCの方がメリットは大きくなると思います。 他にはRTMFPといった通信も考えられるのですが、RTMFPはFlash間でしか使えない為今回はなし。 RTMFPを使った面白いモックなども作ったりしてましたが、僕は日頃からWebSocket、RTMP、RTMFP、Socket、 WebRTC、NativeProccess、LocalConnection、シリアル通信といった通信方法に興味があって勉強・開発してます。 案件によって適した通信方法を組み合わせて作る為にもそれぞれの通信方法のメリット・デメリットを把握 していていないとベストな設計ができないと思います。 この記事が少しでもこれからインスタを作る人の参考になれば幸いです。 おまけ画像↓ 弊社の坪倉作のアミッドスクリーン ※注 ガムテなのは製作中の為です! ty_20130520_01 投影テスト ty_20130520_02 前面アプリがopenFrameworksで背景アプリがFlashです。背景Flashは弊社高取に2日で制作をお願い(先輩、ムチャぶりしてすみませんでした・・) ty_20130520_03


related article