気になったニュースとかいろいろ。

プログラミングの話ばかりしていても肩がこるので、たまには別の話題を。
（とはいえ、プログラミングの話題を上げている方がアクセス数がいいんだよな。）

のはらしんのすけ義塾大学というのが開校したそうで。
新手のSNSやネットゲームかと思いきや、公式のサイトに広告らしいものが配置されているわけでもなく……。
ドメインも中途半端だし（edu904って、エデュケーションくれよんのつもりだろうか？大学なら、アカデミーじゃないの？）、一体何がしたいんだろうか？
まぁ、開校って記述があるから、今後会員を集めてなんかやろうっていうのは目に見えてるわな。

んで、これに絡んでサービスを提供してる会社が気になったんで調べてみたら、パチンコとか小規模なネットゲームを配信している企業だそうな。
資本金1000万で社員75名って……。大丈夫なんだろうか？

社長の岡村隆って名前も、ナインティナ○ンか！？と思ってしまった（笑）


のはらしんのすけ義塾大学が、今後新しいタイプのネットワークサービスに成長したら面白いなと思うので、ここに書いておこう。

ただ気になるのが、大学という名称。
これって、学校法人法（私立学校法とかいうのかな？）とかに引っかからないんだろうか？
学校法人名乗ってないから大丈夫なのか？
それとも、ウェブサービスは法の及ばない範囲？
（もし詳しい方が居たら、そのへんおしえてぷりーず。）

---

そして、プログラミングの話題以外といいつつ、プログラミングの話題を（笑）
テクスチャの張り込みに関してだけど、TSXVertex**というクラスを用いてテクスチャの貼り付け情報を管理してやれば、問題なくテクスチャを張れそうな感じがしてきた。
というのも、SXLib9.pasをのぞいてみたら、SX形式の解説があって、

    名称   | オフセット   | サイズ | 備考
----------------------------------------------------------------------------
 Signature |            0 |     16 | 'Simplified_X02  '
 nVextices |           16 |      2 | 頂点の数
 nIndices  |           18 |      2 | 頂点数のインデックス数
 dwFVF     |           20 |      4 | フレキシブル頂点フォーマットのフラグ
 VertexSize|           24 |      4 | 1頂点当たり何バイト必要とするか
 DXVersion |           28 |      4 | DirectXのバージョン(FVFの識別用)
.
.
.
 (中身)
.
.
.
    名称   | オフセット   | サイズ                  | 備考
---------------------------------------------------------------------------------
 Vertices  |          256 |  VertexSize * nVertices | 頂点
 Indices   | 256+Vertices |           2 * nIndices  | 頂点のインデックス

というのがSXファイルのフォーマットらしいから。
ここから読み取るに、テクスチャのマッピング情報は一切含まれていない。
だから、テクスチャのマッピング情報は別物だと考えていいのかもしれない。
（という考えから行けば、先日ラグナロクキャラクターのモデルできちんとテクスチャが貼れたのは偶然ということか？→ROKファイルのようにフレーム分割されているものではなく、シングルオブジェクトとして読み込んでいたからではないだろうか？）

というわけで、テクスチャ貼りに関しては振り出しに戻りました（笑）

それから、P3D形式のデータをQuadrupleDがどうやって動かしているかを考察してみた（またソース読んでない）んだけれども、単純にフレームごとにメッシュを読み込んで、フレームの位置と姿勢をP3Dの指示に従って動かしているだけなんだろうという結論に至った。

これはどういうことかと言えば、フレームを動かすだけだから実装は楽だろうけれども、ボーンアニメーションのようなアニメーションはできないよってこと。

これに対してモーション付きXファイルが想定しているのはボーンアニメーションだったから、そもそも相いれないものだったという認識でいいんじゃなかろうか？

書いててよくわからなくなってきたけど、アニメーションについては自前で実装するのも可能かもしれないという、光明的なものが見えてきたというだけのことです。

自前でアニメーションを実装したときにうれしいことは、六角大王フリー以外のXファイル書き出し対応3Dモデラによって3次元オブジェクトを作り出せることだろうな。

六角大王フリーで十分な私にとって見たら、さほど重要なことじゃないから、おそらく実装はしないだろう。
テクスチャのマッピングに関する情報はSXファイルに含まれていないことがわかったわけだし。

フリー版でモデルデータを作成したときに困る点と、それに対する対処法、それからテクスチャの情報について。

昨日話題に上げたことの続き。

……と書きつつ、まずは昨日と関係ない話題に関することから。

六角大王フリー版は、ご存じのとおり左右対称のオブジェクトしか書き出せない。
でも、これだと片手に剣を持って、もう片方の手に盾を人とか、そういうオブジェクトを描画させることができない。
（武器グラフィックの変更とか、別のメッシュファイルを読みに行くという解決法もあるだろうけど、町の兵士とかはひとつのファイルになっているにこしたことはないだろうから。）

んで、これに対する解決策。
結構六角大王な人には常識なのかもしれないけどね。
左右のうち、いらない方の面を削除するっていう方法。

たとえば後半に紹介する画像は、その方法で剣を片手だけにしてある。
元はメタセコイアのデータで、それを3DAceで読み込み→左右対称にしてROKで書き出し→片手だけ剣の面を削除という手順でやっている。
（正直、結構手間がかかった。モーションまでお手軽にできるのはいいけど、やっぱりヘルパー関数をQuadrupleDと一緒にウマーくつかえる方法を模索した方が、結果的に労力の低減につながるかもしれないと考え中。）

まぁ、他に方法が見つからなければ、こんな方法を駆使する手もあるってことで。

---

さて、そんでもって昨日の続き。
テクスチャ情報を持たないメッシュファイルを読ませて表示させるとどうなるか？
答えば図のようになる。
これは、先日メタセコイアからXファイルとして出力→QuadrupleDを使って表示という作業を行ったのと同じモデル（実際には、ROK形式に返還後、先述した加工を施してある。）

ともかく、メタセコイアの時点では保持していたテクスチャのマッピング情報が失われたために、同じテクスチャを指定してもこんな結果になってしまったんだと思われる。

---

以上のことについて、解決策として思いついたものをメモ。
どれもたいへんそうなのに変わりないけど、時間のあるうちにこういうことを楽しんでやるっていうのも良いのかもしれない。

アイディア１．
Xファイルを扱えばいいわけだから、やっぱりJEDIのヘッダーを引っ張ってきて、QuadrupleDと組み合わせて利用できる方法を模索する。
これだと、SXには頼れなくなるから、レンダリングまわりも自分で制御しないといけなくなるのが一番の問題になるかな？
あ、テクスチャに関しても、TDGTextureという優れたクラスを利用できなくなるのか。

アイディア２．
メタセコイアのデータを利用したいわけだから、それを直接利用できればいいという見方もできる。
じゃあ、メタセコイアのアニメーションデータを扱える、Mikoto向けにコンバータを書けばいいんじゃないだろうか？
＝＞Mikotoのファイルフォーマットに関する資料が少なすぎて、アイディア１以上に骨が折れそう

アイディア３．
アニメーションX→P3Dデータへのコンバータを書けば問題解決？
先日の、モデルはXファイルで、アニメはP3Dでっていうのと同じ話だな。
あるいはSX形式そのものを拡張した独自形式を定義するのもどうだろうと思う。
（SX形式のファイルをひとまとめにして、それをメッシュリストとして扱えるような感じか？）
独自形式に拡張しても、アニメーションデータはP3Dを使えばいいんじゃなかろうか？

なんにせよ、モーション付き3Dっていうのは結構大変そうだ。
いっそのこと、QuadrupleDを捨てて、JEDIのライブラリあたりを経由して、DirectXを直接たたく方が手軽にできるんじゃないかとすら思えてくるね（笑）

それも一回やってみて、それから判断しても……。

なんでめんどいか？っていうのと、その他の話題。

先のエントリで勝手に結論：とか出してたから、なんでメンドイのかを一筆。

実は、SXファイルの取り扱いについて調べていたところ、DirectXのサンプルプログラムではおなじみのイルカのモデルをDelphi＋QuadrupleDで作ってみましたという人の記事を発見。（こちら）

そこによると、形状ごとのモデルを用意する→頂点をブレンドしてアニメーションさせるという手順でアニメーションをさせていたのだ。

これは単純に、アニメーションのパターン数×1パターンで使うアクションの枚数分のファイルが必要になり、六角大王＋HumanMDLの「ROKファイルとP3Dファイルを用意すれば、アニメーションできるザマスわよ。」という状況とはあまりにもかけ離れてくる――そう読んだからだ。

さらに、アニメーションのパターンによっては頂点のブレンド方法を変えなくちゃいけないことが予測される。ということは、とてもお手軽アニメーションとかいうわけにはいかなそうなのである。

---

だけど、後半で書いたP3DファイルがあればSXメッシュだけでもアニメーションできるんじゃないだろうか？
という疑問はかなりいい線行ってそうな感じがする。

P3Dファイルを扱うプログラムを実装した段階で気付いたと思うけど、P3DFigureの作成において、メッシュリストを引数として受け取るSpawnメソッドを利用していたからだ。

メッシュリストを引数として受け取るってことは、それが六角大王のファイルである必要はないということだろう。
つまりこれは、ほかのモデラを利用できるってことなんじゃないだろうか？
（まだ試していないから、今後の課題としてやってみようと思う。）

---

もし六角大王以外のモデラが使えると何が嬉しいか？
一番うれしいのは、テクスチャのマッピング情報をメッシュに持たせることが可能だということなんじゃないだろうか。
SXファイルのフォーマットについて詳しく調べていないから確かなことは言えないけど、少なくとも六角大王フリー版ではモデルにテクスチャを貼り付けることができないと聞いた。

けれど、六角大王で作られたデータはQuadrupleDの管理下に入った時点でSX形式に直されているハズなので、テクスチャを貼り付けることが可能だ。（テクスチャが貼れることは確認済み）

テクスチャが貼れるということは、テクスチャは何らかのマッピング指令に基づいてマッピングされているんじゃないだろうかと。そう考えたわけである。
（たとえば、メタセコイアだとUVマッピングによってマッピング情報をモデルに持たせることができる）

六角大王ではマッピングの情報をモデルに埋め込めていないわけだから、なんらかのデフォルトマッピングというのが定義されているのは間違いないんじゃないかと。そういう結論に至ったのだ。

テクスチャが貼れると、キャラに表情をつけたり、服の細かい模様を3Dで描かなくてもよくなる。
これは、多少規模の大きい3Dのゲームを作るなら便利な機能なんだろう。
同じ形の家だけど、テクスチャが違うから別の家に感じさせることができるとか。
（家の場合、アニメーションしなくても良いから、別に六角大王にこだわる必要は無いんだけどね。）

---

以上を踏まえてのとりあえずの結論は、SX形式に対応したポリゴンモデラがあればいいじゃん。
ついでだから、HumanMDLの形式でアニメーションつけられるようにしてさ。

ふぅ。

要するに、今あるものを使うのが一番楽だよってこと。
でも、話題自体は面白いからもう少し追いかけてみるかな。

結論：標準で提供されているのを使うのが楽。

昨晩考えたことについては、表題のような結論に達しました（笑）

さて、そんなわけで今日は六角大王のモデルデータを動かしてみるという話。

コードは昨日のを流用するとして、どこかからP3D形式（HumanMDLで作られたモーションデータ）のファイルをゲットしてこなきゃなりません。

が。

いつもどおりCypherS TufTさんにはこの条件に合致するデータが存在するので、今日もそCypherS TufTさんのお世話になります。
（いずれ、きちんとお礼をせねば。。。）

はてさて、こうしてデータが準備出来たら、一応HumanMDLでどんなモーションがあって、どんな動きをするのか確認しておいた方がいいでしょう。

この先読んでいただければわかりますけど、今回はモーション番号2番、全部で4フレーム時間あるアニメーションをさせるつもりでいます。

インデックスは0から始まるわけですから、HumanMDLで確認できるモーション、ジャンプ2と同じ動作をすれば、うまくいったと言えるわけですな。

そんなわけでさっそくコーディング。
まずはuses節にP3DLoaderユニットを追加して、TP3D, TP3DFigureオブジェクトを準備しますよ。

uses
...ROKLoader, P3DLoader;
.
.
.
ROKMesh: TSXMeshList;
P3DData: TP3D;
Motion: TP3DFigure;
.
.

こんな感じで。

んで、TP3Dオブジェクトを作成して、P3Dデータを読み込みマウス。

P3DData := TP3D.Create;
P3DData.LoadFromFile( 'jump.p3d' );

したらば、先に読み込んでおいた六角大王データと組み合わせて、P3DFigureオブジェクトを作ってもらいます。

Motion := P3DData.Spawn( ROKMesh, MeshFrame );

Spawnの引数は、六角大王のデータと、親になるフレームですよ。そこんとこお間違いなく。
当然、こうやってメッシュデータを取り出せるわけだから、昨日やったfor文による小手先のテクニックは不要になるわけだ。

あとは、Scene.Render( Root );する前に、

Motion.Move( 2, AnimationCounter );

とかすれば動き出してくれる。

ここでAnimationCounterはSingle型の変数で、表示するべき時間を表す変数。
Application.Idleが、50FPSだとだいたい20回/sぐらいの回数呼び出されるはずだから、極端に小さいとめちゃめちゃスローなアニメーションになる（当然、動きもなめらかになる）し、かといって大きいとやたらと素早く動く（すごく気持ち悪い）アニメーションになる。（さらには、動きがカクカクになる。）

増分の数値はお好みで。
まぁ、AnimationCounter := AnimationCounter + 0.01;ぐらいが丁度いいんじゃなかろうか？

あ、アニメーションは4フレームまでしかないと考えているから、

if AnimationCounter > 4.0 then
        AnimationCounter := 0.0;

とかして、増分後にリセットしとくのを忘れずに。

忘れずにといえば、オブジェクトの解放もForm.CloseQueryあたりでこなしとくといいと思うよ。

さ、だんだんおもしろくなってきたぞ。

画像は静止してるけど、実際には画面内を回転しながらぴょこぴょこ動いてます（笑）
回転じゃなく、キーボードの指示に合わせて画面内を移動するとかさせたら、もう3次元空間を歩き回るアプリケーションは出来上がりになるわけか。

つくづくQuadrupleDの強力さには驚かされるね。

疑問山積

眠いので、明日のためにメモと考えのまとめ。

これまでは六角大王のデータを読み込んで、HumanMDL（関係ないけど、マツド・サイエンス研究所で検索したら、最新版の配布ページにたどり着けた）でモーションデータを作成→QuadrupleD経由で読んで動かすっていう手法で3次元のアニメーションがいけるもんだと思ってたけど、リファレンスを読んでみたら形状データとモーションデータは分離して考えていいらしい。

つまり、同じ動きをしするけど違うモデリングを施されたモデルがあっても対処できますよってこと。

で、ここの部分について考察してみると、結局TSXMeshはROKデータをSXデータに変換して扱っているのではないかということ。（現時点ではソースとか読んでないから、確証は持ててない。）

従って、形状データは六角大王を使うのが簡単だけど、別に六角大王で作る必要はないんじゃないかってこと。
動きさえきちんとすれば、メタセコイアあたりでモデリング→Xファイルで出力→SXに変換して利用でも行けるんじゃないだろうかと。そう思ったわけです。

ただ、このときにはひと手間が必要で、六角大王でいうところのグループのように、Xファイルを分割しておく必要があるんじゃないかなぁ？と。
たとえば頭、腕、胴体、足からなるモデルなら、六角大王ではそれぞれをグループにすればいいけど、変換して使ってく方法では4つのXファイルとSXファイルを用意しないといけないんだろうなぁと思ったけわけです。
どうせメッシュリストに放りこんでしまえば、なんだろうと変わりないんだろうし。

となると、大まかなアクションをしてくれるP3Dファイルを六角大王のダミー人形クンデータかなんかで作成して、そのサイズに合わせて細かくモデリングしたポリゴンモデルを利用すれば、ふつくしい3次元モデルのアニメーションができるんじゃないの？と。そんな風に思うわけです。

まとめ

・六角大王でモーション用ダミーデータを作成→HumanMDLでモーションデータをつける
・メタセコイア等でポリゴンモデルを作成→動かしたいパーツごとにX形式で出力→それぞれをSX形式に変換
・SX形式に変換したモデルを読み込み→HumanMDLで作ったモーションデータを読み込み→QuadrupleDの力を借りて合体させる→こいつ…動くぞ！！→わー、はっぴーはっぴー。

問題になりそうなこと

・P3Dファイルには、読み込むべき六角大王ファイルの指定がされていないのか？
・読み込むべき六角大王ファイルが指定されていた場合、QuadrupleD上から使うにおいて問題はないのか？
・別々に読み込んで利用した場合、それぞれが連携してアニメーションしてくれるんだろうか？
・そもそも、内部的にSX形式に変換されているという読みが間違っていないのか？

うーん。
考えをまとめるつもりでエントリ起こしてみたけど、まとまらないなぁ。

まぁいいや。眠たいから、残りは明日の自分に任せよう。

---

どうでもいいけど今日から9月1日だ。
福田首相辞任とか、9月草々すぎる。
総選挙近いのかな？
次は麻生さん？
日本がよくなるならどうでもいいけど。


あ、カレンダーめくらなきゃ。

QuadrupleDで六角大王の形状データを表示する方法だと思うよぉ。

そんなわけで、とりあえず形状データを読み込めたので報告。
というかメモ。

基本的なソースはチュートリアルのポリゴンモデルを表示してみようというやつ。
んで、使った3次元モデルのデータは、例によってCypherS TufTさんより拝借。
六角大王のデータまで公開してらっしゃるとは、実にすばらしい。

さて、六角大王のデータが用意できたら、チュートリアルのソースを改造する。
まずはuses節に

uses
...., D3D9, SXLib9, s_mathpack, ROKLoader

というように、ROKLoaderユニットを加えておく。

これで六角大王の形状データを読めるようになる。

当然、チュートリアルでTSXMesh型として定義されていた部分は必要ないので削除。
代わりに

ROKMesh: TSXMeshList; //六角大王形状データ

な感じでTSXMeshList型のオブジェクトを準備しておく。

これは、六角大王のメッシュデータがグループという単位にわかれているからと理解した。
このグループという単位でHumanMDLを用いてアニメーションをつけることができる。
んで、QuadrupleDではそのグループをメッシュという単位に置き換えて扱うわけだ。
さらに複数のグループでひとつのROKファイルを構成しているから、ROKファイルからの読み込み→メッシュのリストとして考えるという発想に至ったと思われる。

さて、ROKデータの読み込みだけれども、これはいたって簡単。
先ほどの続きとして考えると、

// 形状データの読み込み
ROKMesh := TSXMeshList.Create( DG );
ROKLoadFromFile( DG, 'junp.rok', ROKMesh, 60.0 );

ってな具合になる。
ROKLoadFromFile手続きは、ROKLoaderユニットに定義されている手続きで、第二引数に指定されたファイルを読み込んでTSXMeshListデータとして第三引数に格納するというもの。
内容はクリアされてしまうものの、第三引数に渡すオブジェクトはインスタンス化されている必要があることに注意。

こうして読み込みまで出来れば、「あとはメッシュのデータを格納するフレームを

MeshFrame: TSXFrame;

てな要領で準備して、そこのMeshプロパティに放り込めばいいんですね。わかります。」
と思ったあなた。それは早計だ。

なぜならTSXFrameのMeshプロパティは、TSXMeshのデータしか格納できないから。
そう、TSXMeshListのデータは格納できないのだ。

そこでどうするか？
考えた結果、私は次のような方法をとった。

まず、QuadrupleDにおいて、フレームというのは「親フレーム→子フレーム→孫フレーム→...」というような感じに階層構造をもっている。
そして、一つのフレームにつき、一つのメッシュを保持することができるわけだ。
さらに描画のときには、親フレームから末代のフレームまで辿って描画をしてくれる。
（少なくともチュートリアルの実装では）

ということは、先のように用意したMeshFrameの子孫フレームに、ROKファイル内に存在する各グループをメッシュとして保持してもらえばいいわけだ。
簡単な図にすると

MeshFrame
┣（しっぽの形状データ）
┣（あたまの形状データ）
┣（腕の形状データ）
・
・
・

という具合だ。
こうすることで、MeshFrameがMeshListを保持しているように考えることができる。

で、それを実現するために次のようなコードを書いた。

for i := 0 to ROKMesh.Count-1 do begin
    TSXFrame.Create( MeshFrame ).Mesh := ROKMesh.Meshes[i];
end;

Delphiがオブジェクト指向言語だから可能な記述方法であって、さらにTSXFrameがインスタンスを作成するときに親フレームオブジェクトを要求するという構造だからこそ可能な芸当かもしれないが、こうして読み込んでおくことで、描画の際のコードはチュートリアルから一切手を加えなくとも、きちんと3次元モデルを表示することができる。

画像はこの方法で読み込んだROKデータ。

3Dは面倒なことが多いね。

DirectX+Delphiで楽しもうと、QuadrupleDを導入してごにょごにょしちょるわけですが、さっそく壁にぶち当たりました。

というのも、QuadrupleDがチュートリアルでも使っているSXという（簡略化されたX形式みたいなもの）、3次元形状データのファイルは、シンプルという名前だけあってモーション付きXファイルは取り扱ってくれないようなのです。

メタセコイア+RoKDeBone2でモーション付きXファイルを作成してウキウキしてた私にとっては、これはなんとも苦い現実でございますことよ。

いろいろ調べて、JEDIが（ここでもジェダイの騎士か！）過去にDirectX9のヘッダーを変換していたらしいことを突き止め、それを利用すれば（正確には、そこに含まれるヘルパー関数をおさめたヘッダを利用すれば）いけそうだというところまで来ました。

が！ここでひとつ重要な問題が。
それは、JEDIによるっぽいDirectXヘッダーを利用するなら、QuadrupleDの恩恵はあんまり受けられないんじゃないかってこと。
（調べていくうち、せいぜい、Direct3Dオブジェクトの作成程度しか恩恵にあずかれないだろうという考えに行きつきました）

本格的にやるなら断然こっち（JEDI）なんだろうけど、とりあえず目先の問題として、お手軽にやりたいっていうのがあるからなぁ。
と思っていると、ここで救世主が。

どうやらQuadrupleDは六角大王フリーの形状データと、それを元にHumanMDLでつけたモーションデータを取り扱える様子。

そうか。モーションデータを取り扱うには、こっちを利用しなくてはいけないわけか…。

そんなわけで、現在はそちらを調べつつ試行錯誤中。