くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | ]

2010-02-22

_ 日記

金曜は結構な時間たちっぱなし歩きっぱなしで疲れて、土曜はでかいカラーボックスを組み立てて疲れた。

画面転送受信のDirectShowFilterがどうしても動かないわーと困っていたら、普通にCapture Filterの作り方がドキュメントにあるじゃないですか。なんでこれ見落としてたんですか。

いろいろ実装しなきゃいけないインターフェースが判明したので実装してamcapでもちゃんと取り込めるようになった。わーい。だがしかし。まだWMEでエンコするとすぐ止まっちゃう。でもこれはなんか分かったぞ。

音の取り込みをやめてみたら正常にエンコできたのでこれが正解だね。IReferenceClock使って音のタイムスタンプと同期してあげないといけないのであった。

というところで日曜朝の配信は終わり。今更ながら、しかしまだ混んでるアバター見にいくよ。

…そんなわけでアバター見てきたよ。

ストーリーは架空惑星の大自然を原住民の生活を通して紹介する環境ドキュメンタリー映画なので特にどうでもいい。

3Dも特にどうでもいい。

おわり。

いや、終わりかよ。

まあ本腰入れて3D使うとこうなるよといういい例だったんじゃないでしょうか。2D+αとしての3Dというか、3D自体を目的にしてない3Dはこんなもんというか。

一緒に行った友達はもっと物が飛び出してきてびっくりさせるのかと思ったらそうでも無かったという感想なようだし、俺も思ったよりそういうことやらなかったなぁという感想もあるんだが、でもやっぱりこれからちゃんと3D使うならそんなもんだろうなぁと。物が飛び出してきてびっくりさせるのは疲れるし最初だけだもんねぇ。

飛び出してきてびっくるはほぼ無かったが、奥行き感というかスクリーン面より手前の表現はすごい良くできてて、なるほど映画館なら3Dはいいなぁと思えた。

これを家のTVでやるとディスプレイのサイズ的に飛び出し感がものすっごく薄れちゃうので、3Dテレビで家でも映画館のような3D!とか思うと残念なことになるかもしれない。

とりあえず100円ショップで色セロファン買って帰って赤青メガネ作ろ。

_ 日記その2

日記続き。

赤青メガネはあらためてなかなか良い。

日曜の夜もやっぱり配信。DirectShowFilterの続き。

いろいろ実装してもやっぱりWindowsMediaEncoderさんは時間指定された操作が間に合わないとかなんとか吐いて動かなくなってしまう。こまったこまった。

そんなこんなやってるうちにフィルタが起動されなくなってしまった。本来だったらフィルタのPauseが呼ばれるところで呼ばれなくなってそこからRunも何も呼ばれない状態。

これはフィルタのデバッグやってるとたまに起きるのでそんな時はOS再起動。しかし再起動しても直らず。はて?これは俺が悪いのか。

オーディオの入力を外すと上手く動くのでやっぱり同期の辺りでなにかミスった気がするんだが、それっぽいところを削りまくっても改善せず。1時間以上ずーっと悩んで分からなくなったのでもう一回OSごと再起動したら動きやがった。あれー?

これは一体何をかかえこんでるんだろうなぁ。今気付いたけどDeviceMonikerとかなんとかのせいなのかなぁ。

ともあれ再起動すれば動くのはわかったので、あとはタイムスタンプをいろいろいじってなんとか動くようになった。タイムスタンプはやっぱり0から始まらないとだめだったんですね…。

fps制御はまだ上手くいってないものの、それ以外はやっとまともに動くようになった。かも?

少なくともamcapとWindowsMediaEncoderではいけそう。Expression EncoderさんはWMEさんより気難しいのでまだだめかもしれない。

こんどこそこれで配信できるようになるかなぁ。

_ [Ruby][COLLADA] ruby/dae日記

RenderStateのスキーマ書けたぁっ!

texture1Dとかが意味わからなかったのはxsd見たらわかった。texture1Dのvalueやparamは属性じゃなくて子要素で、value要素の中身がsampler1Dとかと同一っていう意味だったようです。

あの仕様書からそれを読み取れる人間なんて居ないって。せめてvalueが要素ならそう書けよと。

あとはそんなに難しいところもないのでさくさくとコピペしていったらRenderState全部書けてしまった。 ほとんどがコピペで済むから思ったより全然楽だったな。 これのおかげでファイルがやたらと長くなっちゃったのがめんどいけど。

FXもあと半分無いくらい。これなら思ったより早くまとまりそうだな。

_ [Riko] Riko日記

ほとんど出来たわーとか思ってテストをちょこちょこ書いてたら、シェーダへのテクスチャサンプラの指定が上手くできないことが判明。これめんどいんだよね…。

OpenGLではシェーダへのサンプラ指定はテクスチャユニット番号を渡せばよい。

サンプリングしたいテクスチャは指定しといたテクスチャユニットにBindしておけばおk。

これ自体は簡単ですね。

テクスチャユニットはグローバル、というかコンテキストグローバル。 シェーダパラメータというかuniform変数の中身はシェーダプログラム毎に保持。

これによりシェーダにこのテクスチャを読んでねって言う時にコンテキストとシェーダの2つにパラメータ設定しないといけないんだよね。これはめんどい。

ということでシェーダに直接テクスチャオブジェクトを渡してあげて、シェーダは適当にテクスチャユニットを割り当ててそこにテクスチャをBindするようにした。

これでは環境マップみたいにどうせどんなシェーダでも使うテクスチャが、シェーダ毎に別なテクスチャユニットに割り当てられてあっちこっちBindし直されちゃうかもしんない。それは気持ちわるいのでプログラムから割り当てるユニット番号を指定もできるようにした。

しかしなんでこんな構造になってるんだろうなぁ。OpenGLではテクスチャ自体とサンプラがいっしょになってテクスチャオブジェクトになってるし、シェーダにそのままテクスチャオブジェクト番号渡すのでは駄目だったんだろうか。その方が使う側としては楽なんですけど。

上に書いたような、どのユニットにどのテクスチャ割り当てるかでとっかえひっかえしないといけない問題が出ちゃうからだめ?でもOpenGLのテクスチャユニット番号とハードウェアのテクスチャユニット番号が一致してる必要はないから、ドライバでなんとか適当にできもするんじゃないだろうか。

まあ今更仕方ないんですけどね。でもテクスチャのBindにはいつもめんどうな思いをさせられるのでもう少しなんとかならんかと思うところ。

それはともかく、とりあえずGLSLでは実装はできた。これで問題なければあとアセンブリシェーダと固定シェーダに実装しておっけーですね。

いつまでもライブラリレベルをいじってるわけにもいかんから、そろそろデスクトップマスコットに戻りたいなぁ。今週中になんとかとりあえずでも手をつけはじめたい。


ページのトップへ | トップ «前の日記(2010-02-18) 最新 次の日記(2010-02-24)» | 編集 | kumaryu.net by kumaryu