!!!独り言日記 !!有料粗大ごみ処理券（2009/04/29） 近所のコンビニで聞いてみたら「有料粗大ごみ処理券」を出してくれました。 なるほど、切手などと同じでレジで言えばいいんだ。 今まで大きいゴミを始末してなかったのがバレバレですね(^_^;;。 しかし、自分自身、つくづく片付けが苦手だなぁと。ダンボールに荷詰めをしているのですが、部屋がなかなか片付かないです。ゴミや不要な本などは捨てるようにくくったのですが、まとめるのがヘタなのか部屋の空きスペースにあんまり差がないです。 こりゃ、GWの半分は大掃除と引越し準備になりそう。 言い訳はできないですが、引越し準備に精を出しているのもあり、メインの仕事が遅れ気味です（汗）。いつもどおり、理論を考えて検証・実装しているのですが、う〜ん、いいところまで行ってるような気がするけどいまいち結果が芳しくない、、。 ShadeからのmqoエクスポータとFlex3あたりをGWあたりで掘ろうと思ってたのですが、仕事の穴埋めで費やしてしまいそうです。 !!大掃除（2009/04/29） 近々引越し予定でして、GWはまずは大掃除から。ということで、 燃えるゴミ、燃えないゴミ、資源、粗大ゴミ、パソコン、に分類しているんですが分からないことが多いです。 以下、我が東京都品川区のルール。地域によって違いがあるそうです。 !資源（週一回の回収） *割れていない蛍光灯 *きれいに洗ったプラスチック容器包装（コンビニ弁当の容器など） *ペットボトル・ビン・カン *乾電池 *新聞雑誌（紐で縛ってまとめておく） *本（マンガ本含む。紐で縛ってまとめておく） *ダンボール（紐で縛ってまとめておく） *紙パック（すすいで紐で縛ってまとめておく） !燃えるゴミ（週二回の回収） *CD/DVD *紙類 *フロッピーディスク *ビデオテープ、カセットテープ *汚れているプラスチック容器包装 *ビニール *ゴム製品類・革製品類 紙が重要書類だったりすることもあるので、破いて分解。 フロッピーやCDは読み込みできないように傷をつけておく（重要なことが記録されている可能性があるため）。 音楽CDやDVDはBookOffなどに持っていく手もありますね（私は面倒なので燃えるゴミで出してしまってます）。 !燃えないゴミ（週一回の回収） *陶器・金属類 *ガラス類、割れた蛍光灯 *カセットボンベ・スプレー缶・ライター 刃物などの危険物は、新聞紙でくるんで「キケン」と記載。 パソコンのケーブル類やマウスなど周辺機器は燃えないゴミでＯＫ（大家さんに確認を取ると燃えないゴミ扱いとのこと）？ CDドライブやハードディスクなどはどうなるのだろう？ 後、自作パソコンのマザーボードとかサイズの大きい音源などはどうなるのだろう？まだ未確認です。 !粗大ゴミ 上記の中でもイレギュラーな30cm角以上のゴミは粗大ゴミ扱い。 これは事前に申請して回収してもらうことになります。お金がかかります。 各県や区のHPにて確認。 また、「有料粗大ごみ処理券」というのを事前に購入しておく必要があります。 どこで売ってるんだぁ、、、。ちょっと行脚して探しにいかねば。コンビニも特定の場所でしかおいてないのかな？これは○○区限定（私の場合は品川区）のシールになってるみたいです。他の地域の処理券は使えません。 品川区の場合は、１品目にて200円〜1400円。 私が捨てる予定のものは、 *布団 *ビデオデッキ *DVDプレイヤー *トースター（パン焼き）←リストにないもの *米びつ *こたつ *こたつ板（こたつと板は別扱いで料金かかります） *湯沸かし器 *スピーカー など。PCのマザーボード類はここに入るのかは確認しないと（30cmくらいはあるよね、たしか）。マザボの場合はパソコンリサイクルかなぁ。 !パソコン リサイクル対象です。これもイレギュラー扱いで、メーカーが分かるものはメーカーの回収窓口に問い合わせ、自作パソコンなどのメーカーが分からないものは http://www.pc3r.jp/ で回収してくれるとのこと。パソコン本体とディスプレイ、それに付属する キーボード、マウス、テンキー、コード類、マイク、スピーカーなどは回収してくれる模様。ですが、それ以外に買った周辺機器は分からないですねぇ。 これも問い合わせなければ。マザーボードも回収してくれるのだろうか。 ちなみに、自作PCの場合は4000円〜5000円台の料金がかかるみたい。たけぇ、、、。 メーカーに回収依頼する場合でもやはり3000円〜4000円は取られますね。 と、昔はそんなに苦労しなかったはずですが（燃える・燃えないはたしかに現在は楽になったんですが）、パソコンと家電品の扱いは、メーカー回収の義務が発生しているのでなんだかややこしいです。 そして、捨てるだけで私の場合は数万は予算を見積もらないといけないっすねぇ。 一瞬、面倒だから便利屋にでも頼もうかなという考えが横切ったのですが、いずれにせよ費用は発生するわけなので、自分で処理するほうがいいすね。 しかし、パソコンの処分が思いのほか出費になるのでいたいところです。 だから不法投棄も増えてるんだろうなと。 ルールは地域によって違うのがなんだかなと。う〜ん、せっかくのネットワークで情報共有できる場があるので、誰か（というよりも自治体が）全国のゴミ処理のためのまとめサイト作ってほしいものではあります。 粗大ゴミもリスト以外の品目も多く出るでしょうから、データベースで管理してほしいよな、とか。 とりあえず、分からないことがまだまだあるので役所での確認や業者に電話せねば。 確定申告(e-tax)だけじゃなくて、このへんも便利になってほしいですね。 粗大ゴミは品川区の場合はネットで申請できるのですが、有料粗大ごみ処理券は別途購入だし、リストにない品目もあるので結局電話か役所で確認とらないと安心できないです。 !!Shade ←→ メタセコの相互変換（2009/04/25） メタセコのmqo形式をShadeに読み込むインポータは作っていたのですが、 その逆の作業を行いたいことがまれに発生するため（Shadeでざくっと作ったものをメタセコでちまちま調整したい、そしてShadeに戻したい）、Shadeからのmqoエクスポータを作成中です。出来次第公開します。 Shadeで作ったテストシーン。 {{ref_image mqo_img00_20090425.png}} Shade上でmqo形式にて出力して、メタセコに読み込んでみました。 {{ref_image mqo_img01_20090425.png}} Shadeから他形式に出力する場合は、すべてのパターンにて対応するというのはなかなか骨が折れるため（リンクとかスキンとか）、自分で使う目的のみの機能に制限する予定です。自由曲面はポリゴン変換で。 4頂点の面がある場合は、三角形に分解しないで扱うようにしてます。 しかし、数値入力での頂点位置指定はShadeでもメタセコでも機能としてほしいところですね。また、気が向いたらプラグインにて作ってみることにします。 某所で某CADソフトを見せてもらいまして、なんというか数値指定のエレガントさ、そのまま造型に持っていけるシビアさに感動してしまいました(^_^;;。設計用CADソフトってすげ〜〜。 !!AVIからFLVへの変換ソフト（2009/04/23） AVIからFLV変換できるフリーソフトを探していたのですが、いいのがありました。 BatchDOO! http://www.vector.co.jp/soft/win95/art/se436800.html Vistaでも動作します。 avi/mpeg1/mpeg2/mpeg4/wmv/mov/swf/flvなどを相互変換できるようです。 実験的にAVI→FLVにコンバートしてみましたが、ビットレート調整（ようは劣化具合調整）もできてなかなかナイス。また、Youtubeやニコニコ動画にアップする際のプリセット設定も用意されてます。 今までは、製品版のFlashに付属していたflv Encoderを使ってたのですが、BatchDoo!のほうが直感的な気がします。 !!Oracle by Sun（2009/04/20） 結局はSunはOracleの傘下になったのかぁ。これはビッグニュースです。 http://www.itmedia.co.jp/news/articles/0904/20/news110.html IBMは破談したのね。 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」で、三角形の塗りつぶしをシェーダー対応してみました。 {{flash PixelBenderDrawTriangle_20090409.swf,width=300,height=300}} 対応している証拠としてテクスチャマッピング＋頂点色の変更、を行ってます。 シェーダーへの入力情報としては、三角形の頂点と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としての三角形描画|3Dとしての三角形描画_Flex]]のページにて、drawTrianglesのソースをアップしました。解説はまだです。 {{flash PixelBenderTest_20090408.swf,width=300,height=300}} よし、これで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. = new Vector.(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_shade]]のページにアップしました。「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|mqoImporter_shade]]のページにてWin版/Mac版をおいています。 64ビット版は１つ前のものを使うようにしてください（機能はぜんぜん変わってません、ただ単にShade10用のSDKでビルドしただけ）。 後、Shade10でプラグインを作る際の雛形のHelloWorldプロジェクトを [[Shadeのページ|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にいつも楽しみにしている円谷さんのところ（ウルトラマンのとこね）、つながんねぇ〜〜。