前々回、前回と続いたこのネタも、ようやくネギ振り実装完了（まだやってた）
ねぎミクPV3D改善版ねぎ振り付き（要：FlashPlayer9）
※クリックで振る
腕とネギだけが動けばいいので、特に難しく考えず腕とネギをペアレントした上で、それぞれ rotationX で動かした。Away3DのCORRECT_Z_ORDERレンダラ版は重すぎて、ねぎ振りは断念。
コレを全力で動かすとしたらMD2フォーマットのスキンメッシュ使うのが現実的なのかなぁ。ボーン制御だとメッシュのメリ込み回避とか面倒くさそう。
前回の続き。
元データのままじゃ重いので、mqoインポーター使ってBlenderに読み込んで再編集した。
元データはエッジ表示用のポリゴンが貼られてたんだけど、多少のディテール低下はやむを得ないのでこれを丸ごと削除、さらに目立たない部分をチマチマ削除したりして何とか△987まで減らした。フォルムを殺さずにローポリ化するってのはそれだけでかなりの職人芸だわ。上手い人はもっと少ないポリゴン数で作れるんだろうな。
ローポリ化した後、PV3Dで簡易的にZ-Sortの弱点をカバーするdisplayObject3Dの「meshSort」プロパティを使う為に「髪の毛と上半身」「顔と下半身」を別のノードに分けてCollada出力した。結果は以下。
ねぎミクPV3D改善版（要：FlashPlayer9）
前回と比べてパフォーマンスもちょっと向上、さらに髪の毛のポリゴン欠けはかなり軽減した。meshSortプロパティは、わりと使いどころが難しいけど丁寧にやればもう少しポリゴン欠けを押さえられそうだ。
ポリゴン数を半分以下に減らしたんで、Away3Dでもなんとか動くようになった。
ねぎミクAway3D改善版（要：FlashPlayer9）
とはいえ重いのは変わりない。CORRECT_Z_ORDERレンダラは強力だけど、相当ポリゴン数が少なくないとダメか。Away3DにはmeshSortが無いので、パフォーマンスと品質を両立させた上でこの手のキャラクタを動かしたい場合、モデリングの時点である程度工夫が必要と。PV3DはmeshSortを上手く使うことを心がけるのがコツっぽいな。
はちゅねミクことネギミクをPV3Dで読み込んでみた。
メッシュデータは七葉の保管庫から拝借（作者はズサさん）、ありがたいことでございます。メタセコで作られたデータなので、rch850さんによるMetasequoiaクラスを使ってみた。
あっさりおしまい、かと思ったらMetasequoiaクラスが PV3D1.5用みたいで、PV3D1.7だと使えない。何事も修業ってことで、1.7に対応させてみた。
208行目
var materialName:String; ↓ var materialName:MaterialObject3D;
208行目
var materialName:String; ↓ var materialName:MaterialObject3D;
298行目
materialName = mMaterialNames[parseInt(mstr)]; ↓ materialName = materials.getMaterialByName(mMaterialNames[parseInt(mstr)]);
321行目
face = new Face3D([a, b, c], face.materialName, face.uv); ↓ face = new Face3D([a, b, c], face.material, face.uv);
331行目
materialName = mMaterialNames[parseInt(mstr)]; ↓ materialName = materials.getMaterialByName(mMaterialNames[parseInt(mstr)]);
あと、これまでPV3D触ってきた経験上
162行目の
material.doubleSided = true;
はコメントアウトした。doubleSidedプロパティは基本的にfalseで、どーしても必要な場合のみtrueが無難、ってのがオレの考え。
以上でめでたくPV3D1.7で使えるようになった。メタセコ派のPapervisionalistはお試しあれ。
Face3Dの仕様変更が原因なので1.5と1.7両対応ってのは面倒そう。
以下が結果。
ネギミクPV3D版（要：FlashPlayer9）
うーん。重いのはまぁしょーがないとして、左右が反転してるのは何で？Metasequoiaクラスの改造がマズかったかな。
07/11/12追記：
↑の疑問を太郎日記’79Jさんが見事に解決してくださいました。つーか、自分で調べた座標系の事をスッポリ忘れて何というイノセントな感想を語っているのかオレ…orz。
それよかやっぱり複雑なメッシュだとポリゴン欠けが目立つなぁー。Z-Sortなんとかなんねーのか。
とかなんとか、ひとしきりグチったとこでポリゴン欠けが円形脱毛症に見えてしょーがねーのでついカッとなって、MetasequoiaクラスをAway3D用に移植、CORRECT_Z_ORDERレンダラ使ってやってみた。
ネギミクAway3D版（要：FlashPlayer9）※デンジャラス重いです
おげぇー！重いーっつーか動いてねぇ（笑）ポリゴン欠けはウソみたいに無くなったけど…ねぇ。CORRECT_Z_ORDERレンダラって重いんだなぁ。これじゃネギ振るなんてムリだ。
mqoから一旦Blenderにコンバートして、もっとローポリ化しないとダメか。
Metasequoiaクラス移植した意味無ぇなぁ（笑）とりあえず面白かったけど。
追記：
太郎日記’79Jさんとネタかぶった…orz。
しかもつい2時間前のエントリ。でもむしろ同志がいてくれてウレシイ。
faceVisible.swf（要：FlashPlayer9）
前にPV3Dでやろうとして出来なかったことが、Away3Dだとアッサリ出来た。
Object3D.faces[0].visible = false;（or true）
で、Face毎に表示／非表示できる。
現時点（Beta1.7）のPV3Dだと、Face3Dのvisibleプロパティが read-only なので、こういうことが出来ない。わりと使いたいケースがありそうなもんだけど。
PV3Dにも参加してるTim Knip氏が開発中のASCOLLADAで、GoogleSketchUpからエクスポートしたkmzファイルに含まれるdaeファイルを、比較的まともにPV3Dで読めるようになってたので忘れないようにメモ。
使ったPV3Dのリビジョンはrev.243。
ASCOLLADA自体は、svnから落とす。
http://ascollada.googlecode.com/svn/as3/
（前述のTim氏によるエントリに記載されてるURLは古いので注意）
PV3DでASCOLLADAを使う場合は、上記svnからpapervision3d拡張用のクラスファイルも全て落とした上で、それぞれ所定のディレクトリに置く。
Googleの3DWareHouseから適当なデータの「Google Earth形式（.kmz）」を落とす。オレの場合は、Corn Exchange National Bankを落とした。
.kmzファイルの実態はzip形式のアーカイブなので、拡張子を.zipに書き換えるとかして展開。中には
が入ってるので、modelsフォルダ内のdaeファイルをPV3Dで読み込めばよし。
Tim氏のエントリにあるように
var dae:DAE = new DAE( “somedae.dae” ); scene.addChild( dae );
とかやればいい。
注意点として、GoogleSketchUpでテクスチャをタイリング処理してあることが多いので、それに対処するためには、MaterialObjectのtiledプロパティを「true」にする必要がある。面倒な場合は、org/papervision3d/core/proto/
MaterialObject3D.asの79行目を
public var tiled :Boolean = true;
に書き換えておく。デフォルトは「false」なので必要ない時は戻したほうがいいかも。
結果は以下の通り。
obj_Collada.swf（要：FlashPlayer9）
手ぇ抜いてマテリアルをデフォルトのままにしたもんだから、テクスチャ歪みまくり。
PreciseBitmapMaterialで設定し直したほうが美しいだろうな…かなりめんどくさいけど。
今回は出来あいのkmzからdaeを拝借したけど、GoogleSketchUpで作った形状をkmzでエクスポートしても多分読めると思う。ただ、GoogleWareHouseで公開されてるデータが全部まともに読めるわけではないので、何かの機能を使うことでASCOLLADAで読めないものになるみたいだ。この辺は要調査。
とはいえ、そこそこ使えそう。これで貧乏人のためのモデリングツールがまたひとつ増えたかな？
mtfuji.swf（要：FlashPlayer9 結構重いです。）
以前作った富士山、もうちょっと広域表示できないもんかと色々調べてて、Blenderの機能に「モディファイアシステム」ってのがあるのを発見。ついでにバージョンが2.45になってたのでアップグレードしつつ、Decimate モディファイアを使って、SRTM-DEMからコンバートしたメッシュをローポリ化。大幅に広域表示しつつフェイス数は前回と同じくらいにできた。地形データはメッシュの構造が単純だからこういうのがスゲー利くなぁ。とはいえやっぱり重いことには変わりない。頻繁に一瞬止まるのはGCなのかな。
今回は、ライトを試したくてAway3Dを使ってみたけど、Bitmap系のマテリアルには白色でのライティングしかできないことが判明してガックシ。これみたいに朝、昼、夕の変化させたかったのにー。久々にAway3Dにちょっかい出したら、随分仕様が変わってたので前に晒したソースを直した。
自分が慣れてきたせいなのか、Away3D使いやすくなった気がする。PV3DはsvnのPhunkyブランチでガンガン開発が進んでいるものの、メジャーリリース遠そうだし結構な仕様変更ありそうだし、しばらくAway3Dで遊んでみようかな。SandyもAS3版が出たみたいなので試してみたいな。サンプル見る限りだとSandyのほうがPV3D系よりnear clippingが上手く実装されてるような気がするし。（気のせいかもしんないけど）
