独り言日記
2003/07/31 update.

真夏日
更新日時 2003/07/31
内容 いきなり暑くなりましたね。ようやく梅雨も終わったって感じでしょうか(<東京)。
で、夏恒例のランニングを本格的に再開しました。
思いっきり汗をかいて、帰ってから風呂入る、で涼しいひとときを満喫中です。
こうすると作業もはかどるんです(ちなみにクーラーなどの文明の利器には頼りません(笑)。扇風機も無しでウチワのみ)。 電気代も大幅節約です(これが一番の目的です)。
これで、いざ電気の供給がストップしても狂い死ぬこともないでしょう(^_^;;。 でも、PCが動かないと仕事もできなくなりますわね。
でも、現代人、一度はそんな電気無し生活を体験したら、新たな発見があるかもしれませんね。
Redqueen Rendering Tool
更新日時 2003/07/30
内容 Redqueenで実際どれくらいのレンダリング速度がでるのだろう、と試してみました。
「速いよ」ってのは事前にいろいろな方から聞いてはいたのですけどね。

こんな感じ
これで、4x4のオーバーサンプリング(拡散反射サンプル数 12・拡散反射回数 5)で3分くらいです。 (Athlon 1100MHz/Mem512MB Windows 2000 環境にて)

・・・確かに速いじゃないすか。一度、直接光で止めてレイトレと同じ状態でレンダリングしてみて、 実際の自分で作ったレンダラと速度差を比べてみたのですが、大差はありませんでした。
でも、セレクティブレイトレースのような技を使わずにですから、私のレイトレレンダラよりも速いことになりますね。
つまりは、カリカリに調整しまくってるってことですね・・・むむ、すばらしいです。
GIレンダラを作ろうかとも思ったのですが、もうRedqueenで満足です(はやくも、GIレンダラを作ろうの気分は崩壊(笑))。
国産のGIレンダラですので、ご興味のある方はぜひ。

Redqueen(大垣さん)のサイト>http://www.teamredqueen.com/index.html

賞味期限
更新日時 2003/07/29
内容 賞味期限が4ヶ月以上過ぎた「ふりかけ」を、 もったいないのでゴハンにふりかけて食べてみました。
問題なかったです。風味もほのかに感じ取れます(^_^;;
ちなみに賞味期限が切れた「味付きノリ」は、パリパリ感がなく、しめってる感じでした。
さすがに加工品以外は賞味期限切れでも試さないですが・・・ 数年保管が可能な食材があればいいのですが、自炊派には賞味期限の壁はつらいですねぇ。

どうでもいいですが、勉強のために無性にGIレンダラー作りたくなってきました。
ま、仕事が忙しくなったときの、いつもの「逃げ」なんですけど(T_T)
「学生時代に勉強しとけばよかった」ってのが口癖になってしまいそうですが、 マジで勉強しておいたほうがいいですよ(^_^;;。 時間がいくらでもほしい今日このごろです。
そう考えると、コンピュータ業界は特に、情報格差が大きいでしょうね。
モデラー途中経過
更新日時 2003/07/20
内容 すいぶんとそれらしくなってきました(ダミーが多いんですけど(^_^;;)。


編集画面部分は、ソフトウェアレンダリングなのですが、 オブジェクト数 45・ポリゴン総数 19215・頂点総数 10154で、 スムースシェーディング+ワイヤーフレーム描画を行うのに 約230msです(640*480ピクセル分)。
C言語でカリカリにした場合と比べて(Javaなのに)速度差はほぼ0になってます。
仕組みとしてはちょっと凝ったことをしていて、Java側とC言語側で「クライアント・サーバー」の関係になってます(X Windowの仕組みのような感じを想像すればいいかと)。
Java側はユーザーインターフェース・操作の管理、C言語側は描画データ管理とベクトル・行列・3D計算処理やレンダリングを行っています。
画面への3D描画は、C言語側に「描画する」の1命令を送るだけで、後は何のやりとりをする必要もなくC言語側で(メモリ上に)レンダリングします。 これをJavaのImageに画像として転送します。
すべてのデータとレンダリングエンジンをC言語側に持たせるのがミソです。
これで、Javaのネックである速度の問題とメモリの食い過ぎ問題はほぼ解決します(たぶん)。
・・・とそう考えると、実はSWTのプラグインとしてOpenGLのモジュールがあるのですが(WinとLinuxのみ)、 これはちょっと効率悪いですね。
専用のリアルタイムレンダリングエンジンを作成して、 Javaではあくまでも描画や操作などのトリガーを与えるだけにし、データはC言語側で持たせたほうがいいように思います。
もちろん、ハードウェアレンダラも実装するつもりにしてます。<現3DCGツール
SWTのImage高速化に向けて
更新日時 2003/07/17
内容 JavaのSWTのImageでの描画速度を計測してみました。
以下のように、10000回のライン描画を行います。


int i,x1,y1,x2,y2;
int rr,gg,bb;
Random rand = new Random();

//256*256ピクセルの画像を作成
Image img = new Image(null,256,256);

GC gc = new GC(img);
gc.setForeground(new Color(null,255,255,255));
gc.fillRectangle(0,0,256,256);

for(i=0;i<10000;i++){
  x1 = rand.nextInt() & 255;
  y1 = rand.nextInt() & 255;
  x2 = rand.nextInt() & 255;
  y2 = rand.nextInt() & 255;
			
  rr = rand.nextInt() & 255;
  gg = rand.nextInt() & 255;
  bb = rand.nextInt() & 255;
			
  gc.setForeground(new Color(null,rr,gg,bb));
  gc.drawLine(x1,y1,x2,y2);
}
gc.dispose();


これで、160msかかってます。
ループ内の「new Color」がボトルネックになっているため、コレを除くと70msかかります。
でも、遅いですね。

で、「S3D」というオリジナルのクラスを作り、 これを使用して同じように描画してみました。

int i,x1,y1,x2,y2;
int rr,gg,bb;
Random rand = new Random();

//256*256ピクセルの画像を作成
Image img = new Image(null,256,256);

//オフスクリーンを作成
int num = S3D.createOffscreen(256,256);
S3D.clear(num,255,255,255);

GC gc = new GC(img);

for(i=0;i<10000;i++){
  x1 = rand.nextInt() & 255;
  y1 = rand.nextInt() & 255;
  x2 = rand.nextInt() & 255;
  y2 = rand.nextInt() & 255;
			
  rr = rand.nextInt() & 255;
  gg = rand.nextInt() & 255;
  bb = rand.nextInt() & 255;
			

  S3D.setForeground(num,rr,gg,bb);
  S3D.drawLine(num,x1,y1,x2,y2);
}

//オフスクリーンの画像をImageに転送
S3D.BitBlt(gc.handle,0 , 0,0, 256,256, 0,0);

gc.dispose();


独自で作ったオフスクリーンに描画して、最終的にImageに画像転送(BitBlt)します。 これで、なんと50msです。普通にSWTを使った描画に対し、3.2倍の高速化が実現してます。
一度画像転送処理が間に入っているにもかかわらず、大幅に速度アップです。
これは、「S3D」というクラスを経由してC言語の関数を呼び出している、 というカラクリになってます(JNI経由でDIBSectionに描画)。
と、なんだかんだで SWTはこのへんのカスタマイズが甘い、ってのが如実に出ている気が(^_^;;
速い、と言われるSWTでもまだまだ高速化はできそうですね。
もちろん、この高速化は、今作っている3Dツールでも使ってます。
このようにC言語との連携で劇的に高速化できるのですが、 「クライアントサイドJavaは遅い」という一般の偏見が一番の問題ですねぇ。 なんとか、その事実を崩してみたいものです。 盛り上がれ、クライアントJavaアプリ。
SWTのImage
更新日時 2003/07/16
内容 SWTにて画像を扱う「Image」ですが、ここにダイレクトに描画を行って(描画開始ポインタを取得してメモリを直接いじる感じ) 描画速度を高速化をしよう、とたくらんでみました。
たしかに、以下でメモリに描画して反映はできるのですが・・・

//RGBの24ビットで1ピクセルのフォーマットにおいて、
//128*128ピクセルの画像データを作成
ImageData iDat = new ImageData(128,128,24,
  new PaletteData(0xff0000,0x00ff00,0x0000ff));
byte [] dataPos;
int pos,px,py;

//以下は、128*128ピクセルを赤色で塗る指定
pos = 0;
dataPos = iDat.data;
for(py=0;py<128;py++){
  for(px=0;px<128;px++){
    dataPos[pos] = (byte)255;  //Red
    dataPos[pos+1] = (byte)0;  //Green
    dataPos[pos+2] = (byte)0;  //Blue
    pos+=3;
  }
}

//イメージを作成
Image img = new Image(null,iDat);


1ピクセルでも変更が行われた段階で「new Image(null,iDat)」が必要なため、 ここがネックになってしまってます。
(640*480ピクセルの画像にて、200ms-300msほどロスします)
これは、内部的にピクセルフォーマット変換が行われているからだと思われます。 その証拠に、ImageDataのフォーマットをスクリーンのと同じにする(Imageをカラで作成して、getImageData()でImageDataを取得)と1.5倍ほど速度アップします。
でも、やはり遅い・・・。ピクセル操作部の2重ループよりも、このImage作成部でほとんどの時間を食っています。
なので、C言語(JNI)で画像を扱って(DIBSectionなどで)そこで元データを管理し、最終的にImageのデバイスに BitBltしてやろうかと。

Imageへの描画は、Java内ではGCを取得して行いますが、

GC gc = new GC(img);
gc.setForegroundColor(new Color(null,255,0,0));
gc.drawLine(0,0,64,64);
int handle = gc.handle;
...
gc.dispose();


このときの「handle」が、実はWindowsで言う「HDC(デバイスコンテキストのハンドル)」に 相当しますので、これを使うとC言語に処理を引き渡せそうです(このgc.handleは、 各OSに沿った描画ハンドルになります)。
SWTでは、Imageは(内部では)DIBSectionで管理してほしかったなぁ、と思いますね。 メモリへのポインタも返せるようにすると、高速化に拍車がかかったのですけど。
まぁ、C言語との連携はしやすいですのでいいです。
と思って、C言語部をいじっていると、せっかく作ったソースファイルがいきなり消えてしまった・・・。 VisualStudioのバカヤロ〜(T_T)
モデラー部作成中
更新日時 2003/07/16
内容 只今鋭利制作中、で初のスクリーンショット公開です(まだまだスカスカですけど)。


完成時期は今のところまったくの未定です。仕事の合間にしつつ、今年中に完成すればいいなぁと思ってます。
「Javaでこんなことまでできる」ってのを目指しています。
仕様は全部固まってますので、後は前進のみです。ゲーム用のモデラー&ムービー作成ツールができればいいなぁと。
やっぱり、昔っから「ゲーム作りたい欲」が原動力ですね(^_^;;<ワタシ
まあいいや、自分に正直に好きなものを作ろうっと。
モデラー部作成中
更新日時 2003/07/14
内容 ちょっと時間ができたため、3DCGのモデラー部を本腰入れて作成中です。
開発言語として、Java+SWTを使ってます。即マルチプラットフォーム対応できる、というのがねらいです。
3DCGツールとしては、モデラー部とシーン構築部(&アニメーション部)は分ける予定(LightWave3Dみたいな構成かな)。 いろいろ構成を考えたのですが、モデリングとシーン構築が分離していたほうがシステムとしてすっきりするような感じがしましたので・・。
Javaを使う場合は、リアルタイムレンダラの処理(OpenGLを使う、もしくはソフトウェアレンダラ)が重くなるかもしれないですね。 ただし、ポリゴン数が少ない場合(計算や描画処理が少ない場合)は、あまり速度低下は感じられませんでした。 描画処理部分は、C言語のリアルタイムレンダラモジュールを呼び出したほうがいいかも(これは自作しないと)。
また形がそれらしくなってきた段階で、開発途中のスクリーンショットでも出していこうと思っています。
ひさびさに敵襲来
更新日時 2003/07/09
内容 本日、新聞勧誘が来ました。
「近くに店を建てることになったので粗品配ってま〜す」などと行って来たので、 「ほな、粗品いただきます。」と言いつつ粗品を手に持って話を聞いていると、 新聞の勧誘の話になってきました。
内心「なんや、ただの新聞の勧誘か」と思ったのですが、口に出さずに 私の考えている新聞の方針について話をして(うちでは別の新聞をすでに購入済みっす) 「すみませ〜〜ん、また店出来たらきますね。」とさわやかに返してやりましたよ!! (粗品はもちろんお返ししました)
我ながら誰も傷つけないスマートな返し方だと思いました(笑)。あっさり引き下がっていきましたし。
それにしても、ステルス的勧誘すね(笑)こんな手口もあったんすねぇ。
なんにせよ、話術は大事だと実感しました。
数年前に、某宗教(?)にも勧誘されたんですけど(某所で意気投合した人につれられて、 なのですが。親切な人でも、やっぱり距離を置くべきですね(親切な人には弱い私(^_^;;)) 現地(総本山とでも言うか)まで行ったことがあります。現地に行くまで、何の話かも聞かされずに そのままついていった私にも落ち度はあるのですけどね(^_^;;。
数人(信者の方)と飯を食べながら、こちらの宗教観・信念とかをとうとうを語って、うち負かしてきました。 こちらで説教(しかる、って意味ではないですよ)してきたって感じです。 相手も「いい話が聞けました。」とか喜んでたし。いいのかな(^_^;;?
このときは、タダ飯を頂けてラッキーだったです(笑)。このへんの精神論的な深い話は、 分かる人しかついてこれないでしょうから、いい相手になったって感じでよかったですけどね。 (私自身は無宗教ですが、うちの家系的にはいろいろ入り乱れていたり、父親が研究家たっだりしたので詳しいんです)
この手の勧誘の場合は、相手が悪い気をぜんぜん持っていなく、むしろ善意で話しますので 「悪い人かイイ人か」っていう判断は難しいっすね。むしろイイ人なのですが、自分の立ち位置が 第三者の視点で見えていないって感じです。
話を聞くと、微妙に矛盾点があるんですよね(それは「考え方の違い」といったレベルではあったりするのですけど)。

なんにせよ、「話術」は大事です(仕事上でも、話ができると有利ですしね)。 慣れの面も多いかと思いますが、何事に対しても信念を持ってると強いかと思いますよ。
オリジナル3DCGツール進行状況
更新日時 2003/07/09
内容 途中で中断していたプログラム開発を再開しようとしても なかなか進まないですね(^_^;;。
3Dツール作成のために、GUIライブラリである「C-Parts」を作っては中断しての繰り返しなのですが、 集中して開発できる時間がまとめてとれないと全然です(T_T)。
やはり、GUI部分は既存のに頼ろうか・・・
ですが、「マルチプラットフォーム」というのを大前提にしてますので選択肢に悩みます。 かといって、これは完全に趣味プログラムですので仕事の合間に着手、なんすね。
効率を考えるとJava+SWTが楽かなぁ、ということでそれで進めようかと。 レンダラ部は、Javaでレンダラを作ると遅いため、Cで作成したレンダラをJNIで呼び出す形で。
SWTを使った場合は、Mac OS Xで速度的にダメダメなのですが、 後々SWT側で改善してくれるであろうことを願ってそのまま進めます。
(Apple関連は、このあたりにツッコミを入れてくれるデベロッパがいれば、進むんでしょうけどね。 何かズレを感じます。独自路線を突っ走ってる、と言えばそれまでなんですが(^_^;;)
GUIライブラリとか開発言語とか、選択肢はいろいろあるのですが、どれも一丁両端すねぇ。
C/C++は速度的にサイコーなのですが、OS間の差異の穴埋めが大変(イベント部・GUI部)、
Javaはマルチプラットフォームかつライブラリがそろっていて開発効率はいいのですが、 速度的にはまだちょっと遅い(C言語に比べて2〜5倍ほど)、
速度が速くてマルチプラットフォーム・豊富なライブラリがそろっている言語があれば最高なのですが(笑)。
今のところ、キメラ式にいろんな言語・ライブラリでアプリケーションを構築する、が妥協案すね。
Javaでのレンダラは遅い?
更新日時 2003/07/06
内容 以下の「WinOSi」のギャラリーを見ると、Javaのレンダラ「JaTrac」との比較があるのですが、

「WinOSi」のギャラリー
http://www.winosi.onlinehome.de/Gallery.htm

「WinOSi」といろいろ比較
http://www.winosi.onlinehome.de/Comp1.htm

このJavaレンダラ「JaTrac」が圧倒的に「遅い」ように見えます(他の10倍くらい)。
C言語とJavaとの速度差は現状ではかなり縮まっているはず、 というのを考慮しても遅すぎ・・・。 ってことで、「そんなに速度差が開くものなのか?」という疑問が出たため、 簡単に、C言語とJavaのレイトレーサーのプログラムを作ってテストをしてみました。
640*480ドットのレンダリング領域にて、球1個を配置してレンダリングしてます (Athlon1100MHz/Mem512MBで、OSはWindows 2000)。



純粋に計算時間のみを(描画は考えない)取り出して計測したところ、
C言語(VC++使用)では、96ms
Java(J2SE 1.4.2)では、250ms
という結果になりました。約2.6倍差です。
複雑化した場合(ネストや関数呼び出しが深くなった場合)、 もしかしたら10倍くらいの差が出るかもしれないですね。
速度重視の処理では、まだJavaは向かないなぁ、というのを再認識してしまいました。
ほんとは、「JavaとC言語って速度的にも大差ないや〜〜ん」というのを検証しようと思ってテストってみたのですが、 返り討ちあってしまいました(^_^;;。
でも、Javaでは中間言語を吐き出し、それを解釈するにもかかわらずこの速度、 というのは速いんですけど。 やっぱりネイティブには勝てないってことっすね。
言語としての使いやすさ・安定性・メンテのしやすさなどはJavaの勝ちのような気がするのですが、 速度を考えるとやはりC言語が勝ちです。どっちを取るか、ですねぇ。
Curl
更新日時 2003/07/06
内容 友達から教えてもらって初めて知ったのですが、「Curl」という言語があるということで調べてみました。
JavaのようなVMを持つ言語環境で、Webブラウザでの閲覧速度を高速化するのを狙っているようです。
Webブラウザのプラグイン(「Surge」という名称です)として動作します。

http://www.curlap.com/html/

今までのブラウザのプラグインと違って、「HTML+CSS+埋め込みプラグイン」をCurlで表現している、という感じになります。
ある意味ブラウザの「乗っ取り」といった感じかな。なので、「閲覧は従来よりも10倍速い」そうで。
JavaAppletでもFlashでも「埋め込み」なので、この差は大きいように感じます。
開発言語としてはLISP風です。
このサイトのDEMOを見ていただければ分かりますが、グラフィックに非常に強そうですね。
フィルタでのぼかしやらリアルタイムレイトレーシングしてますし。
JavaAppletの開発されたことがある方は身に染みているかと思いますが、ブラウザ上でのJavaAppletは 速度的にかなり遅くて正直使い物にならないくらいです(JavaApplicationなら問題ないのですけどね)。
Curlの場合は、もともと速度重視ですのでストレスはないです、これなら業務でも使えそうです。
一番突出すべきなのは、「開発時間を短縮できる」でしょうか。
「システム構築に300人月かかるところを、Curlを使ったことで300時間で済んだ」とかうたってますねぇ。
言語として簡単な構造なのかもしれません。
いかに開発効率がいいと言われるJavaといえど、より簡単なスクリプト(LISP)風の言語のほうが効率がいい(もしくは理解しやすい)、ということかもしれないですね。

http://www.hotwired.co.jp/news/news/technology/story/20011207301.html

動作OSとしては、WindowsのみのようですがMacOSXやLinuxでの開発も進んでいるとのことです。
勉強してみようかなぁ。