Hatena::ブログ(Diary)

anagma日記

2013-02-20

2つのベクトル定義される面に対して垂直なベクトル - 外積 - cross

法線的な - 鏡の面の法線を外積として表す

鏡の法線と入射ベクトル内積をとる。- 内積 - 仕事量 - スカラー値 - ベクトルではない

三次元反射ベクトル

ofVec3f v = -2*(light.dot(norm))*norm+light;


鏡の向き - 法線で表す - norm

鏡の向きはxとyとで回転(altitude, azimuth)

正面を向いている時(0, 0)

モーターを基準に考えると0, 0の時のベクトル

ofVec3f(0, 1, 0)

unit vector


設定値としては

ユニットの設置向き/場所

x, y, zで回転

latitude, longitude


テスト用にマウスの位置で回転

ミラー中央から太陽に向く光の線

ミラー中央からのミラー法線

ミラー中央からの反射光


画面ではユニットの回転

グローバルグリッドを表示

太陽の向きは北向き基準


時差


ofVec3f v = -2*(light.dot(norm))*norm+light;

単純にこれを逆算しようと思っても、dot(内積)がはいっているのでできないな。

考え方として

・光源

・反射した先

が決まっていて

・鏡の角度

がもとめるべき解


太陽から

反射する先から

の2つベクトルの成す角度の間がとれれば良い。

2次元で考えると、、、



座標系の混乱を整理してクリアにする。

世界を上方向から見た時

上が北

右が東

太陽は東から登って西に沈む


N-E-S-W

北-東-南-西

0-90-180-270


左手系の座標と右手系の座標

一般的な数学空間では右手系の座標

方位では

右手系では東を基準方位とし反時計回りを正の角度とする。左手系では北を基準方位とし時計回りを正の角度とする。

http://ja.wikipedia.org/wiki/%E6%96%B9%E4%BD%8D%E8%A7%92


今、拾ってきて使っているコード左手系南基準

高さについても、左手系なので、右手系に変換

右手系東基準で行こう

f:id:anagma:20130220083954p:image

トラックバック - http://d.hatena.ne.jp/anagma/20130220

2012-07-07

BlackmagicDesign DeckLink StudioでのリアルタイムHD映像取り込みのレイテンシー 01:47

そろそろ始まる年末までのラッシュに向けて、こつこつと準備中


レイテンシー検証をするのに、モニターを2枚/ないしはカメラのプレビューとモニターとを並べてiPhoneカメラ撮影、そのフレームカウント比較する、という力技。

f:id:anagma:20120708014429j:image

f:id:anagma:20120708014428j:image

f:id:anagma:20120708014427j:image


Blackmagic Design、Decklink Studioを使ってのリアルタイムフルHD映像の取り込みに取り組んでる。oFで受けるのにarturoc氏の

https://github.com/arturoc/ofxBlackmagicGrabber

を使えば、簡単に取り込めるのだけど、そのままだとレイテンシーが1秒前後あって、リアルタイム性を重要視する場合実用にならない。BMDの配布してるSDKについてくるサンプルだとレイテンシー1フレームくらいなので、なにか方法があるはず、と探る。

結論としては、取り込んだ映像はそのままだとYUVで、それをRGBへと変換する部分があってそこの処理が重い模様(Xeon 2.8G使ってても3フレーム分くらい)。あとその変換のためにダブルバッファーになってて、それがさらにレイテンシーを酷くしている。BMDのサンプルではCocoa上のPreviewに直接データを送っててどう処理してるのか良くわからない。ただ表示できてんだからなにか方法があるはず。っていうか、YUV形式のままテクスチャに張り込む方法が必ずあるはず。

で、見つけたのがこの記事

http://stackoverflow.com/questions/1080545/how-to-display-a-raw-yuv-frame-in-a-cocoa-opengl-program

GL_YCBCR_422_APPLEのテクスチャ。少しはまったのは、oFで使う場合にofTextureのallocateで形式をGL_YCBCR_422_APPLEに指定するのではなくGL_RGBを指定するということ。allocateする時に指定するのはInternalFormatなので、GL_RGB。loadDataする時に渡すのがGL_YCBCR_422_APPLE。あと忘れちゃいけないのが、allocateした後に、ofTextureのtexData、そのpixelTypeにGL_UNSIGNED_SHORT_8_8_APPLEを指定すること。

とか書いてたら上の記事とちょっと内容が違うな。俺、これ、どこで見つけたんだろ。

とりあえず、arturoc氏のofxBlackmagicGrabber、フレームデータを受けたときのCallback、VideoInputFrameArrivedメソッドの中のyuv2rgbを呼び出している部分やらダブルバッファースワップなんかをしている部分をコメントアウトして、単にIDeckLinkVideoInputFramesのインスタンスからunsigned char配列フレームデータをYUVのままコピー、testAppのupdate内で、tex.loadDataするのに最後引数でGL_YCBCR_422_APPLEを指定すればOK。

あとはfboやらshaderやらreadbackするなり好きにすれば良い。

トラックバック - http://d.hatena.ne.jp/anagma/20120707

2012-06-05

New Adventures in Narratives, Ecstasies - about "ON 02" 02:07

このタイトル意味は、直訳すれば「物語性と快楽の新しい試み」。

なにによる「新しい試み」なのか?

それによって得られる「新しい物語性」「新しい快楽」とは何なのか?


「新しい物語性」、この言葉は、昨年のインドでの滞在制作の時に何度もファシリテーターに対して発言した言葉。その滞在制作で求められていたのは、地元のダンサーとともにビデオダンスを作るということだった。そもそも、地元ダンサーコラボレートできるメディアアーティストという条件で参加した僕にとってはクリエーションの前のワークショップで見せられる無理矢理に形式化された映画的なビデオダンスに対して関心が持てなかった。そんな中で一つのスケッチワークを作る際に、ふと思い出し引用させてもらったのが、前田二郎氏の「ON 02」で試みられていた、フレーム輝度アナライズし、暗いものから明るいものフレームソートし直す、という手法だった。

リキシャーから撮影された夜のデリーの町並み、そのワンショットをその手法で処理する。映像的な意味でのナラティブ - 映画的なナラティブ - ストーリーシナリオ/それによって引き起こされる感情 - リキシャーに乗り、同乗のフランス人風景について話しながら自分たちの部屋まで帰る - そういう流れは失われ(一般的な意味での人の理解できるものではなくなり)、エクストリームなワンフレーム単位カットアップがそこに現れる。

かっこいいビジュアルであるとか、絶妙なタイミング、であるとか、そういう本来映像である要素は排除され、そこにあるのは、適当撮影された素材そのままのフレームとタイムライン上に表されるグラフ的な何か。しかし、その点滅に近い画面が3分の間に徐々に明るくなり、激しい明滅へと変わっていくその構造は、僕にカタルシスを与えるのに充分だった。

映像の「内容」ではなく、その「プロセス」によって語られる物語

New Adventures in Narratives, Ecstasies

http://ekran.jp/event/

ON 02

2000年に発表した72分の映画"オン" は、12万以上のフレームで構成されています。そのフレーム輝度を解析し、暗いものから明るいものに並べ替え、5分の長さに圧縮したものが "on 02"です。

前田二郎

映像作家情報科学芸術大学院大学(IAMAS) 准教授

1969年生まれ。 京都精華大学大学院美術研究科修了。 映像メディアを「未知を発見する道具」と捉え、 コンピュータを用いた自動編集による映像作品や、 規則を基にした撮影行為連鎖から生成される映画などを制作する。代表作に「オン」(2000/香港国際映画祭)、「日々 "hibi" 13 full moons」(2005/山形国際ドキュメンタリー映画祭)がある。2005年よりDVDレーベル"SOL CHORD"の監修を務める。

http://maedashinjiro.jp/

トラックバック - http://d.hatena.ne.jp/anagma/20120605

2012-04-19

光速世界 - mbed 16:10

制御できるものとして、マイクロ秒、ナノ秒世界が広がっているのが、このプロジェクトで個人的に面白いところ。普通にコンピューターを使ってるんじゃあ、逆にそこまでの精度にはたどりつけない。

光の速さは、秒速299,792,458m。1ミリ秒あたり299,792m、そして1マイクロ秒では299mって、光の速度がリアルに感じられるところまで降りてきてるんだよ!

そんな風にツールによって、新しい視点を得ること、感覚拡張されていくこと。これはプログラミングを学ぶこととも同じ。プログラミングを学べば、途端にいろんな現象から、その骨組みが透けて見えるようになってくる。物理という現実世界のSpecification。その仕様に沿ったpre-programmedなものとして世界を眺めることができる。順列都市

__

Arduinoでの高速パルスは結局、これ http://code.google.com/p/digitalwritefast/ を使ってみたわけだけど、それで2tick、125ns。

Timerは http://www.pjrc.com/teensy/td_libs_MsTimer2.html このFlexiTimer2を使った。

ACモーターはやっぱり誤差があって、レーザーシンクできないので、ステッピングモーター世界。使っているステッピングモーターの分解能、500分割を1500rpm(25rps)で回そうと思うと、12.5kHzのパルス必要。いきなり、その速度では、脱調してしまって回らない。ちゃんと加速のカーブを描いてあげなきゃいけないのだけど、そこまでやってると、Arduinoではもうセクシー過ぎてデレデレになってる。

__

かくして、mbed発注、そしてこの高速世界を観測するのにやっぱりオシロスコープ必要だろうと、 http://www.seeedstudio.com/depot/dso-nano-v2-p-681.html?cPath=174 こちらのDSO nano(の一個バージョン古いやつ)も一緒に発注。日本だとSwitch Science http://www.switch-science.com/products/detail.php?product_id=466 で買えます。

mbedのonline editerのUIがださい、とかいろいろ問題はあるけれど、mbed、速い。あっさり250kHzくらいのパルスがハック無しででる。digitalOutのスイッチング速度、上がり下がりそれぞれ2usくらい。ArduinoにおけるdigitalWriteFastがあるみたいに、mbedでもFastIO http://mbed.org/users/igorsk/programs/FastIO/5zey5 があるので、これをうまく利用すれば、ステッピングモーター用のパルスの処理をしつつ、レーザーを細かく刻むにも充分なはず。

DSO nanoも安い&コンパクトな割にきっちり動いて非常にナイス

そして改めてステッピングモーターと戦うわけだけど、mbedの標準のSDKではdelayやTimer(Ticker)が、us単位しか刻めないので、前述のステッピングモーターの加速のカーブが速くなればなるだけ、階段状に上がっていくのが目立ってしまう。そして、6kHzを超えた辺りで、その壁を超えられず脱調。。。パルススピードとしてはまだまだ全然出るはずだから、結局、wait_usをハックしてもっと滑らかな加速のカーブを描かないと、、、

てか、こんなニッチノウハウ、書いてもしょうがないか、、、普通にやる分にはArduinoでFlexiTimer2、もしくはMsTimer2を知ってると非常に便利ですよー、といった具合か。

トラックバック - http://d.hatena.ne.jp/anagma/20120419

2012-04-13

高速世界 - Arduino 04:53

高速の世界指向/思考する。

某企画でレーザーとモーターとの組み合わせである特殊なレーザープロジェクタDIYに取り組んでいる。

モーターとレーザーとの同期がなかなかセクシーなことになってて、ミリ単位(ms)の制御じゃ全然精度が悪くて、マイクロ秒(us)の世界突入している。そして0.003%以下のモーターのフラッターに悩まされ、Arduinoクリスタル(16MHz)の誤差にさらに悩まされる。

モーターの性能としては、オーディオ用のACモーターでも誤差は0.006%とかってなっているからきっと悪くないんだろうけど、オーディオ用のモーターと比較すると回転数が全然早いので、何週も回しているうちにどんどん誤差が集積されていってしまってずれていってしまう。さらにクリスタルも誤差があるからステッピングモーターでモーターをちゃんとArduinoから制御するか、もしくは周回ごとにフォトダイオードなりできっちり同期を取らないと。そしてさらなる高速世界へずぶずぶと、、、

AVRの1フロップはクリスタルが16MHzなので1us辺り16フロップ、1フロップは0.0625us。62.5ナノ秒か。us単位できっちり同期をと思うとArduinoのdigitalWrite関数なんかじゃ(フォーラムによるとdigitalWriteを呼ぶだけで50フロップ程度使用しているとか、、、)遅い。今ちょうどみつけたんだけど

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1226290298

この辺りの記事を参考に、Arduinoではなく、AVRを直に叩く必要がある。それでも速度が足りない場合は、クリスタルを32MHzに交換か、もしくはmbedを使うという手もあるのかも?

そしてそれだけの精度を要求される作業になると、loop関数の中でちまちまやるよりは、Timerを使って割り込み処理をさせる。Arduinoでやるべき作業ではなくなってきているけれど、USB経由で簡単にプログラムの書き換えができるってのはやっぱり助かるので、その部分だけを使って、内部はよりプレーンなAVRプログラミングへ向かう。

mbedはこれまで使ったことが無いのだけれど、ちょろっと見た記事では32bitのプロセッサと96MHzのクロックで、AVR比較するとかなり早いことになってる。とりあえず1枚発注してみて試してみよう。

そんな高速世界はそもそもその振る舞いをちゃんと確認するだけでも大変だ。目で見てその振る舞いは正しいのか、ずれているのかを判別できない。Arduinoクリスタルの誤差はtoneでジェネった矩形波をブザーでならしつつ、コンピュータからも同じ周波数矩形波をならしてその誤差でチューニングを図ったりする。

そんな高速世界

トラックバック - http://d.hatena.ne.jp/anagma/20120413