【HTML5】canvasを使ってNormal Mappingもどき

久しぶりの更新です。
最近はJavaScriptにどっぷりはまっています。
jQueryがすごすぎです。

今回はHTML5のcanvasでこんなこともできるというデモです。
オリジナルのスクリプトを改造して、動作を高速化しました。

普通の画像にノーマルマップを使って、リアルタイムに陰影計算を行っています。

オリジナルのスクリプトはこちら -> Normal Mapping with Javascript and Canvas - 29a.ch
おかりしましたモデル -> キオ式アニキャラ3D act.3

下の画像クリックで対象のページにジャンプします。




※注意：このデモを動作させるためには、HTML5をサポートしたブラウザが必要になります。
Safari、Chrome、Firefox以外のブラウザでの動作は確認できていません。

【python】同じサイズの画像の色を合成して出力するプログラム

研究で必要になったので、3分間クッキング。
Illustratorでやる方法が分かりませんでした。

以下ソース
-------------------

#color.py

import sys, pygame

_gSrc = None

tex1 = sys.argv[1]
tex2 = sys.argv[2]
save_name = sys.argv[3]

pygame.init()
pygame.display.set_mode((150, 150), 0, 32)
_gScr = pygame.display.get_surface()
tBuf1 = pygame.image.load(tex1).convert()
tBuf2 = pygame.image.load(tex2).convert()

w, h = tBuf1.get_size()
pygame.display.set_mode((w, h), 0, 32)

for j in range(h):
	for i in range(w):
		color1 = tBuf1.get_at((i, j))
		color2 = tBuf2.get_at((i, j))
		# RGB to GRB
		tBuf1.set_at((i, j), (
		(color1[0] + color2[0]) / 2,
		(color1[1] + color2[1]) / 2,
		(color1[2] + color2[2]) / 2,
		255))

_gScr.blit(tBuf1, (0, 0), tBuf1.get_rect())
pygame.image.save(_gScr, save_name)
print "finished"

while True:
	_gScr.blit(tBuf1, (0, 0), tBuf1.get_rect())
	pygame.display.update()
	pygame.time.wait(10)

-----------------------------------
コマンドプロンプト
$:python color.py [入力画像1] [入力画像2] [出力画像]

-----------------------------------

参考サイト
http://www5f.biglobe.ne.jp/~kenmo/program/graphics/pygame/pygame.html

途中経過 > iPod touchでVRを再現する

さて、iPhone / iPod touchアプリの勉強中ですが、難航しています。チュートリアルでXcodeとInterface Builderはわかってきましたが、Objective-Cに癖がありまして、なかなか進みません。
ほかにもやることがあるので、残念ですがしばらく手を付けられません。時間切れです。

とりあえずやりたいことをネタにしておきます。
--------------------------------------------

iPod touchにはカメラがなく、ARToolKitなどを使って直接VRを楽しむことができません。ならばどうやってVRを作るか、というのはJohnny Chung LeeのWiiリモコンを使ったVRシステムにヒントがありました。

Johnny Chung Lee > Projects > Wii

このプロジェクトではWiiリモコン（つまりIRカメラ）と赤外線LEDを使ったもので、ARToolKitと同じような手法で実現をしています。ARToolKitと大きく違うのは、視点にマーカーを使っている点です、Wiiリモコンはディスプレイまたはコンピュータに固定されています。逆にARToolKitでは視点はWiiリモコンにあたります。
今回想定しているプログラムは以下の図で表せます。


簡単に説明すると、マーカーの位置と傾きをカメラの視点座標とし、カメラの位置を物体の座標としてVRを行うシステムです。

プロセスは、マーカーをiPod touchの裏に張り付け、その映像をカメラで撮影、映像をARToolKitを使って、マーカーの座標を検出します。そのマーカーの座標をiPhone / iPod touchプログラムに送信し、マーカー位置を視点座標とし、視点座標からカメラの位置である原点座標が物体位置にします。これによってVRが可能になります。

利点はARToolKitの処理がすべてサーバー側の処理になり、モバイル機側での処理を減らせます。特にARToolKitの処理であるストリーム処理、画像処理などの膨大な計算処理が省けるので、恩恵はかなり大きくなります。

欠点はカメラの視点外になるとマーカーが検出されず、映像が出力されないのと、ARToolKitのように周辺画像を取り込めないことにあります。

中途経過として、マーカーの座標を送信するプログラムのひな形はできましたが、レガシーなCのコードで書かれているため、iPhone / iPod touchのアプリケーションでは実装が難しく、代わりの方法に関してのコード記述で停滞しています。
一応そのひな形のプログラムのスクリーンショットは以下の図です。手前のテキストベースのアプリケーションがクライアント、後ろのARToolKitを使ったアプリケーションがサーバーになります。クライアントがマーカー座標をサーバーに要求し、要求を受け付けたサーバーが座標データをクライアントに送信、最後にクライアントは受信した座標を表示するプログラムです。数字は４行４列の行列になります。acceptのスペルミスがありますが…


とりあえず今回はここまでです、また来年お会いしましょう。登校時間から数時間後ですが…

[iアプリ]標準クラスを使わずに３次元表示その２

少し間が空きました。
相変わらず３ＤＣＧ表示するための元のソースを解析しています。

今回の一番のボトルネックは頂点の変換と、ポリゴンのラスタ化にあります。特にラスタ化をするためのステップが多いのが問題です。Javaの配列へのランダムアクセスの速度が分からないので、今のところあまり手が付けられませんが、解決したいところです。

詰められる部分は詰めたいのですが、スキンメッシュアニメーションをさせる時に頂点ごとにボーンウェイトを埋め込まないといけないので、大規模な変更はかえって面倒になりかねないので、実用段階までにはこぎつけたいところです。

とりあず現状はここまでです。

[iアプリ](MascotCapsuleなどの)標準クラスを使わずに３次元表示

前のログのようにiアプリでの3DCGはMascotCapsuleに則ったファイルを読み込まないとモデルの表示が出来ません。
MascotCapsuleのファイルを出力するソフトがほとんど高額なソフトであるのと、それ自体を使うのが癪に障るので、何とか自力でデータの読み込みをすることが出来ないかを考えていました。そこですべてJava上で計算して表示させることが可能であるか、色々と調べていました。
Java上ですべて計算表示するため、今回は以下のサイトのソースを利用させていただきました。（JAVAde3Dのテクスチャマッピングの項のソースより）
OPEN PROGRAMING

主要部分はほぼコピペですが、awtのパッケージの関数を使っている部分は変える必要があったので、iアプリのパッケージで代用する変更を加えました。もう一つGUI部分がアプレットを使ったものだったので、これもiアプリ準拠のGUIを使うように変更しました。

とりあえず動くのは動きましたが、やっぱり遅いです。更新間隔を300msほど置かないとうまく表示されないので、実用的ではありません。
クロックの問題もあると思いますが、やはり問題になってくるのはfloat(浮動小数点数)の演算になってきます。あとはレンダリングアルゴリズムでしょうか。

まだまだ解決するべき点は多いですが、一応可能であることは分かりました。

---

2008/3/6/1:42 画像を修正

本が届きました

アマゾンで注文しようと思ったらすでに在庫が切れてて、紀伊国屋でまだあったことに気づいたので今回は紀伊国屋のネット通販を利用して購入しました。

ただし下のリンクはアマゾンです
Amazon.co.jp： Java仮想マシン仕様 (The Java series): 本: ティム リンドホルム,フランク イェリン,Tim Lindholm,Frank Yellin,村上 雅章

この本のすごいところは、javacがソースから仮想マシンで実行されるバイトコードをどのように記述しているかを解説しています。その他にも命令セットのニーモニックとオペコードの表記を一つずつ解説していてかなり詳細にVMの仕様を書いています。
この本はVMを自分で作る人だけでなく、Javaでコードの最適化を行おうとしている人にも向いていると思います。（例としてC言語で言えば逆コンパイルして、ニーモニックに変換したコードとにらめっこする時に役に立つと思います。）

まだ詳しくは調べていませんが、大抵の場合JavaはバイトコードをJITコンパイラでネイティブコードに直せる部分では速度低下はあまり見られませんが、インタプリタで実行される部分も発生するため処理速度が落ちるようです。つまりなるべくネイティブコードで実行されれば(C言語と比べて）速度の低下を防ぐことができるみたいです。
速度向上に繋がる部分はまだ押さえていませんが、練れる場所はまだありそうです。

JAVA依然勉強中

本屋で見つけたのですが、SunのJAVAのVM仕様というのものが本になっているようです。詳しいタイトルは忘れましたが、Sunから出している本というのは本数が少ないと思うので、すぐに見つけられると思います。

実際見て思ったのは、バイトコードレベルになるとやはりアセンブリ言語に近い感覚で扱われるみたいです。Javaのコンパイル時にニーモニックにして出力ができるみたいなので、これでJavaのソースコードの書き方によって処理効率の比較ができそうです。

とりあえず、本を買ってC++のように最適化が行えるかどうか試してみます。

最近気づいたC++のコード

C言語とC++言語は親和性が高いんですが、それゆえにC++の特有の機能というのが曖昧なところが結構あります。
streamクラス関連のcoutなんかはstring型を使わなければ、stdioのprintfのほうが扱いやすいですし、抽象度が高いクラスはデータの流れが分かりづらいせいでデバッグがめんどくさいのでなかなか使うのには面倒な点があります。

そして勉強不足なのか、最近になってC++には参照型変数というのものがあることが分かりました。
記述は

型指定子＆　参照型変数名
例(int& val)

という風な感じでかかれます。
これの効果は関数にポインタを使わずに参照させることが出来ます。
基本的に関数の引数や返り値に値渡しを使うとオーバーヘッドが増えてしまいます。オーバーヘッドを増やさないためにはポインタを使ってやり取りする必要がありますが、ポインタを使った場合だと参照させたいだけの場合では、内容が書き換えられる可能性があります。

int* getInt(int* val) {
*val++; //内容が変更される。
return val;
}

ポインタの場合、constを付けても無意味なので(constは型のデータを定数にするので、ポインタ型の場合はアドレスが定数化されるだけでデータの定数化まではできない）一見すると変更させない参照は用意できないように思えます。
そこで参照型変数の登場です。

int& getInt(const int& val) {
val++; //警告、またはエラーになる
return val;
}

このようにすることで、valは参照させるだけで、関数内で変更することができないように指定が出来ます。またconstをはずすとvalは関数内で変更可能になります。基本的にC++の参照型変数はconstをセットにして扱われるパターンが多いと思います。
上の例だとintでポインタのサイズと変わりませんが、これがデータが大きい構造体の場合などでは値渡しと参照渡しではかなり変わってきます。

C++の良い点はC言語のコードが流用できる点が良いですが、C言語のコードとC++のコードが混在するとコード管理の問題も出てきますから、一概に良いとも言い切れないのが問題ですね。

---

訂正(2/7)：
ポインタ型でもconstを付けることで内容が変更されないようにできるそうです。

int* getInt(const int* val) {
*val = 10; //エラー
return val;
}

constは (const 型)でも(型 const)でも同じ効果を持ちますが、ポインタ型の場合は、(const int* もしくは int const *)はアドレス先の値を定数化し、ポインタ型 constの場合(int* const)はアドレスを定数化するみたいです。

思いっきり間違ってました。指摘ありがとうございました。

作るべきか、使うべきか

また間が空いてしまいました。反省反省…

ちょっと前にC++で.NetのXmlTextReaderと同じような機能を持つネイティブ版のものを作ったんですが、デバッグの作業がとてもしんどいことになりました。
テンプレートがまともに使えていればまだ楽だったのかもしれませんが、テンプレートを使うと原因が追えずにソース内をたらい回しにされると言う最悪な状態ができるので、よほど自信がなければテンプレートは使えませんね。

で、今回のネタは、制限のある環境の便利なライブラリを使うか、開けた環境で自作のライブラリを作るかという話です。

「使う場合」はバグが含まれていない限りは何の問題もなく使えますが、環境に制限があったり、使い勝手に不満が出たりすることもあります。
対して「作る場合」は作ったものにバグ取りなどの責任がでてきますが、自分で作るんだから環境に制限は無く、使い勝手も自分で変更できます。

業務用のソフトでは安全性が第一でしょうが、趣味でやる場合はどうなんでしょうかねぇ…
シビアなクロック稼ぎはニーモニックを見ながらチューニングする羽目になるんで、やることは分かりやすいですがハッキリ行って辛いです。

実行速度に依存しない場合は安全を取るか、それとも速度または使い勝手を求めるかの葛藤するときは…

同期型/非同期型コミュニティの進化（ニコニコ動画について）

1さて、今日のネタはコミュニティについて考えてみることにします。

---

コミュニティの種類は２種類に分かれていて、同期型コミュニティ（ＩＲＣやＷｅｂのチャットルームなど）と非同期型コミュニティ（ＢＢＳ、Forum系サイトなど）に分類することができます。

・同期型コミュニティ：
他の参加者とリアルタイムに意見を交わすことができますが、参加していない場合、意見を取り交わすことができ ません。メッセージログを読むことはできると思いますが、相手のメッセージに対して返信のメッセージを通知する方法が無いからです。

・非同期型コミュニティ：
コミュニティに参加した（メッセージを送信した）時のメッセージログとそのログに対しての返信機能がついています。これによって参加した時刻が相手と異なっていても通知することが可能になっています。

---

さて、上記はいわゆる一般的なコミュニティの形式が取っている方法ですが、同期/非同期の最大の違いはリアルタイムに意見のやり取りができるかどうかとい う点にあります。

ニコニコ動画の場合、感覚的には映画館や友達と一緒にテレビを見て笑ったり、独り言をこぼしているのをメッセージとして投稿すると いった形式でコミュニティの形式としています。 つまり限定された時間空間を共有できる点が他のコミュニティと大きく異なります。 ただしこれは投稿者の動画を対象としてコメントしているため、通常のコミュニティと違って不特定多数の人と意見を交わすことを前提として作られていないの で、応用が利かない点があります。

 しかしながら新しいコミュニティの形態を提供したのは間違いなく、今後新しいコミュニティの形態としてこのシステムが応用される可能性は十分に含まれてい ます。
もしも同じ時間に参加しなくてもチャットと同じ感覚でメッセージのやり取りができるようになったらインターネットの可能性がさらに広がりそうですね。