Rasterizer Test01（要：FlashPlayer10.1）

解像度640×480、△9800のトーラスにフラットシェーディングした状態で、自分の環境の場合30fpsくらい。背面カリングしてるので、実質△4000〜△4500くらい描画してる。ポリゴンあたりの描画面積のほうが影響ありそうなので、何枚描画できるかなんて性能評価の基準にならないかもしれないけど、まあ目安として。初代プレステが（たぶんローレゾで）30フレーム動作だと12000微少ポリゴン描画できるってことだから、なんとか近づけたい。目指せ初代プレステ。

Zバッファ持たせたので交差ポリゴンも問題なし。

Rasterizer Test02（要：FlashPlayer10.1）

テクスチャにもとりあえず対応。アルファブレンドはまだ。

Rasterizer Test03（要：FlashPlayer10.1）

ようやくBlenderローダーが前に進められそうな状況が整ってきたので、とりあえずハデな部分はこのへんで止めて地味な処理を詰める。勝手な解釈で曖昧にしてた部分が全部ひっくり返されて、かなり整理された。

FrustumClipping and QuadrantRenderEngine work together Demo（要：FlashPlayer9）

/core/dyn/DynamicTriangles.as の64行目以下

triangle.instance = object;
triangle.vertices = [v0, v1, v2];
triangle.uv = [uv0, uv1, uv2];
…

の部分を、以下のような感じに。

triangle.renderCommand.instance = object; //←この一行を追加
triangle.instance = object;
triangle.vertices = [v0, v1, v2];
triangle.uv = [uv0, uv1, uv2];
…

バカ正直に使うと当然負荷が大きくなるわけで、床面が真っ平らで良いならビットマップを透視投影した方が経済的だと思う。
QuadrantRenderEngine使用時は、通常のクリッピングの流れからバイパスして、視錘台の各平面と他のポリゴンとの交差をいっぺんに判定して分割、不可視部分を刈り取るようにすれば結構最適化できそうだけど、そこまでやるなら根本的なデータ構造含めて作り直したいっていう開発サイドの判断で放置されてるのかなぁ。

Away3Dに BSP/PVS を実装しようとしてるブランチを見つけてニヤリ。
コミッターはFP10版Away3DにPixelbenderによるシェーディング実装した David Lenaerts。
今どきのリアルタイムレンダリングシーンじゃ特に意識しないだろうし、Flash用エンジンに絞っても Alternativa3D とか infinity3d にはとっくに実装されてるし、これといったアドバンテージがあるわけじゃないけど、ライセンス的に緩めなAway3Dに組み込まれるのは本当にありがたい。

今のところObjectContainer3Dを継承したクラスとしてBSPTreeが実装されてて、空間分割されたコンテナをSceneに追加する形で使う。この辺はハナっからScene3DにBSPが組み込まれてる（と思われる）Alternativa3Dのほうがスマートだと頭の悪いオレでも思うので、今後の仕様変更でScene3Dに内包されるかも。そうなれば Zソート・クリッピング・カリング・ポリゴン交差時の分割処理に至るまでパイプラインの至る所で恩恵にあずかれるはず。あと、内部で持ってる物理演算や衝突判定の最適化にも取り入れようとしているみたいなので、ちょっぴり期待しておく。

まだまだガンガン仕様変更があると思うけど、どんな感じになるのか試したくて、以前作った迷路を使ってポータルシステムがどの程度カリングを最適化してくれるのかを見てみた。比較用にBSP/PVSを使わない場合も改めて作成。

BSPTreeとポータルの生成にはかなり時間がかかる。DoomやQuakeなんかだとレベルエディタを使って事前に作ったものを外部ファイルとして保存しておいて、実行時は読み込みだけで済むようにしてあるように、事前処理のがよさそう。Away3Dもこの辺は考えてあるようで、エクスポータークラスが用意されてる（PreFabにレベルエディタ的な機能が追加されたりして？）。今回は使い方がよくわかんねーのと、必要なデータ全部エクスポートするのこれ？って感じだったので諦めた。

Maze normal
Maze using BSP/PVS (BSP/PVS使用)

■操作方法
カーソルキー [CursorKey] … 移動 (move)
[Z], [X] Key … ティルト (Tilt)

※要：FlashPlayer10

BSP/PVS版は、スタンドアロンプレーヤーならかなりヌルヌル動く感じ。マシンパワーのある環境だと2つの違いが分かりにくいかもしれないけど、オレの環境（MacBookPro 2.33GHz Core2Duo）だと全然違う。クリッピングモードをRectangle Clippingにすると視覚的にも違いが見て取れる。Project stats の T-ELEMENTS と R-ELEMENTS を見ると処理対象のFaceが大幅に減ってるのが分かる。ワクワクしてまいりました。

ハードウェアの進化に伴って失われつつある先人達の技術を追体験しつつ手軽に勉強できるのが、ActionScriptで3Dをやる唯一のメリットだと思うので、こういうトピックは超アガる。ちゃんと自分のものにするには相当ハードル高いけど、とりあえず周辺をウロウロする。

参考：
BSP Trees（視覚的でわかりやすい）
バイナリ空間分割（Binary space partitioning）- Wikipedia
BSP trees in 3D worlds
ゲームプログラミングのためのリアルタイム衝突判定（Amazon）

Java版Quake II「Jake2」を、Google Web Toolkit（GWT）でJavaScriptに移植したという
Quake II GWT Port が、WebGLのベンチマークになりそうだったので動かしてみたメモ。
以下、MacOSXでのビルド手順。

QuakeII GWTは、Mercurialでソース管理されてるのでコレ必須。
http://mercurial.selenic.com/downloads/

サウンド関連でVorbis-toolsとLameも必要。MacPorts使ってるなら

sudo port install vorbis-tools
sudo port install lame

でインストール。Fink使ってるならそっちで。
どっちも使ってない場合は、Homebrew突っ込んで、

sudo chown -R $USER /usr/local
curl -Lsf http://github.com/mxcl/homebrew/tarball/master | tar xvz -C/usr/local --strip 1
brew install vorbis-tools
brew install lame

でもいいらしい。
オレはMacPorts経由だったので他の方法は試してない。ダメだったらすんません。
これで準備完了。

適当なディレクトリに移動したあと、

hg clone https://quake2-gwt-port.googlecode.com/hg/ quake2-gwt-port

で、QuakeII GWT Portのリボジトリがコピーされる。
続いてサーバー、クライアントのビルドとリソースのインストール。

cd quake2-gwt-port
./build-dedicated-server
./install-resources

./install-resourcesとか時間かかるので、メシ食うとか風呂入るとか。
終わったら一部ディレクトリ構造を変更。なんかバグらしい？

cp -r maven-build/server/target/gwtquake/war/gwtquake war

以上でビルド完了。

サーバーを起動

./run-dedicated-server

起動できたら、WebGLに対応したブラウザで、

http://localhost:8080/GwtQuake.html

にアクセスする。
公式には、Chromiumが推奨ブラウザになってたけど、WebKit Nightly Buildでも動いた。

自分の環境では、11〜13fpsくらいの速度。遊べない事もないけど、たまにブラウザごと落ちる。ドライバの問題なのかGPUそのものが対応できてないのかよくわかんないけどそんな感じ。
HTML5よりなにより、GWTスゲーっていう印象。

mozOrientation + PV3D（要：FireFox3.6 + Flash Player9以降 + 加速度センサ付きPC）
※加速度センサ積んでれば、PCを前後左右に傾けることで玉が転がる

FireFox3.6が加速度センサの傾き検出できるってんで、ありがちな物を作って体験してみた。
自分のMacBookProでしか試してないんで確証はないけど、mozOrientationがディスパッチされる環境なら動くはず。

参考サイト：
加速度センサーの値を表示するサンプル(MozOrientation)

今回のネタを作ろうとFireFox3.6にしたらFlashの再生時、妙に負荷かかるようになった。
起動して数時間使った後で、上のデモを再生すると頻繁にGCが発生してるみたいな挙動になって、衝突判定すり抜けたりする。FireFoxを再起動すると直るんだけどオレの環境の問題かなぁ。

suumo（要：Flash Player9）

スーモ萌え。
を目指して作ったものの「スーモではない何か」が出来た。
無意味にファー表現したので、見た目のわりにポリゴン数食ってたり、負荷が増大してて非常にコストパフォーマンスが悪い。低コストな屋外の景観生成が個人的な課題。一つの方法論がドライブシミュもどきの時の構造だけど、これよりさらにコストを抑えられないもんかな。

Imitate Morphovision（要：Flash Player9）

※ステージドラッグで視点位置が変わります。

岩井俊雄さんと、NHK放送技術研究所が共同開発したモルフォビジョン。
プリズムミラーで反射させたプロジェクタからの光を使ってスリットスキャンする方法で、立体物の見えを変化させるシステム。Another time, Another space の立体版って感じだけど、デジタル的な画像処理じゃない方法で摩訶不思議な現象を作り出してるのがカッコイイ。悔しいかな一度も本物を見た事がない。

んで、実機と同じような状況を作ったら、以前作ったゾートロープのようにソレっぽく見えたりしねぇかなぁーとか思ったのが2年くらい前。エライ時間がかかったけど、プロジェクションマップがそれなりに動いたので、技術的に課題だったライトマップ的なものが実装できて、ようやく動かせた。見やすくするためにブレンド使った以外は、スリット光の移動と物体の回転しかしてないんだけど、歪んで見えないことも…ない感じにはなった。スリット光のピッチが荒いのと、回転と同期がうまく取れてないあたりが課題か。でもまぁ、明らかに普通に回しただけじゃこうは見えないので、ちょっと嬉しい。

実機みたいに滑らかで有機的な振る舞いをさせるには、もっと高fps叩き出せるプラットホームじゃないと無理があるかなぁ…。それとも根気よく調整すればもう少し改善するのか？ とりあえず一歩前進。なんとなく可能性が垣間見えたので、またしばらく寝かせとこう。

WebGL概要

• Mozillaが作ってたCanvas3Dがベース
• OpenGL 2.0 or OpenGL ES 2.0をサポートする環境でハードウェアアクセラレートされた2D、3Dグラフィックスを表示する
• HTML5のCanvasを通じた、JavaScriptとOpenGL ES 2.0のバインディング

リソース

• khronos WebGLセクション
• WebGL Cheat Sheet

WebGL対応ブラウザ（いずれも開発中）

• Webkit nightly Build
• Minefield (FireFox 3.7 nightly Build)
• Chorome (Chromium)
• Opera? ※未確認

仕事が早いというか、気が早いというかすでにいくつかのライブラリが公開されてる。

WebGLライブラリ

• WebGLU　※MIT License
• SceneJS　※MIT License または GPL Version 2
• SpiderGL　※GNU Library または LGPL
• GLGE　※LGPL

※SpiderGLが、PV3Dとかと感覚的に近いのかな？GLGEなんかはシーングラフをxmlで記述したものをベースに作ってく感じで勝手が違う。

上記ライブラリは使わずに、NeHeからの移植チュートリアルを大いに参考にしつつコードも拝借しながら、いくつかデモを作ってみた。いずれも MacBookPro (Mobility Radeon X1600) OSX10.5.8 にて Webkit、Minefield、Chromium で動作確認。
※Mac版Webkit r54648以降だと動作しなくなった。

3D Cube（要：WebGL対応ブラウザ）

3D Cube Matrix（要：WebGL対応ブラウザ）

Billboard Particle（要：WebGL対応ブラウザ）

思ってたよりパフォーマンス出ない。WebkitとMinefieldに関してはGPUアクセラレーションが効いてるっぽいけど、Chromiumでは機能してない感じ。開発中のものにケチつけてもしょうがないけども、回転数が足りなくて一番おいしいとこが使えてないエンジン載せ替えたばっかりのハチロクみたいなもどかしさがある。「JavaScriptでこんなに！？」みたいなインパクトが欲しいな。オレのコードと環境の問題かもしれんけど。
OpenGL + GLSLそのものを勉強する環境としてはカジュアルに取り組めていいと思う。個人的にはかなり勉強になったし。

なんていうか、派手なビジュアル作りに使うってのはむしろ亜流で、もっと地味なとこでじわじわ効いてくる技術なんだろうなーと漠然と思った。
Flashプラットフォームと比較して云々ってのは、なんかズレてる気がする。マーケティング戦略としてはアリなのかもしれんけど。

2010/02/11追記：
ほとんどシェーダーにやらせる感じの4KB intro的アプローチだとどうなるか？と素朴に興味が涌いたので、日本屈指のscener、kiokuさんの4K Procedural Gfx Monitorに付属するサンプルのシェーダーを拝借させていただいてレイトレ動かしてみた。

Raytrace（要：WebGL対応ブラウザ）
※Minefieldだと動かない。要調査。※Minefieldでも動いたそうです。

ブラウザのウインドウサイズに追従するので、あんまりデカくするとキビしいけどなんとか動いてる。この手法ならGPUパワーでゴリ押しできそう。やっぱりJavascriptとのバインディングって釣り合いが取れてないんじゃなかろうか。

随分楽しめたんで、もう満足。
OpenGL + GLSLをちゃんと勉強しとこ。

Projection map Test（要：FlashPlayer9）
※各Cubeはドラッグで動かせます。

プロジェクションマップの習作。
パフォーマンス悪いなぁ。根本的に考え直さないとダメか。

昨年末、yas@ClockMakerさんのご好意で「Flash3Dコンテンツ制作のためのPapervision3D入門」を献本していただき、年末年始に少しずつ読んだ。yasさんの太っ腹さに感謝。
あざーッス！

総じて懇切丁寧、全項カラーで超豪華。この本を隅々まで読み込んで実際に手を動かし、それでも理解できなきゃPV3D以前の問題なんじゃね？と、言えるくらい基礎から実践＋αまで非常に盛りだくさんな内容でお腹いっぱい。PV3DのAPIを使いこなして、Flashコンテンツに3D要素をちょろっと加えたいだけならこれ一冊で十分。

ただ、説明の分かりやすさや冗長さの回避が優先されて、多少語弊のある記述もチラホラ見受けられるので（UVの解説とかシェーディング系Materialあたり）、ネット上に多数ある情報も併せて参照するとなお良い。このへんは入門書のジレンマですな。

「英語わかんね」とかいうモノグサ野郎もこれでバッチシ！PV3Dに興味のあるFlashデベロッパは、手元に置いて損は無いかと。