9.24.2008

有限ぷちぷち

モデルが透けるという問題、いっこうに解決しない。
テクスチャを張らないモデルだと、透けているような感じはないので、テクスチャに問題があるものだと思っていた。

んで、QDに頼っていたテクスチャ関連の部分を、ごっそり自前のものに差し替えてみた。
だけど、やっぱりモデルは透ける。
そりゃもう、スケスケだ。

だもんだから、これはテクスチャの問題じゃなく、表示周りの問題か、マテリアルの問題だと思う。
トラだと透けないから、アニメーションを内包しているモデルに固有の問題なのかもしれない。

あるいは、DDS→BMPに無理やり変換した画像ファイルを使っているからだろうか?
なぞは深まるばかり。

作業は進まない。

9.23.2008

やはり問題がみえてくる。

アニメーションに手をつけようと、さっそくDirectXのサンプルに入っているTinyを連れてきた。
が、このTinyに絡んでいくつかの問題が発生。

問題1.Tinyの座標軸が、トラさんと違う
→タイガーさんの表示に使っていた方法だと、Tinyの表示がおかしい。
→例の画像でも、Tinyは横回転をしている。(これでも調整した後の画像)

問題2.テクスチャがDDS形式だった
→すっかり頭になかったけど、そういえばこんな形式もあったなと。
→んで、これをQDのテクスチャクラスで読んだら、読み込んでくれませんでした(笑)
→結果、DDS→BMPコンバートという方法をとって対処したものの
→テクスチャクラスは新たに作る必要がありそう。

問題3.なんかTiny透けてね?
→原因不明。
→Tiny自身が透ける体質なのか、実はエフェクトを設定する必要があるのか……。
→これから原因究明しなくちゃいけないなぁ。

という訳で、アニメーションの手前で解決しなきゃいけない問題がまだありそうな予感です。

ゆったり、まったり、たのしく。

カメラをクラスに分けて、とりあえず動くところまでコーディングしました。
画像はそれを動かしてみたところなんだけども、まぁ、内部的な変化だから、見た目にはワカランわな(笑)

このクラスには、今後カメラをお手軽に動かせるような、そんな機能を付けていこうと思っています。
が、いつになることやら……。






さて、引き続き探していたモーションXファイルの取り扱いについて、かなり有効な資料が見つかりました。
(書籍なんですけどね)
カメラもクラスに小分けできたことだし、そろそろ本来の目的であるモーション付きXファイルの利用に戻ろうかと思います。

9.21.2008

たまには気分を変えて。

Delphi+DirectXヘルパー関数を気軽に使うクラスは、カメラの処理が手軽にできたほうがいいだろうということで、そちらに着手。

だけど、ずっと3Dのプログラムじゃ頭の中まで3次元になってしまうので、気分転換にSDL。

今回はLesson28。
今回はっていうか、前回の続きですな。

お題はパーティクルエンジン。
パーティクルっていうから、シューティングゲームなんかで見られる弾幕を想像してたら、動き回るスマイルさんの後ろにキラキラと小さなドットが瞬くだけでした(笑)

久しぶりにC++触ったけど、やっぱりキモイな。いろいろと。

9.20.2008

Visual C# 2008 SP1

というわけで、VC# 2008 SP1(ExpressEdition)を放り込んでみた。
ついでなんで、.NET Framework も 3.5 SP1 にしてみた。

これまでインストールしなかった理由として、手間がかかるというのがあげられるけど、こういう眠れない夜に限っては、その手間が眠気を誘ってくれるいい薬になる。

そんなわけで、まずは.NETFrameworkのアップデート。
インストール中に、セットアッププログラムを終了しろという警告が出たものの、無視したら通った。
なんなんだこれは……。

が、同様の報告をネット上でもいくつか見かけたので、とりあえず問題視しないことにした。


続いてVC#のインストール。
ExpressEditionは全とっかえが必要なので、先に古いものをアンインストールしておく。
んで、SP1のセットアッププログラムを落としてきてセットアップ。

こちらは特に問題なくインストールできた。
(ただ、ネット上では止まる、落ちる等の問題が出たという報告も見かけた)

後は特にやることはなし。

実際使ってみた感想としては、VC#について、起動速度がかなり向上していると思う。
これならストレスなく開発ができそう。

まぁ、しばらくVC#に触る機会はないんだろうけどw

9.17.2008

アクションゲームツクール

いつものように、本屋でファミ通を立ち読みしたら、伊集院光氏のコラムに話題が上がってた。
気になったので調べてみたら、GameWatchにニュースリリースがあった

最近のRPGツクールの動向からして、当然Rubyベースなスクリプトが書けないと話にならないようなツールなのかなぁ。と思っていたら、どうやらプログラミングのスキルは必要ないとのこと。

Rubyじゃアクションゲームの応答性には答えられないってことか?1.9ベースのエンジンなら、めちゃめちゃ早いと思うけど。

作ったゲームは箱○ことXbox350でも動作させることが可能になるんだそうで。
それによって何がうれしくなるのかはよくわからないけど(笑)

まぁ、GameWatchに上がってるスクリーンショットを見る限りだと、作るのはRPG以上に大変そうな感じがする。
アクションゲームならそれほど難しいテクニックがいらないんだし、HSPあたりで実装した方が楽にできるんじゃないかなぁ?

それに、ここにきていまさら2Dアクションツクールを出してくるっていう意図がわからん。

せっかくやるなら、MikuMikuDanceで出力したモーションデータを使って3Dのアクションゲームが作れますぐらいの出せばいいのに。

そしたら、オヂサン初音ミク無双とか初音ミクBASARAとか作っちゃうよw

静かにしてくれ

街宣車は規制されてるのに、なんで選挙カーと廃品回収のおっさんは規制されないんだ。

少なくとも、選挙カーは住宅街での走行を厳しく制限されるべきだと思うし(住宅街と規定されている地域では、スピーカーから音を出しちゃいけないとか。)、廃品回収のおっさんはスピーカーから出る音量をもっと小さくするべきだと思う。

こういうのってみんな公害だと思わないのかな?

9.16.2008

便利なcoLinuxコンソール

久々にcoLinuxの話題。
dev-MLだけに投げられた投稿ならよそうかと思ったけど、users-MLにも同様のメールが投げられているようなので。

本文をそのまま載せるのもアレなので、件のプログラムについて、ざくっと要約&紹介をしておきます。

coLinuxユーザーのPaoloさんが、colinux-console-ntに機能付加をしたそうです。
これまでのコンソールを踏襲しつつ、

・範囲選択でのコピー&右クリックでのペースト

の機能を付加。

すごくちっさい改良に見えますが、これが実に便利。
(colinux-consoleを使う人にとってはという但し書きつきですけどね。)
ダウンロードは以下から。

http://xoomer.alice.it/paolo.minazzi/colinux-console-nt.exe

使い方は、従来のcolinux-console-ntにコピペでインストール。
あとは従来のものと同じように呼び出し。
WIN+ALTキーで、従来のcolinux-consoleと同じふるまいをします。

85x25キャラクタの表示に対応しているので、まぁ、標準的なコンソールプログラムなのかなぁ。
Ver:0.7.3-20080524で動作確認がとれている様子。
ただ、自己責任で使うのは言うまでもないことですよ。

大きなブロックをコピペするときに、コンソールがクラッシュするという既知の問題があり。
Henryによれば、テキストカーソルの点滅スピード速すぎない?とのこと。

言われてみれば、確かにそう思う(笑)

まぁ、興味のある人は使ってみるといいかもね。

9.15.2008

当面の問題は解決。

一応、これで先に挙げた問題は解決したっぽい。
まだDirect3DのAPIについて理解の浅いところがあるから、そこを詰めないとダメかな?なんて思ったりするけれども、カメラワークとテクスチャの問題が解決したから、次のステージに進むとしよう。

JEDIヘッダとQuadrupleDヘッダの定義の違いからくるところは、とりあえずQuadrupleDヘッダに合わせることにした。当面は困らなそうだし。

俺はアホですかそうですかそうですねまったくですよね。

カメラワークが思い通りいかないよう><
という問題。

解決しました。

単純にIdleループ内でカメラの再設定をしていないからでした。

9.14.2008

六角大王[フリー版]でのモデリング>>>>>>>>DirectXをたたく

そんなわけで、六角大王のモデリングが難しすぎだと思います。
メタセコイアで3Dの世界に入ったアタクシとしては、六角大王でのモデリングは、お手軽さを損ねる原因の頂点に立つのでは?と思えるほど。

したがって、Xファイルを表示する方へ逆戻り。
朝言っていたことが夕方には変わっているというアレですね。

目的のためには手段を選ぶなとは、よくいったものです。

だけど、ただ表示したんじゃ芸がない。
そんな無駄な発想から、Xファイルを読み込んで表示するクラスを作りながらやってます。
だんだん拡張して、カメラを扱うクラスやライトを扱うクラスをそろえられたらいいなと。
そしたら、後々便利になるジャン!

使いなれないDelphiさんのポインタに苦戦しながら、なんとか形にはなりましたがね。
そんなわけで、いったんセーブです。




一応、メッシュそのものの表示までできるようになったわけだけれども、いくつか問題があって、

・JEDIヘッダとQDヘッダではD3DMATRIXの定義が違うため、どちらかに揃えると上手く行かない所が出てくる
・カメラワークがおかしい?(←サンプルプログラムで想定しているようにならない;
・テクスチャの表示には未対応(←だけど、こちらは光明が見えている

といったところが当面の課題。
アニメーションに程遠いというのは相変わらず。

そうそう、それと、DirectXSDKの付属サンプルをDelphi向けにリライトしたもののうち、いくつかのプログラムが手元で動きません(笑)

特に重要なアニメーションのサンプルが動かない;
エラーを見る限り、デバッグ用DLLをよこせって言っているようだけど、DirectXSDK入れるの嫌なんだよなぁ。

むしゃくししてやった、今は公開後悔している。――いや、本当に。

つい昨日、寄り道を予想と決意したばかりなのに、なにをやっているんだろうか。

メタセコイアでモデリングの練習をしてたら、ふとOpenGLモードがあることに気づき、そこから

・OpenGLって、比較的マルチプラットフォームなライブラリだった気がする
・OpenGLって、DLL化されてた気がする
・じゃあ、Delphiでも使えるんじゃないか?
・(DelphiのLibディレクトリをのぞいて)OpenGL.dcuがある!こりゃいけそうだ!!
・ネットで情報を探す→あれ?WindowsでOpenGL使うのって、Linuxと流儀が違ったりするの?
・どうやら流儀がだいぶ違うらしいことに気づく(ここまで2時間ほど消費)
・そういえば、GLUT使うと、統一的なインタフェイスでプログラミングできるって、授業で習った気がする。
・よし、Delphi向けGLUTを探そう。
・結構速く見つかったな。試すぞ。(ここまでさらに20分ほど)

・うごかねーーーーーーーー!!!

・このヘッダーがまずいんじゃね?(気づいたのがさらに3時間ほどたってから)
・使えるライブラリ無いの?
・さらに探す→サンプル付きのライブラリがあるじゃまいか!
・使ってみる

・またうごかねーーーーーー!!!

・ソースを微調整
・動いた!ktkr!!!!(ここまでさらに10分ほど)

そんなわけで、寝てませんよwwwww

苦労の結果提出できる画像がこれだよ!!!




ほんと!後悔するよNE☆
OpenGL好きだから、こんなもんじゃやめねぇけど!

使ったのはこれ↓
http://delphi.codefetch.com/example/k4/lunits/elfglut.pas?qy=getmenu

施した改造は、uses節にWindowsを追加したこと。

注意点として、glutInitの呼び出し方法が特殊で

glutInit( MS_LIB )

のように呼び出さなくてはいけないということ。
if文の条件式として呼び出せば、エラートラップもできていいのかもと思った。
あとは、C向けのGLUT開設サイトのサンプルソースが、ほとんどそのまま通る。
Delphi with OpenGLしたい人はお試しあれ。

# 追記
実行時にはglut32.dllを要求するから、どっかから拾ってくる必要があるよ!

# 追記2
眠い時に難しい漢字使ってタイトル書くもんじゃないね!

9.12.2008

遠回りして気づく。

Xファイルの表示だのなんだのやってみたけど、あんまり意味ないんじゃないかと気づく。
そもそも、やりたかったのはお手軽に3Dのゲームを書くってことだったし。

そんなわけで、本来の道筋に戻ります(笑)

とりあえずそれなりに動くものを仕上げてから、ここまで検討してきた事柄について再検討してみようと思うよ。

# これに気づいたのは、描画やらなんやらを自前でやりながら、お手軽さがたりないと思ったところから。

9.09.2008

遅くまでおきててもロクなことがない。

頭は回らないし、プログラムは書けないし。
そんでもって、ネットサーフィンした挙句、面白そうなライブラリを見つけちゃうし……。

だが、今はこの心躍る発見をつまみ食いしている場合じゃないのだ。
……だけどメモだけしとく。

・G3D――SDL+OpenGLで3Dゲームを実現するためのフレームワーク

案外開発も活発らしく、今やってることに飽きたらこちらに転向するかな。

もうひとつ。
こちらは思ったこと。

・MQOファイルを読み込んで、Xファイルと仲良く使えないかな?(←Xファイルが扱えれば、利便性は低い?
・Xファイルの取り扱い方について、SXをみならってクラス化してしまおうか

どちらも所詮思いつき。

僕敗北。

どうにもこうにも、SXファイルとの共存が難しい。
というか、SXLibと共存がすごく難しい。

どうしたものか(´ε`;)ウーン…。

QuadrupleDでの初期化処理→あとは普通のDirectXと同じっていうだけでも、だいぶ手間は提言されるものの……。

SXLibを使わないことによる弊害がどの程度発生するかによるのかな……?


もうすこし、SXLibについて精査する必要がありそうだな。

9.08.2008

ライティングの難しさ。

ここまでくると、もはやセンスの問題だとすら思えてくる(笑)
テクスチャ貼ったSX形式のキューブがいまいちうまくふるまわねー!!と思ったら、鏡面反射光をOFFにすることで、問題なくふるまってくれました。

Zオーダーの問題も、単純に私が座標系を間違えていただけでした。
右手座標とか、左手座標とかややこしいんだよ!
普段OpenGLで組んでるんだから仕方ないだろ!←ひどい言い訳

さて、ここまで来たら、今度はモーション付きXファイルについて考え始めてもいいかと思っているんだけども、まだ問題がある。

と、その前に、まずはうまくいった証拠として図をどうぞ。






さて、アニメーションに行く前に残っている(と思われる)問題。

1.カメラワーク
カメラの位置とか、制御というのをどうやるのがうまいのか理解できていないから、そこを考えないといけない。
勝手な思い込みかもしれないけど、QuadrupleDはカメラを動かすことで視点の移動を実現できるけど、DirectXはカメラが固定でオブジェクトの座標を変換することでカメラの移動を実現している気がする。

となると、QuadrupleDを叩けばどっかでつながっているところにたどりつくわけか。

なんにせよ、その辺は解決しないとどうしようもないと思う。

2.オブジェクトの回転
カメラに絡む事だけど、オブジェクトをその場で回転させたりする方法がよく理解できていない。
便利な行列変換やら行列操作のライブラリがあるから、フレームやらなんやらについて理解できればその場での回転も問題なく行けるものと思われる。

3.オブジェクトの制御
たとえば、シーンをレンダリングした後にXファイルを描画すると、シーンで最後に描いたフレーム内に描画されてしまう。
これをうまく使えば、思い通りの描画ができるんだろうけど、この辺はまだ調べないといけないところだと思う。

と、とりあえずはこの3点が課題。
3.は描画順序を工夫したり、Xファイル用のフレームを用意するだけだから、それほど手間ではないと思うけれども、1.と2.が解決しないことにはアニメーションをやっても面白くない気がする。

単純な解決法としてはQuadrupleDを使わないことなんだけど、それでは今回いろいろ調べてる意味がない。
(お手軽プログラミングのためにお手軽でない道を通るってのはバカに見えるかもしれないけど、目的のためには手段を選べない状況なんですな。)

3Dについて、もっと勉強しなくちゃ。

9.07.2008

確認作業は粛々と続く。

そろそろカスタムしたことによる有用性が見えてきたかもしれない。
図はQuadrupleDで提供されてるビルボード機能と、トラの回転画像を合わせるというもの。
サンプルのソースコードそのままで、普通にビルボードが表示できた。
(背景がトゥーンレンダリングのようになっているけれど、正体はメタセコイアでレンダリングした単なる一枚絵)



こうなると、当然SXファイルによるオブジェクトとの共存も考えられる。
それを実行してみたのが下図。
(Tiger.xと自分の作ったSXファイルとで)モデルのスケールが合ってないから、一度取りがちょっと大変だけど、基本的にはうまく行った。




だけど、ここでいくつか問題がある

・光源がおかしい(トラの設定でメッシュにあたっているせいか、白くなってしまっている)
・オブジェクトごとにZオーダーを持っているものと思っていたら、BeginSceneで描画を指示した順番に奥から描画されていく
・描画順序を変えると、座標は同じはずなのに描画結果が著しく異なる

この辺はまだ追跡調査の必要がありそう。

とりあえず問題解決。

カメラワークの方が簡単だと思っていたら、こちらの方が簡単だった。
というのも、TDGTextureオブジェクトがうまい具合にラップされていないテクスチャオブジェクトを参照する手段を提供してくれていたから。
実質一行だけで済んでしまった。

これなら、複雑なマッピングがされたオブジェクトでも、配列を定義してやればよさそうだから楽だな。
(クラスを噛ませるから、メモリの効率は悪いんだろうけど。)

画像はテクスチャを貼った昨日のトラ。






そんでちょっと手間のかかったカメラワークの方。
いろいろ考えた結果、ワールド(トラの住んでいる、画面の向こう側の3次元の世界)ごとグルグルまわしてみることに。

よく見てみたら、参考にしたソースもワールド座標を回してた。
そんなわけで、画像は回っている様子。



これでライブラリもそれなりにうまく動くことが実証できた。

使ったカスタムライブラリはこちら。
上のぐるぐる回るトラのサンプルはこちら。

お約束ですが、ご利用は自己責任で。

だいぶ手間取った&道のりは長い。

Xファイルを読み込んで、モデルデータを表示させるところまではできた。
具体的に言うと、JEDIのヘッダーを改造して、QuadrupleDと仲良くできるようにしてやった。
ただ、どうしても仲良くできなさそうな点が2,3見つかったので、QuadrupleDのD3D9.pasについても手を入れた。

これで、DirectXのヘルパー系関数を手軽に利用できるようになった(ハズ)

だもんで、まずは静止オブジェクトのロードと表示から。
と言っても、ほとんど前回参考ページとしてあげたサイトのソースをまる写ししただけなんだけど(笑)
図は、DirectXの最近のサンプルでおなじみ、虎のモデルを表示させるデモ。
まだテクスチャマッピングはしていないから、図のような無地のモデルになる。

(ただし、メタセコイア等できちんとマテリアルの設定がなされていて、モデルの地に色が付いている場合にはその色で表示される。)






という訳で表示までこぎつけた。
一応、使ってるヘッダー類はいつものところに上げておきます。

ドキュメントも何もないものですが。
そうそう、このヘッダーについて、SANDMAN氏やDirectXヘッダー関連のプロジェクトに問い合わせないように。

現状の課題は
・カメラワーク(おそらくこれが原因で2次元のような表示になっている)
・テクスチャマッピング(テクスチャはなんとかTDGTextureの力を借りられないものだろうか?)
といったところか。

アニメーションへの道のりは遠いな。

今日はもう寝よう。

9.05.2008

久しぶりにこんな時間まで起きている気がする。

最近すぐ眠くなるから、結構速くに寝てしまうんだけど、今日はなんだかこの時間まで起きている。
当然頭は回ってないけど(笑)

んで、すこし考えたり調べたり実践したりしたのでメモ。

まずはDirectXをDelphiさんから直接たたくっていう方法。
組んでみて、これはQuadrupleDに比べるとあまりにも労力が大きいうえに、Delphiでやる意味はどこにも無いことに気づいた。

QuadrupleDを使わないなら、Cから使った方が、資料も多いし楽だろうということだ。

だから、これはやらないだろう。
もしやるとしたら、QuadrupleD + Delphiという組み合わせを捨てる時だと思う。

これに絡んでDG-Caradを調べていたら、D3DDevice経由でD3DDeviceオブジェクトを直接操作できる(というか、D3DDeviceオブジェクトそのものがうまーく実装されている)ことに気づいた。

よく考えたら当然なんだけどね。

んで、これを利用すれば面倒な初期化処理はQuadrupleDに投げて、 Clootie graphics pagesのDirectXヘッダー(JEDIヘッダ)を用いてヘルパー関数の機能を拝借することができるんじゃないかと。
(ここ最近話題に上げてるアニメーションについては、ちょっと置いておく。)

いくつか型を定義する必要がありそうだけど、そのくらいはやりますわな。
(これは、JEDIヘッダが、DirectXヘッダーにまでT**というDelphi伝統の命名方法を採用しているのに対して、QuadrupleD搭載のヘッダでは、本家DirectXと同様の名称が採用されているため。
まだ試していないけど、おそらくコンパイラはじかれると思う。型の不一致で。
だから、どちらかに統一するか、キャスト等の型変換機構が必要になってくるんだと考えているから、型を定義する必要があるかもしれないという結論に至った。)

そんなわけで、明日の(今日の?)課題はこの辺を探ってみるということ。
参考になりそうなページだけ、メモ代わりにリンクしておく。

・参考になりそうなページへのリンク
http://www13.plala.or.jp/kmaeda/directx9/tiger2.htm

9.04.2008

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

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

のはらしんのすけ義塾大学というのが開校したそうで。
新手の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ファイルに含まれていないことがわかったわけだし。

9.03.2008

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

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

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

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

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

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

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




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

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







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

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

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

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

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

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

9.02.2008

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

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

実は、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の強力さには驚かされるね。

9.01.2008

疑問山積

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

これまでは六角大王のデータを読み込んで、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でつけたモーションデータを取り扱える様子。

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

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