note.x

Adobe製Stage3D用フレームワーク Proscenium に付属してくる物理演算ライブラリ「Pellet」を単独で使ってみた。

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置いてくれ。


FlashPlayer11はハードウェアアクセラレーションに対応してない環境でStage3Dを使った.swfを再生すると、SwiftShaderによるソフトウェアレンダリングにフォールバックする。シェーダー含めコードの書き換えが必要ないのでステキな配慮だとは思うんだけど、ぶっちゃけどの程度動くもんなのか見てみたい。とりとめない感じであれこれ迷走してみた。

下記は、描画サイズ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とかのベクターベースなライブリを採用した方が良いケースもまだまだありそうだ。


FlashPlayer11の動作に必要なシステム構成は、http://www.adobe.com/jp/products/flashplayer/tech-specs.html で公開されてるんだけど、Stage3DのGPUアクセラレーションに対応した環境についての明確な情報が見つからない。

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の方は動作実績リストとして一応の意味があると思うので、引き続き情報提供いただけるとうれしいです。


実に1年ぶりのエントリー。自分でもびっくりした。

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

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

※いずれのデモも要FlashPlayer11、さらに再生環境がStage3DのサポートするGPUを搭載している必要があります。GPU非対応の環境では、ソフトウェアレンダリングで再生されますが、その場合何も表示されなかったりブラウザがクラッシュしたりする可能性があります。

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

Stage3D Test01

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

Stage3D Test02

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

Stage3D Test03

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

Stage3D Test04

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

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


MORE