今日も暑い一日だった。 例年暑くなるのってこんな時期だっけ。 そうかも知れない。
先月は ASKA の逮捕騒ぎで芸能ニュースがにぎやか (?) であった。 薬物で捕まった歌手といえば槇原敬之とか長渕剛とか、最近では酒井法子とか、そういうのが記憶にあるが、調べてみると長渕剛は大麻 (起訴猶予処分)、槇原敬之と酒井法子は覚醒剤であった。 やっぱり一番印象に残っているのは槇原敬之で、当時自分が高校生だったのもあるけど、毎週ラジオ番組やってるのを知ってたし、毎年何かしらランキングに入るような曲を出していたイメージがあって、そんな中で逮捕っていうんだからそりゃびっくりするわけで。
それに比べると、チャゲアスってのはもちろん名前は知ってるけど、ファンだったわけでもなく、もう人気だった時期は過ぎたよねっていう感じなので、ふうん、っていう感じではあるが、報道を見る限り、CHAGE が一番かわいそうな事件でもある。
そうそう、某電子掲示板で盛り上がったのは田代まさし、一応歌手だったんだな。ASKA もあんなふうにならなければいいんだけどねぇ。
WebGL を昔ながらの 2D スプライト表示に使うにはどうすればいいか、そんなことを考えていたのだが、たぶんアルファ値を使って透過部分と絵の部分をうまく描けば、あとは前後関係は最後に描画したのが一番上ってやつでうまくいくのかなと思っていた。 でも実際に試してみないとね。 ゲームとか大げさなのじゃなくて、とりあえず、非常にお手軽なテストプログラムで。
実際やってみたところ、アルファブレンディングをちゃんと有効にしないと、白い三角形が見えてしまってうまくいかなかったし、アルファブレンディングのブレンド関数を固定の ONE にすると、前後関係がなく、とけ込むような表示になってちょっとおもしろかった。 どういうしくみでそんな不思議な結果が出ていたのかはよくわかんないけど、とにかく、普通のブレンド関数を設定すれば、割と予想通りの素直な 2D スプライトっぽいのが実現できたように見える。
あ、これはテクスチャーは使って無くて、シェーダーで黒い縁付きの黄色い球を描いている。 球が三角形の内側に収まるように JavaScript 側から座標を与えている。...四角形ではなくて、三角形にすることで頂点数を減らしたが、そのぶんフラグメントが増えるのだからどれだけ意味があるのかはよくわからない。 めんどくさいので vec4 の xy に三角形の頂点座標、zw に球描画のための xy 座標 (球を x*x+y*y<1.0 の範囲に描画するとする) を入れて渡すという構造にした。 いかにも 2 次元グラフィックス用。
ThinkPad X201 (Core i5 560M) の Linux 上の Chromium で、16k 個くらいまで 60fps を保って表示できている。 これがよい結果なのかどうかはよくわからない。
まぁうまくはいったんだけど興味深いのは、たぶん GPU は頂点座標を求めるシェーダープログラムを並列実行しているんだと思っている。 フラグメントシェーダーも並列実行だと思う。 でも最後に描画する時はこちらから指定したとおりの順番で描画されている。 いや、確実にそうとは言えないが、少なくとも重なり合っている部分に関してはそうでないとつじつまが合わない結果となっている。
WebGL のシェーダーを使って例の N クイーン問題のアルゴリズムを実行させられないか不真面目に考えている。 とりあえず、これなら整数演算なので、結果は適当に色を割り当てて表示してしまえばいい。 頂点シェーダーを使うか、フラグメントシェーダーを使うかというのはあるが、色で答えを出すということは、ひとつのフラグメントで 16,777,216 通りしか表せないことになるので、それを超えるような結果が出るとフラグメントシェーダーでは困る。 まーそんな結果が出るような処理が動くのかは怪しいところだけど。
頂点シェーダーを使う場合 varying 変数でフラグメントシェーダーに結果を渡すことになるだろう。 線分の描画なら 2 点の頂点について値を出す必要があり、それが GPU 側で補完されてしまう。 ということを考えれば、例えばひとつのフラグメントで 1 ビットの結果を表すとしたら、ビットに分解するのも頂点シェーダーで行う必要がある。 そして結果を入れる varying 変数には 2 値しか入れないこととし、線分の片方の頂点に結果、もう片方には 0 を入れて、線分の長さを十分に取れば、補完されてもフラグメントシェーダー側で 2 値の判定が行えるはず。
とかいうくだらないことを考えていたら、ぎゅうぎゅう詰めで結果を返そうとすると 1 ピクセル単位できれいに埋めたくなるわけだが、そういえば座標が浮動小数点なので、どうなるのかよくわかっていなかった。 今まで書いたテストプログラムは canvas の幅と高さを 500 と指定している。 それで、(-1,-1) から (1,1) の矩形の塗りつぶしを描画するとき、フラグメントシェーダーで Y 座標を整数値に変換してみた。
int inty=int((y+1.0)/2.0*500.0);
どうやらこれで、0〜499 の値が得られる。inty/2*2==inty という条件を使って色を変えれば、きれいに 1 行ずつ交互に色が異なる行が並ぶ。 へぇー。500.0 を 499.0 にしたら、きれいに交互じゃなくなって、真ん中あたりが太くなってしまう。 つまり Y 座標の範囲が [-1,1) ということか? と思って y==-1.0 というような条件を入れてみたらそれは成り立たなかった。 微妙に -1.0 より大きく 1.0 より小さい範囲におさまっている? うーん。
Google Chromecast というテレビ・ディスプレイの HDMI 端子に差し込んで使うものが発売されたらしい。4,000 円ちょっとぐらいだとか。HDMI 端子搭載のテレビやディスプレイを持っていないので買っても使えないんだけど、買った人に聞いてみると、タブレットの動画再生にはよさそうだけど、PC つなぐなら Apple TV でいいし、的な様子だった。 へぇ。 タブレットや携帯端末で画面が小さくて動画コンテンツに手を出す気が萎えていた層にはうけるのかも知れない。
Surface Pro 3。 スレート PC、という呼び方は死語か。 画面サイズが大きくなって 12 型、ThinkPad X201 とも同じくらいのサイズで悪くはないが、PC としては持ち運び用の部類なんだろうなぁ。 解像度が少し高めなので文字サイズを大きくしないと目に厳しそう。 そのへんは Windows より Android のほうが選択肢の自由度が高くていいんだよなぁ。
iOS 8。 ガジェットじゃないけど。 サードパーティー製 IME にも期待が持てるが、WebGL 対応というニュースもあった。 やっとか! iOS 搭載端末は過去の経緯からいって数年間はサポートされる見込みがあるため、Android 端末よりは人にすすめやすいところはある。 文字サイズが小さい欠点は解消されないのかな。
「アナと雪の女王」(原題: Frozen)。 映画館で。 字幕版。 声はアメリカ英語。
最近のディズニーらしいアニメーション映画。 ミュージカル調だったので、ヘアスプレーという映画を思い出した。"for the first time in forever" ってせりふが何度も出てくるんだけど、よく考えると不思議なフレーズである。
ストーリーもよかったけれども、コンピューターグラフィックスを見て感心していた。 氷とかガラスみたいな透明で反射するものの表現といえばレイトレーシングだが、使われているのだろうか? それにしてはアニメーションらしい感じになっているのはピクサーらしいというか、あえてレイトレーシングはやってないのかも知れないと思った。 そして、アニメーションだから、コンピューターグラフィックスだから、実写よりもお金がかかっていない、なんてとうてい言えないようなできばえ。 実際、ノルウェーでリサーチが行われたらしい。 それから、例えば歩き方、走り方、歌い方や、髪の毛、ドレス、船、飾りなど、様々な物体の動きが比較的自然で、実際の人や物の動きをトレースした部分もあるのかな、なんて考えると、なかなか。
以下の動画はネタバレになるので注意。 映画の前に 25 か国語版を見てたけどね。
FROZEN - Let It Go Sing-along | Official Disney HD - YouTube
最後のエンディングクレジットのところでこの曲が流れてきたので立つのをためらった。 別の曲になったところで退出。 トイレに行きたかったのと、例によってアメリカ合衆国の映画ならエンディングクレジットに何か演出はつけないだろうと思って。 調べてみたらちょっとだけおまけがあったみたい。
梅雨入りか?
がとけた。
この見るからに怪しいプログラムは、フラグメントシェーダーで Y 座標の浮動小数点数を固定小数点のビット単位にして色で表示し、それを JavaScript で読み取り数値化するもの。Canvas に表示されているのは、左端に出る模様が数値を表すビットパターンで、残りはただのグラデーションである。
結果としては、渡されてくる Y 座標を fy、高さを h ピクセル、画面上のピクセルの Y 座標を iy (下を 0 として範囲は 0〜h-1) とすると、fy = iy / h * 2.0 - 1.0 + 1 / h となっている。 何なのかというと、これを 0 以上 h 未満の整数に変換する場合は int ((fy + 1.0) * h / 2.0) とするわけだが、これは (fy + 1) * h / 2 = (iy * 2 + 1) / 2 = iy + 0.5 となるから、小数点以下を切り捨てることできちんと変換できることがわかるし、また、0 <= iy <= h - 1 より -1 + 1 / h <= fy <= (h - 1) / h * 2 - 1 + 1 / h = 2 - 2 / h - 1 + 1 / h = 1 - 1 / h となることから -1 < fy < 1 であることがわかる。 あと、2 進数の浮動小数点なので、大きさに 10 進数できりのいい数字を選ぶと循環小数で見苦しくなる。 気になるなら大きさを 2 のべき乗とかにしておくとよい。
X 座標も同じ概念に基づいて説明できると考えられる。 ちなみに ThinkPad X201 の Debian GNU/Linux 7.5 と AMD A10-6700 の Ubuntu 14.04 ではわずかに誤差があることもわかった。 もちろん 2 のべき乗サイズなら誤差はないのだが、高さ 100 だと微妙に違いが現れる。 整数値に変換してしまえば安心。
どう見ても梅雨入りです本当に、みたいな天気。 まー関東はシラス台地みたいに弱くはなかろう... と思ったら高尾で避難勧告とか出てて、対象世帯は 1 桁なものの驚いた。
WebGL のフラグメントシェーダーで gl_FragCoord というのを参照すると、フラグメントの座標を得ることができるらしい。 っていうのでそれの結果も出してみた。
こっちは -1〜1 ではなく、通常の座標になっているらしい。 やはり 0.5 が足されているのだが、100 で割られていないため循環小数にはなっていなくてきれいな数字になっている。
テレビでやってた映画。 邦題「ダーク・シャドウ」。 古い英語なのか、主役が何を言っているのかさっぱりわからず、字幕に頼るしかなかったw
くすっと笑えるようなシーン、他の映画のオマージュなのかなみたいなシーンがちりばめられているが、最初の 30 分くらいのところで一瞬ホラーかと思ったところがあった。 他のことをやりながら見ていると一瞬ストーリーについていけなさそうなところもあったが、わかりやすいストーリーになっていたので問題なかった。 最終的には魔女が死んで恋人が助かってめでたしめでたしなのかな? あれは助かったといえるのか?
時間あたりの降水量はたいしたことなくても、ずっと降り続いているから、例年にくらべて相当多い降水量になっているらしい。 中央道が一部通行止めになっていたりして、そういえば九州自動車道も大雨で規制とかたまにあったなぁというのを思い出した。 まぁシラス台地はちょっとした大雨で崖崩れとかあるからだけど、関東平野はそういうの聞かないのにね。 都心では台風で冠水ってのがあったか。
この人、1991 年・1992 年頃の東京のいろんな風景の動画を大量に YouTube にアップロードしてくれている。 当時は東京なんて来たことがなかったけど、当時の映像がこんなにたくさん見られるのはある意味貴重な気がする。 道を走っている車やトラック、お店の自販機などは、鹿児島市内でもこの映像とそれほど差はなかったように思う。 公共交通機関の車両はたぶん鹿児島よりずっと新しいものだろうけど、どれも今となっては引退した車両ばかりのような... 西武の旧 101 も、乗ったことはあったけどなくなったしなぁ。
東京に引っ越して 5 年、結構知っている場所もあったりして、22 年前からのいろんな変化が見られるのがおもしろい。 例えば渋谷駅が自動改札じゃないなんて、今となっては想像もつかないレベルだが、そんな様子がうつっていたりする。 多摩川線は今も 1 駅を除いて自動改札じゃないけど、ほとんどの人が IC カードを使っているから、たくさんの切符をカチカチする光景はさすがに見られない。 駅員さんに切符を渡してもスタンプを押してくれるだけだし、ギリギリに行ったらそれさえしてもらえないし。
テレビでやってた映画「美味しんぼ」。1996 年の邦画。1996 年といえば、Windows 95 が出た次の年、小室ファミリーとか流行ってた年、なんだけどやっぱりこうして映像として見るとやけに古くさく感じられる。
漫画のほうは今でも連載が続いていて、最近は福島県の原子力発電所事故に関する描写が過激というのが話題らしい。 原作は昔歯科の待合室にあったのを少し読んだっけ。 あと近所の弁当屋にあったかな。 ま、それはどうでもいい。 この映画、山岡士郎役の佐藤浩市と海原雄山役の三國連太郎が、役としてだけでなく、実際に親子というのがある意味見所かなと。 ストーリーは例によって究極のメニューと至高のメニューの対決があるが、2 度の対決の後、煮豆の話で親子の関係の変化が表現されている感じ。
きのう作った WebGL でポイントスプライトとやらを使って描画するテストプログラムがこれである。
WebGL 2D Sprite Test Using Point Sprites
うまくいったから満足していたのだが、そういえば、円の塗りつぶしを描画するフラグメントシェーダーのコードで、円の中心からの距離を出すのに、今回、どこかの web サイトで見かけた、ベクトルの内積を使う方法を使ってみたのであった。v.x*v.x+v.y*v.y のようにしていた部分を、dot(v,v) のようにして、それっぽく出ていたからいいだろうと満足していた。
冷静に考えてみると、ベクトルの内積といえば、大きさとその間の角度の cos をかける、みたいな感じで、同じベクトル同士ならば、cos は 1 になるから、大きさの 2 乗で、すなわち v.x*v.x+v.y*v.y と等しい、ということは導けた。 でもハードウェア的にはいちいち角度を求めているはずがない。 たぶん dot(u,v) は u.x*v.x+u.y*v.y で求まるんだろう、と、適当な数字を当てはめてみると確かに成り立つ。 うん、きっとそうだ...
Web で調べたら、証明があった。 ふたつの 2 次元ベクトルの内積を求めるとき、それぞれ横だけの成分のベクトルと縦だけの成分のベクトルの足し算で表現することで、証明できるらしい。 ふむむ。 どうみても高校の数学で容易に理解できるレベルの証明だ。
っていうかどうやら、幾何学的な性質である、大きさと角度の話はむしろ後付けで、u.x*v.x+u.y*v.y が出だしっぽい感じ。 各要素をかけて足しましょうみたいな簡単な計算で、間の角度とかわかっちゃうよこれは便利、みたいな、そういう話っぽい感じがしてきて、なるほどねーとか思った。
で、内積を使うと、30 度・45 度の cos/sin の値から、15 度の cos/sin が求められる、なんてことに気づいた。 加法定理とか半角の公式とか、なんかそういうのは覚えていないけど、内積は大変簡単な概念で、30 度・45 度で長さが 1 のベクトルの内積を求めればいいのだから、暗算で 15 度の cos 値が求まる。 っていうかもしかして、7.5 度とかでも求められるのかな。0 度と 15 度で長さが 1 のベクトルを考えて、それぞれ 7.5 度で長さが 1 のベクトルとの内積を求めればそれらは一致するから云々... もしかしてそれが半角の公式か?
というわけで、不真面目な学生生活を送ってきていたことを証明したところで、今日の話は終わりとしよう。
よりによって帰りのバスの途中で、バスの屋根に打ち付ける雨の音。 ああああ。 途中道路に深い水たまりができていて、バスが中央線よりを減速しながら通過するほど。
バス停についてからしばらく (10 分くらい?) 雨宿り。 やむ気配は全くなかったが、すこ〜し勢いが収まったかなというところを見計らって帰った。
どうやら隣の市あたりまでの範囲に集中した豪雨だったようだが、ここのところ雨が続いているし、今日も朝晴れてたくらいでその後は雨が降ったりやんだりを繰り返していたような状況だから、さすがに心配になるレベル。
まさかのメルセデストラブルに驚いた。 最後の 20 周ほどは見所満載であった。 何戦か前のチームメート同士の争いもおもしろかったけど、今回はいろんなチームが混ざってかなりおもしろかった。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU