トップ差分一覧ソース検索ヘルプ PDF RSS ログイン

独り言日記（2009/04）

SunといえばJavaなんですが、Javaはよくできた言語だと思ってます。Flex（FlashのActionScript）もかなりJavaをインスパイヤしてるのがありありと分かりますし、開発効率がよかったのでシステム開発ではもうスタンダードになってます。C#は打倒Javaだったしね。昔はJavaが扱えたらもてはやされてたのですが、今はプログラマであれば誰でも使えますからねぇ。使えたとしても、あんまりちやほやされなくなってしまってますかね(^_^;;。

私はJava1.0.2の頃に仕事で（後、趣味でも）使ってたのですが、当時はこんな流行るとは思ってませんでした。が、完成度の高さはその段階ですでに垣間見れたんですよ。でも、今後Javaはどうなるんでしょうね？Oracleとは昔からツーカーだったと記憶してますので、なんとかDBと一緒に生きていくのかな。

個人的にシステム系は、COBOL→Javaの大きな流れがあり、その先はまだない、といった印象があります。ガシガシプログラムする系のプログラマは、できるだけネイティブにあこがれるのでスクリプト言語は選択肢にはなかったりします(^_^;;。でも、これは大きな流れの変化ですねぇ。ついにSunが窮地に追い込まれたかぁというのが感慨深いです。SunはサーバとしてSolarisも扱ってたのですが（私もプログラムしたことありますが）、これも時代とともに時代遅れになっていったのも感慨深いところ。

そういや、少し前にSGI（シリコングラフィックス）も逝っちゃいましたね、何回も浮き沈みしてましたけど。

そんなのを見ると、平家物語の無常観（盛者必衰）をいつも思い出してしまいます。

V-Pianoを触ってきた（2009/04/19）

某楽器屋にてV-Pianoを触ってきました。キータッチとしての硬さはなかったです、普通のシンセと変わんないかなぁ。音はたしかによい感じではありました。Rolandのサイトのムービーでも分かりますが、低音がきれい。しかし、燦然と輝く60万円の文字。ほかの周りにあったシンセや電子ピアノは高くても20万円くらいでしたよ(^_^;;。

しかし、電子ピアノのキータッチとしてはもうちょっと硬いのが個人的には好み。なので店頭にあったのを片っ端から確認してみたのですが、いずれもキータッチで押し心地が弱いなと。で、検索してみると最近の電子ピアノはキータッチの硬さ調整もできるとのことが書いてますね。ということは店頭のはわざと軽くしてるのかな。

私自身はMIDI打ち込み用の安いRolandのキーボードを持ってるのですが、キータッチの硬さ調整はできません。ということは、電子ピアノとキーボード（シンセ）では硬さの調整できる・できないに違いがあるのかもしれない。

V-Pianoのマニュアルを見ると（Rolandのサイトからダウンロードしてみることができます）、キータッチの項目はたしかにあるのですがこれって鳴り方の調整なのだろうか、それとも抵抗としての調整なのだろうか。後者ができればよいのですが、、、。

いずれにせよ、再度知識を蓄えて店員さんに聞くほうがいいかもしれませんね。でも、高いから買いません（買えません）けど（汗）。

V-Piano（2009/04/15）

これすげ～！！電子ピアノなんですが、サンプリングでなくてピアノの物理的な動きをシミュレートしてるみたいです。

http://www.roland.co.jp/products/V-Piano/

硬さも再現してるのかな、ほしいなぁと思って価格調べると60万円。手がでないですねぇ(^_^;;。でも、それだけの価値はありそう。YouTubeなりニコニコで演奏動画を調べてみました。ニコニコはなかったです、Rolandのサイトにあったもの以外は。YouTubeにはちらほら出てますね。

これは商談会のムービー。説明もわかりやすいです。

http://www.youtube.com/watch?v=nmwO9qGhJUU

以下は開発者のインタビュー記事。

http://av.watch.impress.co.jp/docs/series/dal/20090330_80168.html

これを読むと「物理モデリング」という単語が出てきてますねぇ、レンダリングという単語もあってCGに近い表現が興味深いです。ようは、3DCGで言う「GIレンダラ」を目指してみました、というピアノなのかもしれないですね。

続続続・Flex3でのピクセルシェーダー（2009/04/11）

はやくも難問にぶちあたりました。やりたいことは、Flex3にて三角形ごとの描画をシェーダー化して「Graphics.drawTriangles」の代わりに光源と法線によるシェーディング（とりあえずは頂点カラー対応）を行いたい、です。

また後でソースをアップしますが、メモとして。「Shader」クラスを作成して

// スクリーン上の頂点座標値
m_shader.data.scrPos1.value = [頂点0のX, 頂点0のY];
m_shader.data.scrPos2.value = [頂点1のX, 頂点1のY];
m_shader.data.scrPos3.value = [頂点2のX, 頂点2のY];
  
// UVT値
m_shader.data.uvt1.value = [頂点0のU, 頂点0のV, 頂点0のT];
m_shader.data.uvt2.value = [頂点1のU, 頂点1のV, 頂点1のT];
m_shader.data.uvt3.value = [頂点2のU, 頂点2のV, 頂点2のT];

// 頂点カラー
m_shader.data.vColor1.value = [頂点0のRed値, 頂点0のGreen値, 頂点0のBlue値];
m_shader.data.vColor2.value = [頂点1のRed値, 頂点1のGreen値, 頂点1のBlue値];
m_shader.data.vColor3.value = [頂点2のRed値, 頂点2のGreen値, 頂点2のBlue値];

と、シェーダーの入力パラメータを指定したとします。FlexからPixelBenderにアクセスする場合は、個々のパラメータごとに配列（Array）でパラメータ指定します。「scrPos1-3」「uvt1-3」「vColor1-3」というのがpbkファイル上のparameterです。

この指定をしたあとに

Graphics.beginShaderFill(m_shader);
Graphics.drawTriangles(頂点座標のVector);
Graphics.endFill();

を呼ぶと三角形のシェーディングが行われ、シェーダーで指定したルールで描画されます。けど、三角形ごとにこの１セット分を呼び出さないといけないです。「Graphics.beginShaderFill」の引数でShadeクラス（ここではm_shader）を指定したときに入力パラメータがShaderにて認識されるようです。

Graphics.beginShaderFill(m_shader);
for(i = 0; i < 三角形数; i++) { 
   m_shader.data.scrPos1.value = [頂点0のX, 頂点0のY];
   ....
   Graphics.drawTriangles(三角形iの頂点座標のVector);
}
Graphics.endFill();

とできればよかったのですが、この場合はparameterの解釈ができませんでした。パラメータを食うタイミングとしてはbeginShaderFillの段階のようですね。う～む、これは効率が悪くなりますねぇ。ということでシェーディング込みの三角形描画としてPixelBenderを使う方法は厳しいか。これだと、独自でラスタライズしたほうが速そう。

シェーダーが有効な描画命令は

Graphics.drawCircle
Graphics.drawEllipse
Graphics.drawRect
Graphics.drawTriangles

あたりがありますが（ラインを引くmoveTo/lineToでもShaderが使えるみたいですが未確認）、むしろ矩形を塗りつぶすように処理するぼかしや発光、ガンマ補正などには有効ではありそうですが、三角形描画は複数回呼ぶ必要があるだけに不得手なのかな。

入力画像は複数指定できるので、一度三角形データ（頂点座標とかUV値とか）を画像として保持してGraphics.drawRectで一括処理、なんてできるだろうか。そうすると、Zバッファ処理もおまけ的にできそうではありますが、、、そもそもFlex3のBitmapDataが1ピクセル4バイトのRGBAなので難しそう。いずれにせよ、まだまだ道は険しそうです。

追記：

ループ（for）機能はPixelBenderでは使用できないようでした。ということで、たくさんの三角形情報を押し込んでの（シェーダーサイドによる）三角形描画は厳しそうですね。う～ん、とりあえず2D効果にだけシェーダー類は使用して、3D系描画はシェーディングなしで考えるかなぁ。

続続・Flex3でのピクセルシェーダー（2009/04/10）

「Graphics.beginShaderFill」での「Graphics.drawTriangles」で、三角形の塗りつぶしをシェーダー対応してみました。

対応している証拠としてテクスチャマッピング＋頂点色の変更、を行ってます。

シェーダーへの入力情報としては、三角形の頂点とUVT値に加えて頂点カラーを渡せるようにしてます。ところで、シェーダーをpbjファイルとしてバイナリ出力する場合は（pbkファイルにて）関数を使用できないのですね。

シェーダーのソースを見れば、なんだと思ってしまうと思うのですが、ちょっと効率が悪いかも。本来線形で三角形は描画できるものなのですが（パースペクティブなUVマップがあると違いますが）、線形じゃない計算です。果たして、ポリゴン数が多いと耐えうるのか実験がいりそうです。

続・Flex3でのピクセルシェーダー（2009/04/09）

「Graphics.beginShaderFill」での「Graphics.drawTriangles」の使用ですが、UV(UVT)を指定しなければシェーダーで三角形も描画できました。

Graphics.drawTriangles(vers, indices, null, TriangleCulling.POSITIVE);

な感じでUV指定部分のみnullにすれば三角形部分だけくりぬける感じに。

ということは、UVの変形描画処理自身＋シェーディング計算をシェーダーでやってあげるとうまいこといけるのかもしれません。糸口はつかめました。後もう少し。これでなんとかなりそうな気配です。

Flex3でのピクセルシェーダー（2009/04/08）

夜な夜な勉強中です。「Adobe Pixel Bender Toolkit」にて適当なシェーダーを書いて、ActionScriptにpbjファイルとして食わしてみました。また別ページにまとめるようにします。3Dとしての三角形描画のページにて、drawTrianglesのソースをアップしました。解説はまだです。

よし、これで3D的なシェーディング処理ができる、と意気込んでたのですが、、、「Graphics.beginShaderFill」内で「Graphics.drawTriangles」が使えないです。「Graphics.drawRect」では効いてるのですが、、、う～む、おしい。別手段でなんとか抜け道はないものか・・・。

Adobe Pixel Bender Toolkit（2009/04/07）

「Flash10でGPU対応している」という記述はどうも「pbj」というバイナリファイルをShaderとして読み込むことで意味が出てくるようです。

Graphics.drawTrianglesを細工して、なんとかテクスチャ＋光源を元にしたシェーディングをしようとしてみたのですが、ちとアイデアが思いつかず。テクスチャに対してシェーディングのグラデーションを焼き付けてしまう、なんて荒業もチラッと考えたのですが実用的じゃないと思い、却下。

で、「Graphics.beginShaderFill」あたりで自由度が増すかなと思って調べています。

以下のページの「Adobe Pixel Bender Toolkit」というものでpbj形式のバイナリファイルを出力できるようです。

http://www.adobe.com/jp/newsletters/edge/july2008/articles/article3/index.html

「OpenGL 2.0 対応のビデオカードが搭載されている必要があります」という記述があるので、これがGPU対応ってことなのかな。CPUで強制計算させて環境依存させない、ということもできるようではあります。

ぱっと見た感じ、普通のGPU（というとわかりにくいか、HLSL的といった感じです）でのin/outと似てますのでなんとか3Dでも応用できそうかも。

しっかし、各社が独自シェーダーを作っていてどうも言語といえどもまとまりがないというか、3Dのファイルフォーマットと同じで乱立状態ですねぇ。知ってる（私自身、使えるわけじゃないです(^_^;;）だけで、HLSL/CUDA/RenderMonkey 、、、ほかあったけ、めんどくせ～です。ちなみに、CUDAはサンプルを眺めていたのですが、なんだかよくわからずに挫折しました（汗）。

Flex3でのMatrix3D.appendでの行列乗算について（2009/04/06）

var m1:Matrix3D = new Matrix3D();
var m2:Matrix3D = new Matrix3D();
m1.append(m2);

としたときに、4x4行列の乗算が行えるんですが

http://livedocs.adobe.com/flex/3_jp/langref/index.html

のドキュメントでは

public function append(lhs:Matrix3D):void
の場合は
thisMatrix = lhs * thisMatrix;

となっているのですが、うん？逆じゃね？と思ってしまいました。計算結果としては、

m1.append(m2);

とした場合に

m1 = m1 * m2

の結果が入るような、、、。

試しに

   /**
    * 行列同士のかけ算
    * @param[in]  m1  行列1の指定
    * @param[in]  m2  行列2の指定
    * @return  (m1 * m2)の乗算結果
    */
   public function MatrixMultiply(m1:Matrix3D, m2:Matrix3D) : Matrix3D {
       var x:int, y:int;
       var mx0:Number, mx1:Number, mx2:Number, mx3:Number;
       var retM:Matrix3D = new Matrix3D();
       var dat:Vector.<Number> = new Vector.<Number>(16, true);

       for(y = 0; y < 4; y++) {
           mx0 = m1.rawData[(y << 2) + 0];
           mx1 = m1.rawData[(y << 2) + 1];
           mx2 = m1.rawData[(y << 2) + 2];
           mx3 = m1.rawData[(y << 2) + 3];

           for(x = 0; x < 4; x++) {
               dat[(y << 2) + x] = mx0 * m2.rawData[0 + x] +
                                   mx1 * m2.rawData[4 + x] + 
                                   mx2 * m2.rawData[8 + x] +
                                   mx3 * m2.rawData[12 + x];
           }
       }
           
       retM.rawData = dat;
       return retM;
   }

のように独自で計算する関数を書いてみて結果を見たのですが、

m1.append(m2);

と　

m1 = MatrixMultiply(m1, m2);

が同じ結果になりました。ということは、

thisMatrix = thisMatrix * lhs;

となる気がするのですが、、、何か間違ってるかなぁ。

この逆がprepend関数なんですが、どうも結果が逆なような気がしないでもありません。どのサイトを見ても特にこの指摘がないのですが、根本的に自分の表現が間違ってるのかな（汗）。もしくは行と列の並びがCLAPACKみたいに逆とか。う～ん、このあたり気持ち悪いっす。

Matrix3Dの計算は遅い、というサイトもありますね。ということでベンチマークをとらなくては。計測してみた結果、自前で行列乗算するよりも「Matrix3D.append」を使うほうがはるかに速い結果になりました。

for(i = 0; i < 100; i++) {
  for(j = 0; j < 1000; j++) {
    m3 = m1.clone();
    m3.append(m2);
  }
}

と、上記の「MatrixMultiply」内のnewを外にだして、(y << 2)などはループの外に出して最適化したもので、

for(i = 0; i < 100; i++) {
  for(j = 0; j < 1000; j++) {
    m3 = MatrixMultiply(m1, m2);
  }
}

の計算をしたものを比較すると、「156 ms : 7194 ms」ということで圧倒的にappend使ったほうに勝敗があがりました。MatrixMultiply内でのループをすべて展開したら若干速くなるのですが、それでも5000msはかかってます。ということで、可能な限りMatrix3Dの関数を使うほうが高速になる、ってことになりそうですね。

mqoImporter Ver 1.02 for Shade10（2009/04/01）

メタセコイアのmqo形式をShade10にて読み込むプラグイン「mqoImporter」のWin64ビット版もビルドして、mqoImporterのページにアップしました。「mqoImporter_win_osx_102_2.zip」をダウンロードして解凍してくださいませ。

なお、ソース付き、Win32/Win64/Mac OS X(32bit)のプラグインを同梱してます。Shade9で動くかは分かりません。以降は何かプラグインを作る場合は、Shade10プラグインSDKでビルドしていくことになると思います。Shade10.5は以前（Shade8～Shade10.0.3あたり）より安定してますね。仕事でのお堅いドキュメント作成で使わせてもらってます。

Shade10プラグインSDK（2009/04/01）

ずいぶんと遅くなりましたが、Shade10プラグインSDKをダウンロードして、mqoImporterをShade10用としてビルドしました。mqoImporterのページにてWin版/Mac版をおいています。64ビット版は１つ前のものを使うようにしてください（機能はぜんぜん変わってません、ただ単にShade10用のSDKでビルドしただけ）。

後、Shade10でプラグインを作る際の雛形のHelloWorldプロジェクトをShadeのページの上のほうにおいておきました。このページは過去バージョンが混在していてカオスなので、いずれは過去の情報は消去か過去ログで別ページに移して整理しないといけないですね。

Shade10プラグインSDKでは、プリプロセッサにて

SXWINDOWS SXWIN32  <== Windows(VC++)の場合の指定
SXMACOSX           <== Mac OS X(XCode)の場合の指定（xplugins_PreFix.pch内にて）

の指定が必要になります。ですが、Shade9のプロジェクトはこれを指定してあげるとそのままビルドできてます。

実はディスプレイスメントマップっぽいでこぼこ実装も今のプラグインSDKでできるのですが、誰もやり方知らないと思う(^_^;;。＜技術ってわけじゃなくてお作法がややこしいですので。

Shade9あたりから「plugin_interface::create_rendering_objects」というのが追加されてまして、これはDirectX10で言う「ジオメトリシェーダーみたいな」ことができたりします。また、このあたりも解説してみることにします。

エイプリルフールなんで何かこじゃれたことを、と思ってたのですがなんてことはないいつもの更新になってしまいました（汗）。ほんとはディスプレイスメントマッププラグインでも作る予定だったのですが、、、。

ところで、4/1にいつも楽しみにしている円谷さんのところ（ウルトラマンのとこね）、つながんねぇ～～。

Future's Laboratory 技術格納庫 2004-2013 Yutaka Yoshisaka.

独り言日記（2009/04）