arduinoからの値でvvvvを操作するアプリ

時間経過とともに反応が悪くなってきた時の対応

 

構成

センサ → arduino → RS232 (Devices) → Tokenizer (String) 

          

arduino / RS232ノードで設定した取得頻度が高すぎた事もあるが、

Tokenizerにqueueがたまり処理できずスタックしていた。

queue modeをdiscardにする。OSCとかも同じ。

vvvv.org

 

連打を防止する

閾値を設けてon/offする処理の場合、S+Hだけで対応できないことがある。いろんな書き方があるがtimerflopで一定時間内の入力は無視する処理にするとマシになる。

vvvv.org

vvvvでスライドショーを作った時にハマったこと

テクスチャ・メモリ管理・.dds

(そもそも正しい挙動かわからないが)

vvvvで.jpgや.pngをtextureとして読み込むと1枚あたり100MB〜200MBメモリ使用量が増える。そのため、数十枚〜数百枚の画像や動画を使って凝ったスライドショー等を作ろうとすると恐ろしいことになる。depthとmipmapの設定等で多少回避できる。

 

公式では.ddsを推奨している。

.ddsファイルはコンバーターで変換して作成する。dxt1〜5でスペックが異なる。恩恵を受けるにはFiletextureのinspectorでformatを"dxT(数字)"を設定する必要がある。

vvvv.org

 

表示のバグ・癖(ハマった所)

表示のバグ?

Rendererでdepthbufferを設定すると一部の画像に黒い縦線が入る。

重なり順が精緻に求められる開発だとつらい。

 

表示されないファイル(読み込んでも表示されない)

vvvv.orgやネット上に落ちてるconverterでは太刀打ちできない謎のファイルがたまにある。元画像のサイズや解像度などに規則性がなく、再現性に乏しいので理由は不明。

→いずれもPhotoshopで変換したらちゃんと読み込めた。

 

ファイルサイズ

どのコンバーターも元のjpgとかpngの解像度を維持して、.ddsに変換するため、ファイルサイズ自体は大きくかわらない。事前にリサイズしてから.ddsに変換したほうがよい。

 

動画と静止画のまざったスライドショー

(最新のvvvvというかdx11 packを試してないからupdateされた可能性もあるが)

 

静止画  →  player(dx11)                    まあ よし(EX9もある)

動画     →   FileStream (DX11.Texture VLC)   nextpinなし。高速に切り替えずらい 

    →   FileStream  (EX9.Texture VLC)   nextpin、preloadでスムーズ

 

実装上の理由で最終的にはdx11で出力したかったので、Filestream EX9で一度renderしてdx11に変換したが動画ファイルでは読み込みのタイミングでうまく渡せない事がある。

 

EX9 →  renderer →  メモリ → DX11から呼び出し 

 

特に初回はメモリまでちゃんと渡してから呼ばないといけない。少し遅延させて読み込ませる必要がある(もしくはcreatenodeなどでノード自体を生成する)

 

FileStream (EX9.Texture

vvvv.org

vvvv.org

vvvv.org

 

 

 

vvvvのkinect v2でcontourする

x64になってから、

この数年まともに触っていなかったが vvvv。

こういったaddonがあるのは知っていたが初めて使った。

vvvv.org

vvvv.org

 

<やりたいこと>

地上にいる人をトラッキングして、人のいる場所の座標を取得して、

クロスケーブルを使って、oscで別pcのunityへ送信。

床面にもプロジェクションするので、可視光のカメラは使えない。

 

<当初の計画>

kinect v2 -> Depth -> Contour -> get postion 

画角の問題から 初代ではなくkinect v2を使う。(持ってなくて買った)

rawで取得できる点群データの処理は重そうなので、

Depthノードの結果を、contourして領域の中央の座標を取得する。

 

< 課題 >

各ノードの64bit対応がまちまち

kinect v2-nodesは x64のみ

・Contour (FreeFrame DShow9)  は、x86のみ

・Contour (CV.Image)も、x86のみ

に対応。

*エリオットのVVVV.Packs.Image自体が、(x86)でしか動かない。

 

< 解決案 >

1. VVVV.Packs.Imageの非公式64bit版を使う。

非公式64bit版はVVVV.Packs.Imageのページのレスの中にリンクがある。

みんな起動時の読み込みから先へ進まない書いているが、2種類ある内の500mb近くある方を使う&packsフォルダーからVVVV.Packs.Image以外を外した状態で読み込む事でクリアできた。

で、この中のContour (CV.Image)を使う。

*ノイズ除去や反転、ID、boundingboxなど機能が予め使えるContour (FreeFrame DShow9) と比べて、そのあたりを自分で実装する必要があるが、helppatchもなく、Delaunayが刺さるくらいしかヒントがない。

Contour (CV.Image)を試してみて、invertや領域化(特定の範囲内の座標を一つのグループとしてID付けする)、boundingboxあたりは実装できそうだが、ノイズ除去やthresholdが内側で何をしてる分からなかったので時間もないし断念。

 

2. kinect v2-nodesの非公式32bit(x86)版を使う

kinect v2-nodesのページのレスの中にある@solroo氏のgithubから落とせる。

*自分の34.2 x86環境では動かず。33.7では動くらしい。

 

3. x64とx86のvvvvを同時起動してテクスチャ共有する

x64で、kinect v2 →Depthをした上で、AsSharedTextureを使って、pointerをwriterでテキストに書き出す。そのpointerを使って、x86のvvvvでテクスチャを呼び出す。

vvvv(x86) を起動するときに、/multipleを付けて起動するとvvvv(x64)版と共存できる。

*共有のレイテンシーは気にならないが、dx11とdx9の変換で少し遅い。

 

< 結果 >

3を使った。

syphonもレイテンシーがなければ使えそうだけど、

別アプリを使う必要もないのでこのまま。

 

 

vvvv_45beta31.2 64bit メモリリーク

本がでた vvvv ですが、いくつか。

新しいシステムをdx11 で作ったんですが、これまでとだいぶ別物でした。

今後、dx11 系で開発が進んでいくとしたら再度勉強が必要だと思います。

パーティクル系はdx11 のが使いやすいかな。

 

1.最新版、vvvv_45beta31.2 64bit で、メモリリークを確認

change log みると、メモリリーク直したって書いてあるんだけど、まだ治ってないところがあります。32bit で 安定してるものが、64bit だと、ガンガン増えていく。長期運用だと、メモリ増えまくって死亡というパターンがvvvv ではあるので、

そのあたりベンチマークした方が良いです。

 

2.DX11 を使うと 映像に書き出せない。

dx11 の renderer に対応した、as texture がないので、writer につなげないので、vvvv 単体で、書き出せない。fraps とか使った方がよさげ。

 

 

 

 

 

 

 

vvvvからFBに投稿する。

vvvvからFBに投稿するプラグインがあったので試してみた。

http://vvvv.org/contribution/basic-facebook-graph-api-dynamic-plugins

 

・アクセストークンを取得して入力

・ページに書き込むには、FacebookPostToWallNode.csの

string theURL = "https://graph.facebook.com/me/feed" を

string theURL = "https://graph.facebook.com/  pageID  /feed"

 

にする必要がある。

 

画像はページだと直でアルバムやタイムラインに入らないので、

もうちょっと要調査。