btConvexHullShape Test（要：FlashPlayer11）

Pellet は、C++で書かれたオープンソースの物理演算ライブラリ「Bullet」のAS3移植版。
BulletはBlenderのゲームエンジンで使われてたりする。（MMDが採用してるっていうほうが通りがいいのかな）そのAS3ポートといえば、

Away3D 4.0 jiglib vs Bullet « DevJamMemo
AwayPhysicsを使って衝突判定をしてみる
Flash Player 11 対応の 3D 物理演算ライブラリ「AwayPhysics」 | ClockMaker Blog

等のエントリーですでに紹介されているAway3D4.0用のAwayPhysicsがあるけど、PelletはAlchemyでネイティブのBullet呼び出す形式ではなくて、ピュアAS3で書いてるっぽい？ そういう理由からか、現状はBulletの一部の機能が実装されている状況。Petit Bullet 略して Pellet ってことなんだろうか。

機能・パフォーマンス的にAwayPhysicsに及ばないけど、描画と完全に切り離して扱うことができるので自前ライブラリと組み合わせて動かすことができた。Box2DとかJigLibとか触ったことがあれば概ね扱いは同じ。

1. dynamicsWorldにもろもろのパラメータ渡して初期化
2. dynamicsWorld内で扱うbtRigidBodyを登録
3. EnterFrame毎に stepSimulation() で演算
4. btRigidBodyの行列を、表示用のオブジェクトにコピー

みたいな流れ。

とはいうものの、JigLibと比較すると設定しなくちゃならない必須パラメータが随分多い上に、リファレンスの類が何も用意されてないので、最低限動かすのに必要な情報は Proscenium のサンプルコード

• TestPhysicsAPI.as
• TestPhysicsFractalTerrain.as
• TestPhysicsStaticMesh.as
• Tutorial06_SimplePhysics.as

から拾った。特にTestPhysicsAPI.as が有用。

あと、Pellet.swc内の catalog.xml からクラス一覧を取り出して、本家Bulletのリファレンスや、Bullet 2.76 Physics Japanese Manual と突き合わせながら用意されてそうなメソッドを探した。無駄に労力使って泥臭く。開発環境大事 orz 「bt〜」というクラス名を本家Bulletと揃えてくれてあるので、アタリを付けるうえでとても助かる。

エントリー冒頭のデモは、凸構造形状を扱うクラスbtConvexHullShapeを使って、球などで近似しない場合にどの程度動くのかを試したもの。一つのコリジョンデータあたり20頂点くらいなんだけど10個くらい動くとキツい。勘所が分かってないのでオレの実装がしょーもないことやってる可能性のほうが高いけど、大量のオブジェクトをガンガン出してヒャッハーしたいとなるとやっぱ球か。

ということで btSphereShape（球体）100個。

btSphereShape Test（要：FlashPlayer11）

自分の環境だと40〜45fps。マジメに最適化やって改善できるんだろうか。。

地形との衝突判定用途の検証に、凹面三角形メッシュを扱うbtBvhTriangleMeshShapeを使ったウォークスルーも作ってみた。

btBvhTriangleMeshShape Test（要：FlashPlayer11）

初期化に結構な負荷と時間がかかりますが、気長にお待ちください。
カーソルキーで移動、Z,Xキーでカメラのピッチング操作。
※モデルデータは、BTAさん制作の「ケロリン町1.05」をお借りしました。
※主な道路に沿う形でコリジョンメッシュ作ったので、通れそうで通れない路地があったり、ぶつかるはずのオブジェを貫通したりします。

コリジョンメッシュは△1000程度。これは思っていたより現実的な速度で動いた。コリジョンのポリゴン削ればさらに負荷を下げられるかもしれない。

今のところ btPoint2PointConstraint、btHingeConstraint といった、複数の剛体を繋いで複雑な物理モデルを構成するためのクラスの大部分が移植されてないようなので、連動して btRaycastVehicle、btKinematicCharacterController という有用なアクションインターフェースが使えない。この辺でもAwayPhysicsに大きく差をつけられてる感じ。

もうひとつ気になるのは、Proscenium を含めて今後もAdobeが開発を続ける気があるのかどうか。Pixel Bender 3Dもツールキットさえ提供されないまま消えてしまいそうだし、同じようにフェードアウトしそうな悪寒。Stage3D API 直叩き派としては描画ライブラリを規定しないPelletのほうが扱いやすいし、名前もカワイイので今後も開発が続行されることに期待したい。
あとリファレンス欲しい。

ランバートのみじゃあんまりなのでフォン実装。なんかいろいろおかしい気もするけど、ひとまず良しとした。.blendのパース時に手を抜いてたフェイス定義を修正。共有すべき頂点は共有するように。

Phong Shading Test（要：FlashPlayer11）

ビルボード実装。

Billboard Test（要：FlashPlayer11）

keim_at_siさんのエントリー「ActionScriptでPoint Sprite」と同じように4頂点を座標変換した後、上下左右に各頂点を移動させる方法で常にカメラの方向を向くようにしてる。

ポリライン実装。

Poly-line Test（要：FlashPlayer11）

Stage3DにはGL_LINE相当の描画モードが無いので線を描くことができない。以前Twitter経由で、9ballsyndromeさんに教えて頂いた http://forums.adobe.com/thread/886188?tstart=0 の方法で、見かけ上ワイヤーフレーム表示することもできるけど、これはサーフェスのエッジ部分だけ描画する方法なので、ポリゴンを真横とか真上から見たりすると線が表示されなくなる。うまい方法無いもんかと悶々とし続けた結果、これも2枚の三角ポリゴン使って描くしかなさげだという結論に達したのでそうした。

頂点を座標変換するところまではビルボードと同じ。各頂点を移動する処理の部分で、ラインの始点・終点の接線ベクトルと視線ベクトルの外積を取って、その方向に線の太さ分移動させてる。欠点として、ラインの接続部分が綺麗じゃなかったり、カメラに真っ直ぐ向かってくるラインの表示が破綻したりするので改善の余地あり。

Game Programming Gems 3 に載ってる Billboard Beams でごまかせそうだという情報を得たので、本屋で立ち読みして何となく把握した。静岡市立図書館にGame Programming Gems置いてくれ。

下記は、描画サイズ640×480でテクスチャ貼った板ポリをランダム配置して回しただけの簡単なデモ。強制Softwareモードで動かしてる。

Stage3D Hardware Acceleration Test（要：FlashPlayer11）

これを自分の環境で試してみると、

WindowsXP SP3 Intel PentiumM 1Ghz：△12000で12〜24fps（CPU使用率：85%〜95％）
OSX10.6.8 Intel Core i5 2.53 GHz：△20000で60fps（CPU使用率：120〜150%）

格差すごい。Core i5のほうはまだ行けそうな感じだけど、PentiumM 1Ghzのほうは△12000でいっぱいいっぱいな感じ。どんな環境でもそれなりに動くものを作るとなると、この差異を吸収できるだけの柔軟さが求められるのか。。
GPUでの描画性能との対比で考えると「Softwareモード遅ぇー！」ってのが率直な印象だし、ブラウザの表示領域目一杯使って、10万オーダーのポリゴン描画とかちょっと現実味がない。

とはいえ悪あがきをしてみよう。
描画面積が小さくなればフィルレートが上がるはずなので解像度を下げてみる。
描画サイズ320×240版

WindowsXP SP3 Intel PentiumM 1Ghz：△12000で28fps〜60fps（CPU使用率：42％〜80%）
OSX10.6.8 Intel Core i5 2.53 GHz：△20000で60fps（CPU使用率：40〜50%）

これならPentiumM 1Ghzでも△12000描画で概ね30fps以上をキープできた。安直だけど効果はデカイ。

テクスチャ以外に
単色カラー塗り
頂点カラー塗り
テクスチャ（ミップマップあり）
加算ブレンド
とかで違いが出るか試してみたけど、それぞれ単独で使っても極端にパフォーマンスが変化することは無かった。

これをどう捉えるか？
320×240で△12000描画して30fpsって、初代プレステ並の描画性能なわけで、FlashPlayer上でのソフトウェアレンダリングにしては結構ヤルんじゃないのかコイツは…と、超前向きな解釈もできる。確かに、自前ラスタライザの場合640×480で△4000〜△4500をPentiumM 1Ghzで描画した場合15fpsにも届かなかったので、これはこれでスゴい。

シーン全体のポリゴン数が△10000程度でポストエフェクトも使わないようなコンテンツなら、描画サイズを調整するだけでも、ある程度古い環境までカバーできそう。逆に、描画サイズを大きく取りたかったり、数十万ポリゴン描画するのが前提な場合、勝手にフォールバックされるのはむしろ危険だと思うので、警告出して再生そのものができないようにする配慮が必要かと。

描画サイズ小さくすることでパフォーマンスは向上したものの、いまどき320×240はいくらなんでも小さい。低解像度でいいから表示面積を大きく拡大したいなーと思ったら、これがどうもステージサイズに連動して拡大されたりしないっぽい。
Betaリリースの段階だとStageScaleMode.NO_SCALE指定してなかったりすると、Stageサイズに合わせて拡大表示されてた記憶があったんだけども…、現状はconfigureBackBufferで定義されたサイズで固定になってしまう。フルスクリーン表示も試してみたけど小さな描画領域が表示されるのだった。

ダメモトで、Context3D.setRenderToTexture()使ってテクスチャレンダリングして、それを貼った板ポリ描画。
描画サイズ640×480、256×256のテクスチャに描画

WindowsXP SP3 Intel PentiumM 1Ghz：△3000で17fps（CPU使用率：87％〜96%）

普通に描画バッファに描くより猛烈に遅い。。結局、バッファ自体は640×480で確保してることに変わりないから、テクスチャレンダリングしてる分余計に負荷がかかるだけってことだろうか？Softwareでマルチパスは諦めたほうがよさそう。

ならば、Context3D.drawToBitmapData() 使ったらどうか。
バックバッファ320×240、同サイズのBitmapDataに描画、640×480に引き延ばして表示
若干パフォーマンスは落ちるけど、描画バッファに描くだけの場合と同じような速度出た。このサイズなら使える手段かもしれない…けど、負荷無く拡大表示できる方法ないもんかなぁ。

と、あれこれ試してみて、オレ的にはこれが活きる環境って限られるんじゃないの？という印象。強制的にSoftwareになっちゃうLinux環境とか、Win/Macで、そこそこのCPU積んでるけどGPUモードには対応してないマシンとか? 数年経ってSandy Bridgeがあたりまえ、みたいな状況になれば大概GPUで動くようになりそうだし、今後のアップデートで対応範囲が広がるかもしれない。個人的な方針として、当面はSoftwareモードへのフォールバックはあんまり気にしすぎないようにして、GPUでの動作に重点を置くことにする。

作るものの方向性次第で、PV3D, Away3D3.6とかのベクターベースなライブリを採用した方が良いケースもまだまだありそうだ。

Stage3Dが開発コードネーム“Molehill”としてお目見えした際には「DirectX9, OpenGL1.3, OpenGL ES2.0（モバイル） に対応したグラフィックカードを搭載してること」みたいな案内があったんだけど、正式公開時のリリースノートにそういった記述は無い。Known Issuesとして多少の情報が載ってる程度。

リリースノートやらWeb上の情報で見かけたものから把握できたのは

• Mac OS X では、Intel GMA、ATI Radeon x1600、ATI Radeon 2400 が非対応。
• VIA チップセットはサポート外。
• Linux ではGPUアクセラレーションに非対応。
• 2009年以前にリリースされたカードはサポート外？ドライバの更新日の話？
  （via: http://cuaoar.jp/2011/09/starling-actionscript-3-1.html）

といった具合。

MacやLinuxに関しては動かない環境が（特にLinuxは残念な方向に）明確だけど、Window環境についてはかなりアバウトな感じ（オレが見つけられなかっただけかもしれないけど）。http://www.techpowerup.com/gpudb/ で、2009年以降のGPU拾っていけばそれなりに絞り込みができそうな気もするけど、主にWinの場合なんかだとサポート外であっても（ドライバがアップデートされたりして）動作するケースもありそうな気がするし、実際のとこどうなのかが知りたい。

Adobeが「動作確認済GPUリスト」みたいなものを公開してくれることを期待しつつ、個人的にログを取ってみることにした。

Stage3D Hardware Acceleration Test（要：FlashPlayer11）

上記のデモをGoogle Chromeでブラウズすると、WebGL対応の環境なら自動的にGPU名を取得して情報を登録します。WebGL非対応の環境や、GL_RENDERERの戻り値でGPU名が受け取れない場合、もしくはChrome以外のブラウザで閲覧した場合は、手入力でGPU名を登録できるようになっております。登録されたGPUは http://blog.r3c7.net/stage3davailablegpu/ で確認できます。

FP11Betaの時のように Context3D.driverInfo でGPU名が取得できればこんな回りくどいことをしなくて済んだんだけど、他に良い方法が思いつかずWebGLのgetParameterでレンダラを取得してる。なのでWebGL非対応環境と、レンダラ名が「mozilla」とか「ANGLE」、「WebKit WebGL」になってしまうケースでは手入力してもらうしかないという状況。
もっといい方法があればどなたかご教示いただけるとありがたいです。

2011.10.20追記
やっぱり探せてなかった。Adobeの中の人 Andy Hall さんにTwitter経由でStage3Dのハードウェアアクセラレーションをサポートしない環境についての記事を教えて頂きました。
http://kb2.adobe.com/cps/921/cpsid_92103.html
現状は、これらの環境でGPU使えないことを承知した上でコンテンツを作る必要があると。

Stage3D hardware accelaration available GPU listの方は動作実績リストとして一応の意味があると思うので、引き続き情報提供いただけるとうれしいです。

FlashPlayer11がリリースされてStage3Dが解禁になったのを機に、以前作ってた自作ライブラリをStage3Dベースに置き換える作業をグダグダと進めてるので、作りながら気づいたことなんかを書き残していけたらいいなと。そんな感じでnote.x再始動であります。

ライブラリの現状は以下のような感じ。

シーングラフ、カメラ実装済。シェーディングについては、現状フラットシェーディングのみ。

Stage3D Test01

ポリゴンのエッジだけを描画する方法で、なんちゃってワイヤーフレーム表示。

Stage3D Test02

旧ライブラリから引き続き.blendローダー搭載。
これだけが他の有名ライブラリに無いトピック。

Stage3D Test03

頂点カラー焼き付けで、なんとなくAO風味。

Stage3D Test04

旧ライブラリはZバッファ持たせたいが為に自前でソフトウェアラスタライズやってた。FlashPlayer10の時点ではそこそこ高速化できてたと思うけど、それでも描画周りがかなり足を引っ張っていて、正直行き詰まり感が強かった。
Stage3Dのおかげでポリゴン描画や座標変換やらをGPUに丸投げできちゃうので、山ほどポリゴン描ける。PV3Dで△1000あたりが限界とかやってたあの頃がウソのよう。ポリゴン描画のためにやらなきゃならない事が相当減ったし、オレ程度のレベルでも何やらスゴげな事が出来そうな気にさせてくれるのはスゲーありがたい。（簡単になったわけではないんだけども）

まぁなんつーか、Stage3D周りはこれまでのAPIから完全に逸脱してるし、機能的にも「劣化OpenGL」みたいな中途半端さがあるけど、なんだかんだいってAS3でこういうのが書けるってのは気楽でいい。これくらいがオレみたいな道楽でリアルタイムレンダリングやってる人間には案配がいい感じがするんですわ。ShockWave3Dよりも遙かに間口が広いと思うし。
地方のWeb屋にとって、仕事にすぐさま活かせるものでは無いからこそ目一杯遊んでおきたい。

Away3D 3.6リリース。

Away3D 3.6.0: Flash 10 upgrades and the Influxis Battlecell API

実質、3.5.3リリース時の仕様をそのまま引き継ぐ形でメジャーアップグレード。予告通りNumber3D廃止、めでたくネイティブ 3D APIに完全移行。FlashPlayer9向けの2.x系は、メンテナンスアップデートのみ行われていくことになる模様。個人的には面白味が減ってしまった。

今回のデモは、FMSのホスティングやってるInfluxisと組んでRTMFP使ったマルチプレイヤーのFPS。4人まで同時接続できるらしいんだけど、海外サーバーな所為か2人でもうゲームにならなかった。趣旨と関係ないけど、マウスドラッグでエイミングはやりにくいな。

放置しっぱなしの過去エントリをどーするかねーと思いつつ、とりあえずView3Dに関するエントリを修正。

MatrixAway3D

ビルトインMatrix3D

値を読み取るだけなら、

var tx:Number = Object3D.transform.tx;

という記述を、

var tx:Number = Object3D.transform.rawData[12];

に置き換えることで対処できる。

要素の値を変更する場合、MatrixAway3Dの要領で

Object3D.transform.rawData[12] = 100;

なんて感じで直接代入しても変更が反映されないので、

var vec: Vector.<Number> = Object3D.transform.rawData;
vec[12] = 100;
Object3D.transform.rawData = vec;

と、Matrix3Dの仕様に準ずる。

また、MatrixAway3Dで実装されていたメソッドの

• quaternion2matrix
• compare

と、ゲッター／セッターとして定義されていた

• forward
• up
• right

は、Matrix3DUtilsという新クラスが引き継いでる。
forward, up, rightについては読み取り専用でそれぞれ

• getForward
• getUp
• getRight

というメソッドに変更になった。

あと、ベクトルについても主要な部分はNumber3DからVector3Dへ移行してる。
まだ一部でNumber3Dが使われている部分があるけど、最終的にはなくなるみたいなのでNumber3Dは忘れてよさげ。Number3Dに実装されてたgetAngleメソッドは、新クラスVector3DUtilsが引き継いでる。

今回の仕様変更がどの程度影響してるのか分からんけど、じわじわと高速化してきてうれしげ。新機能いらないから洗練してほしい。

2010/09/16追記
とか言ってるうちに、FP10版3.5.4にアップデート。
ArrayをVectorに置き換えたりという地味な最適化を目的としたものみたいだ。

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）