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

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

tkinjoさんが、wonderflに投稿されたコードを見て。

sceneの原点（0, 0, 0）にターゲット指定したカメラを x=0, y=1000, z=0 のように、ワールド座標のY軸線上に配置すると何も表示されなくなる。
回避策として、tkinjoさんも採用している x, y座標を0にしないってのが一番ラクチン。
x=0, y=1000, z=-0.1 とか x=0.01, y=1000, z=-0.05 とかを指定する方法。
ただし、x軸、z軸のどっちを使ってY軸からずらすかによって結果が異なる。また数値の±によっても結果が異なる点に注意。大抵はz軸にマイナスの値を入れるといいんじゃないかと。

別の方法として、カメラのターゲット指定をせずに

camera.target = null;
camera.x = 0;
camera.y = 1000;
camera.z = 0;
camera.rotationX = 90;

という設定で同じ状況にした場合も、問題を回避できる。

にしても、なんでなんだぜ？
今まで何が原因なのかをちゃんと調べてなかったので、この機会に調べてみた。
多分、随分前に遭遇したこのトラブルとも関連がありそう。

カメラにターゲット指定しなけりゃ問題ねーってことなんで、lookAt メソッドが怪しいと睨んで DisplayObject3D.lookAt の該当部分を見てみると、

［1］まず、目標にカメラを向けた時のz軸ベクトルを、ターゲットの位置ベクトルからカメラの位置ベクトルから減算して正規化。

_zAxis.copyFrom(_lookatTarget);
_zAxis.minusEq(_position);
_zAxis.normalize();

［2］1で求めたカメラの正規化されたz軸ベクトルと、カメラのupperベクトル（通常は Number3D(0, 1, 0) ）との外積をとって、x軸ベクトルを求める。

if( _zAxis.modulo > 0.1 )
    {
        _xAxis = Number3D.cross( _zAxis, upAxis || UP, _xAxis );
        _xAxis.normalize();

［3］1で求めたz軸ベクトルと、2で求めたx軸ベクトルの外積をとって、y軸のベクトルを求める。

        _yAxis = Number3D.cross( _zAxis, _xAxis, _yAxis );
        _yAxis.normalize();

こんな手順でカメラとターゲットとの位置関係を元に、カメラの姿勢を決めてる模様。

この方法だと、x=0, y=1000, z=0 にカメラがある場合、_zAxisが Number3D (0, 1, 0) になる。
こうなると _xAxisを求める際に外積を取るための、カメラのupperベクトル：Number3D (0, 1, 0) と平行になる。平行なベクトルの外積の大きさはゼロなので、_xAxis は Number3D (0, 0, 0)。
最後の_yAxis は _xAxis との外積だから、_yAxisも Number3D (0, 0, 0)。
って感じでz軸以外がゼロベクトルになっちゃって、カメラの姿勢が定まらない。結果、何も表示されないということみたいだ。これっていわゆるジンバルロックなのか？
むー。PV3Dサイドとしては、これは仕様だということにしてるんだろうか？

なんかアホっぽい方法で回避できそうな気がしたのでやってみた。
DisplayObject3Dの1213行目辺りから

            _zAxis.copyFrom(_lookatTarget);
            _zAxis.minusEq(_position);
            _zAxis.normalize();

            if( _zAxis.modulo > 0.1 )
            {
                _xAxis = Number3D.cross( _zAxis, upAxis || UP, _xAxis );
                _xAxis.normalize();

                _yAxis = Number3D.cross( _zAxis, _xAxis, _yAxis );
                _yAxis.normalize();

という部分を以下に書き換え。

            _zAxis.copyFrom(_lookatTarget);
            _zAxis.minusEq(_position);
           _zAxis.normalize();

           if( _zAxis.modulo > 0.1 )
            {
                _xAxis = Number3D.cross( _zAxis, upAxis || UP, _xAxis );
                _xAxis.normalize();

                if(_xAxis.x == 0 && _xAxis.y == 0 && _xAxis.z == 0)
                {
                    _yAxis = Number3D.cross( _zAxis, RIGHT, _yAxis );
                    _yAxis.normalize();

                    var tempYAxis:Number3D = new Number3D(-_yAxis.x, -_yAxis.y, -_yAxis.z);
                    _xAxis = Number3D.cross( _zAxis, tempYAxis, _xAxis );
                    _xAxis.normalize();
                }
                else
                {
                    _yAxis = Number3D.cross( _zAxis, _xAxis, _yAxis );
                    _yAxis.normalize();
                }

特異点でlookAtする場合のみ、_yAxisを先に求めるようにしたので、カメラが x=0, y=1000, z=0に配置された場合もそれっぽく表示されるようになる。強制的にLEFTベクトルとの外積を取るようにしちゃったので、カメラがアニメーションしてる場合、おかしな挙動になるケースもあるかもしれない力業。
それでも何にも表示されないよりはマシかなぁ。もうひとひねりしてクォータニオン使う方法も考えてみたい。

09/06/15追記：tkinjoさんのご指摘を受けてコード修正。
やっつけ気味なのは変わらず；

daeAnimation（要：FlashPlayer9）

[↑] … 前進（move forward）
[←] [→] … 方向変える（turn left/right）

Papervision2.1 Alpha 公開で、鬼門だったDAE周りが改善されたということで使ってみた。
http://techblog.floorplanner.com/2009/05/26/papervision3d-21-alpha/

BlenderでArmature使ったスキンメッシュをColladaでエクスポートしたものがようやく動くようになった。3dsMAXとかMaya使わない限り不可能かと思ってたけど、どうにか使えそう。Away3Dでもなんとか動いてたけど、ボーンのモーションにtranslateが含まれてると破綻したりして不完全な感じだったのが、PV3D2.1のほうが格段にマトモだ。

上のデモは、KYUCON*BLOGさんで紹介されているAnimationClip3Dを使う方法で静止状態と、歩行中のアニメーションを切り替えて再生してる。スタート・エンドポイントの指定がフレーム単位でもできればいいのになぁ…なんか歩行モーションのループ部分がぎこちない。Blender上だと綺麗につながるんだけどな。

Colladaの仕様的には、animationChannelを定義できるはずなので、Blenderでアニメーションセットを複数定義した上で正常に書き出しができればもっと楽ができそうな、ほのかで甘酸っぱい期待を持ったんだけど、Blenderで複数のアニメーションセットを定義する方法がわかんなくて一旦保留。

こうなってくると、アニメーション切り替え時にモーションブレンドしたい。それは自前で実装するしかねーだろうなー。