前回、
PNG画像の透過判定はメンドイのでとりあえずやらない
みたいなこと書きましたが、
バイナリデータとして改めて読み込んで
PNG形式に則って解析すればイイんじゃね？
と気づきました(^_^;)
同じファイルを２回読むことになってしまいますが、
画像として読み込んだ後にやれば、
ブラウザ側でキャッシュされてるはずだから速度的にも気にならないだろうし。
そんなわけでアッサリとJavaScriptで透過判定できました。
ちなみに判定方法はこちらを参考にしました。
ついでに今回は、
BDEF4にも対応してみました。
MMDのPMX形式では、
ボーン変形による頂点blendingとして、
BDEF1,BDEF2,BDEF4,SDEFの４つをサポートしていますが、
今まではいずれもBDEF2として扱っていました。
three.js(r58)でサポートしていたのが２ボーン（つまりBDEF2）だったので、
それに沿うように実装していたためです。
ただ内部的には４ボーンまでのデータ領域は確保されており、
そのうちの２つを使うようになっていました。
（※three.js(r66)では４ボーンをサポートしたようです）
従来の実装では、
BDEF1 -> ２つめのボーンの参照インデクスと重みをゼロにすることで、BDEF2へ変換。
BDEF2 -> そのままBDEF2として扱う。
BDEF4 -> 重みの大きい方から２つを選び、重みの合計を1.0に正規化することで、BDEF2へ変換。
SDEF -> SDEF固有部分を無視することで、BDEF2相当として扱う。
だったのが、
今回の実装では、
BDEF1,2,4 -> フラグ判定によりそれぞれ純粋に1,2,4ボーンによる変形として扱う。
SDEF -> SDEF固有部分を無視することで、BDEF2相当として扱う。
と変えました。
判定用のフラグとしての頂点属性を追加するのが素直な実装になるのですが、
その分のメモリが余計に必要になったりします。
頂点数が数万個とかになったりすることもあるので結構バカにならないのです。
そこで、ボーンの参照インデクスが必ずゼロ以上になることを利用して、
負数なデータを埋め込むことで、
属性を追加することなくできるように実装を工夫しました。
シェーダーレベルでの改良なので、
場合によっては以前より速度の向上も期待できるかもしれません。
なお、
BDEF4の動作はテストで一応確認済みなのですが、
テストで使ったデータファイルのサイズが大きいため、
今回はテスト動作の公開はありません。
ローディング時間があまりにも長くなりそうなので、やめました。
ここのサーバー、最近なんか重いし変だし・・・(^_^;)
WebGL的にもメモリが厳しくなりそうだし。
BDEF4を使用したほどよいサイズのPMXがあるとよいのですが。
ということで、
変更は前回の方に適用しておきましたので、そちらを参照してください。
といっても内部的な改良なので、見た目には変わっていませんが(^_^;)