Pintek Soft

とりあえず仕様が決まったからってことで、モデリングを再開しました。でも・・・これ駄目かなあ；

まあおいら的にはそこそこまとまった感はあります。しかしそれが問題ですわ。まとめようとすると、どうしても絵が古くなる;;;

基本的にこういう絵なんですね。俺の絵って。

テクスチャを使えば今っぽい絵になるかと思ったら、昔手で描いてた絵みたいになっただけですよ、ええ。

この状況はある意味非常事態だ。いいか、隊長の指示を絶対に守れ、それが死を意味してもだ！

･･･隊長って誰だ。

テクスチャはFireworksでベクトルデータで作っているので、簡単に部品ごとの比率を変更できます。

･･それが故、気付くと黒目の面積を小さくしてました;;

今の絵って、大抵もっと黒目が大きいんですよね。わかります。

ま、それだけの問題じゃないでしょうけど；；　というか、このサイズの黒目のほうが据わりのいいモデリングをしてたというのが正解です。

しゃあねえ、いかにも流行りもののモデリングでもしてみるか・・

てか、今の流行ってどんなですか？教えてください！お願いします！

　　 ∩＿＿＿∩
　　 | ノ　　　　　 ヽ
　　/　　●　　　● |　　　こうですか！？わかりません！
　 |　　　　( _●_)　 ミ
　彡､　　　|∪|　　､｀＼
/　＿＿　 ヽノ　/´>　 )
(＿＿＿）　　　/　(_／
　|　　　　　　 /
　|　　／＼　＼
　|　/　　　 )　 )
　∪　　　 （　 ＼
　　　　　　 ＼＿)

・・とか平気で古いネタをやる体質を変えないと無理かもしれません;;

何気なくxnbのファイルを見てみたんですよ。

元がテキストファイルのfbxだったファイルは、一応バイナリにしてくれるので容量は減ります。この辺はまあ、順当といった話で。

で・も。

問題は画像ファイルなんですよ。

130×100ピクセルの画像のxnbへの変換結果は･･

５２ｋｂ

です。平たく言って

100x130x4=52000

ですよ？つまり３２ビットベタ画像。未圧縮。

いくらなんでもそれはないんじゃねえ???

こりゃあいよいよjpg展開ルーチンも作らなきゃだめですか?

･･そこまでやる気はあんまりないなあ；；；どうしましょ；（まあ放置するような気がしますがね;

テクスチャも貼れましたよ？

あ、テクスチャ自体がアレなのは勘弁してくださいね?

訴えないでね（汗　別に意味はないんですよ？

毎度この絵だけみると標準のローダでも変わらないというお約束ですが、一応アニメーション（ボーンアニメ含む）対応してますんで、いろいろ問題が無いわけじゃないですけどゲーム作るのに充分なシステムできたような気がしますよ。

コンテンツパイプラインの仕様上、いくつか気に入らない点もあるんですけどね。特に隠しておきたいパラメータを表に出さざるを得なかったりとか、できることなら改善したい・・まあ、別に自分だけでやってるんだから、たいした問題じゃないんですけど。

それはともかく、ＸＳＩのＦＢＸエクスポータ、バグ見つけました･・複数のテクスチャをマテリアルに貼ってあると、まともに吐き出さないことがあります。まあ、どのみちＦＢＸ自体がマルチテクスチャきちんと対応してないのかな?（もしかするとＸＳＩのエクスポータがそのようなコードを出しているだけなのかもしれませんが）ＵＶも１つしか出ないみたいですし。

というか

ＦＢＸの仕様考えた奴表出ろ～～～

複雑な割にものすげーパラメータ同士の繋がりが切れてたり、すげえ非論理的な感じがします。

・・オブジェクトとマテリアルの接続を表現するところはあるのに、マテリアルとポリゴンの関係が曖昧だったりとか。ポリゴンに番号が振ってあるのですが、その番号って、マテリアルの･･書いてある順番ですよ？

しかも、そのオブジェクトに付属するマテリアルだけの並び順なんで、ちゃんとマテリアルを抜き出してやらないとどれがどれだか分からないという。

･･それとも、もっといい方法あったんですかねえ（大汗

なにせ、きちんとした資料ないから、ほとんど自力で解析したからなあ；；；

・・あ、そういえばアニメーションの曲線のほう、まだやってないや（汗

まあ読み込みはできてるのでどういう仕様にするかだけです。たいした問題じゃない。今度は本当にｗ

･･というタイトルですが、絵はまるで

「すいません、ちょっと通りますよ・・・ 」ですね（腕があるけど；

とりあえずＢｏｎｅ変形これでＯＫじゃないかと。ちゃんと意図のとおりに変形してくれます。

あとはアニメの曲線とテクスチャが出せれば大体ゲーム作るのに問題ないレベルに到達しましたよ！いやまあ他にモーションブレンディングとか絶対ほしいですけど。とはいえこれでモデルの仕様がほぼ固まったので、画の作成に入ることもできます。

というわけでモデリングもはじめ･･るまえに、今ウケてる感じの画を研究しないとねー。

あ、一応言っておきますが、しばらく作ってたモデルは俺の趣味バリバリで作ってたってこともあって、受けをとろうという意思があんまり働いてません。本当だってば。だがこれから俺の趣味から多少外れても一般受けを狙うさ、本当さ!・・とはいえ、なんだかんだ言ってある程度は残るし、それが味であり愛だってものですわね。

しかしそうなるとシナリオとかも考え出さないといけないわけで･･構想はあっても、文章にできるかがねー；

まあ、最低限自分で納得できるものくらいはできないとは申しませんが、なにせ時間がかかります。そういう意味では、文章って才能もともかく、技術なんだな、と実感するしだいで。絵やプログラミングと同じですね。（この並びにプログラミングを持ってくることの方が本当はナニなんですがｗ）

なんてつまらない絵なのでしょう（汗

アニメーションおかしかったところを修正、かつベースポーズ適用しました。ベースポーズはスキニングしてるものじゃないと意味が無いじゃないかｗ

ただしスケールがかかっているオブジェクトに対してのボーン変形はまだおかしい。ただこれを下手に処理するとちいと怖いですな。他の３Ｄソフトだとどういう動作するか見当がつきません。他の、といってもＭａｙａとＭａｘだけ考えればいいんですけど。

・・ＬＷですか？

ＬＷのＦＢＸエクスポータって、アニメ対応してましたっけ（汗

してるなら手元にあるから確認するべきなんですけど;;;

ま、どうせソフト組むのも俺だけ、モデリングも俺だけなので問題ないんですけどね;;

あー欝だし。

アニメーションもできたといえなくも無いですな。まあ、アニメを録画する方法も分からないし、ここには動画を張る仕組み作ってないしw　あとはキーフレームが線形補間しかしていないのと、ベースポジションをまだ適用してないくらいかな。いやそれじゃ充分できてねえ。まあすぐできそうですけどね、そのくらいは。

ただ仕様的に子オブジェクトの拡大をXSI仕様にするか、普通の仕様にするかちょっと悩んでいたり。どう考えても普通の仕様の方が好みなんですけど、XSIと相性悪い気がしてならないです。というかモデリングで概形を決める際にオブジェクトを拡大する奴が悪いです。俺のことですよ？

まあ、そこはモデリングのしかたを変えましょう。XSI上できちんと動いていればゲーム上でもきちんと動いてくれるはずなので、出来上がってから泣くケースは多分無いですし。本当に悲しければソフトで対応も考えます（w

・・そういえば、まだテクスチャ貼れないんだったwww

UVはすぐに対応できそうだけど、ファイル読み込みで難儀するかもなあ；；

見た目上なんら変化がないかもしれませんけど（汗。　XNAでのオブジェクトローダです。

この前の奴とは違ってちゃんとfbxの形状（スキニング用のボーンウエイト含む）、オブジェクト階層、マテリアル、といったあたりがきちんとロードできてます。つまりかなり進んだってことですよ（汗

まあまだやることは結構ありますけどね。

調べ物としてはfbxのキーフレーム構造がほぼつかめたってところが結構重要でしょうか。なぜかそのあたりの情報がないので、データ現物とXSI上の数値を照らし合わせて類推しました。ほぼ合ってると思います。万が一にも知りたい方いらっしゃったらご連絡くだされば。

・・にしてもfbxのSDKって、ロードするためのDLLとその使い方だけしかないですか?それとも俺見つけられないだけですか?

ファイルフォーマットの細かいところ、資料がないので解析に結構手間取りましたね･･･XNA自体よりこっちの方が問題だったかな;

まあ次はキーフレーム構造作って、ローダ作って、ってところだけど、難しいところはないのでがんばりましょう。

XNAのメモでありんす。基本的に自分で読むためでーす（はあと

というわけで間違っていても自分で利用できれば問題なしレベル（汗。

ContentImporter

読み込み部分ですね。読み込んで保存するために最適なオブジェクトを作りましょう。

ContentWriter

ファイルへの書き出し部分です。読み込むときに元の形をきちんと維持できるように必要なデータを書き出しましょう。

ContentReader

ContentWriterで書き出したものを読み取るための部分です。書いたものは全部きちんと読みましょう。必ずしも保存しなくてもいいですが。もっともWriterで書いたものを保存しないってのも間抜けですけど。ていうか、リーダとライタってほとんど対になるコードなので、どっちか書けば反対側も書いてくれればいいじゃんか、とか思ってしまう今日この頃;

ContentProcessor

読み込みのときの形を実際に使う形に変換します。この処理をReaderで無理やりやろうとしていたのが今までの失敗でした;

Importer>Writer>>xnbファイル>>Reader>Processor

って順番で処理されるのかな?

WriterとReaderの間にProcessorが入るものだと思っていたのがProcessor全然つかってなかった理由。

というか気持ち的にはオブジェクトに直接ローダ実装したいというのがありますが。まあそれが最適というわけではないですけど、いままでずっとそうやってましたしね;

まあいいや。方向性がわかったので書き直しましょう。

しかしXNAって微妙な所もありますけど、ローレベルなコード書けば何とかなるというのは助かりますよ。面倒くさいですけど;

全体的にローレベルなところほどよくできている気がします>XNA

･･逆でなくてよかった、正直よかった、XNA。

やっとこ自力でFBXのモデル形状は読み込めるようになったので、これは一つの進化と言えなくもないです。

が、所詮まだアニメはおろかヒエラルキ（という表現、当たり前すぎて普段使わないだけに新鮮w）も対応していないので、見て楽しいもんじゃないので別の話で。

今までXNA Creators Clubの会員であるにもかかわらず一度もXBOX上で自作ソフト動かしたことありませんでした。会費がもったいないところでしたが、実は2度目の課金がまだありません。それどころか次の支払い発生日がいつの間にか1年後になっています。

ただのスレッショルドですか？これ。4ヶ月バージョンでよかったって事かなw?

まあそれはともかく、とりあえずXBOXにゲーム転送してみました。すっごく簡単です。

ってこれお前が作ったゲームじゃないジャン、と言われればそうですね（汗

まあもう少しすれば自力オブジェクトエンジンもできますので、そうなればやっと、クリエイティブな作業に移れますよ。

しかし試行錯誤の連続なのであまりきれいなコードではないですね（汗

とはいえ、問題があるのはほとんどローダー側で、製品にはまったく影響しないと思いますのでいいかなあと。

いや一点よくないかも。ロードがすげえ遅い。これだけはヤバイかも。

でも遅いのが

ファイルからテキストを読み込むだけ

の処理なので・・どうよそれ？100行読むのに1秒くらいはかかってるよ？

もしかすると一度に読み込んでから処理すること考えた方がいいかも。

ま、一通り動いてからだべっちゃ。

私にとっても大きな一歩かどうかは微妙です。まあ一歩ではあります。

とりあえずデータ読み込みは後回しにしてレンダリング側から攻めてます。スキニング対応の頂点フォーマットを使えるようにするのに丸一日使ってしまいました;

悪かったのは頂点フォーマットの選び方がエフェクトと違っていたあたりですな。いや現状でも違ってるはずなんだけど、なぜかうまく動いていたり;

ＣＰＵ側のコードでは位置ベクトルは３次元、シェーダ側だと４次元だったりして。

まあ確かにデータとしては３次元あれば足りるけど、計算のときは４次元必要ですけど。なんだこりゃ。

もしかしたらデータサイズが４の倍数じゃなきゃダメとかあったかなあ；確かに現状４の倍数だし。

これで次はロード部分ですか。なんだかんだで結構手間かかりそうですね。

・・ＸＮＡの機能をもっと生かせるかと思ってたのに、結局かなり低レベルのコードを書く羽目になっているので当然といえば当然なんですが・・

いや全然意味がないタイトルです。Ｃ＃の話なんで興味ない人はブラウザを閉じてください。閉じなくてもいいですけど(汗

結局ありもののジェネリックを使おうとすると、結局使い方を調べている暇があったら自分でその仕組みを作った方が圧倒的に早かったり。まあＬｉｓｔくらいは使いますけど。

一人でやっている限りそのとおりだと思います。多人数でやっているなら仕組みが分かりやすいというメリットがあるので、意味があるとは思いますが、どうせ僕以外僕のコードはいじらないので問題なしです。

｢一度使えば使い方分かるじゃん?｣

という意見もあるでしょうが、僕は頭が悪いのですぐ忘れます。ええ、忘れますとも。覚える暇があったら、というか思い出す暇があればあの程度の仕組み簡単につくれますよ。どうせ木構造位しか使いません。

コンテントパイプラインですが、結局自力でfbxローダを作ることにしました。fbx自体そんなに複雑な構造ではないですし、下手なことをやってる暇があったら一から作った方がマシと思えましたので。

というわけで本日はコンテントパイプラインのフルスクラッチ開始。パイプラインの流れを作って、fbxの構造を読むコード書いたところで終了。大してすすまなかったにゃ；

明日中にはオブジェクト表示するまで・・いけるかなあ；

前に書いた｢2，3日で｣という話はどこへやら。まあ、もともとのfbxのローダーがキーフレームを直接触れず、全フレームに行列で展開された状態でしか触れないって仕様がいけなかったわけですよ。誰だこんな仕様考えた奴。まあ確かにキーフレームの仕様って３Ｄソフトによってかなり違うとはいえ、基本的には軸ごとの回転の積かクォータニオンしかないだろうに。まあfbxの仕様まだ詳しくは見てませんけど、そのあたりはいろいろな形式でソフトは吐いてきそうなので、ある程度は種類はありそうですけど・・

というかその辺の仕様がダメすぎるので標準でＸＮＡはアニメーション対応できなかったのでは、と疑いたくなります。

まあ、いいさ。作ればｗ　そのあたり作れば大丈夫な柔軟性に感謝しましょうｗ

いくらなんでもこれはねえと思うんですよ。

ＸＮＡのモデル読み込み、一応コンバータ読み込みの時点ではアニメがついてきてます。じゃああとは書き出しデータに書くだけジャン?

そう思っていた時期もありました。

まあ、キーフレームの一般的な方式なんてないといえますから、何かしら統一的な方法をとるほかないのは分からなくもないです。

でも、行列しか読めないってのはかなり致命的では。まあ、どんな入力がきても行列なら対応できます。そりゃね。

ただ、補間したりブレンドしたりを行列ではちょっと無理なので、できればＨＰＢ(軸ごとの回転ですね）なり、クォータニオンなりで処理してほしかったわけですよ。はい。

軸ごとの回転は回転順序を入れ替えると大変なことになりそうだから、クォータニオンかな。ベストは。

じゃあ行列>クォータニオン変換しちゃえばいいじゃん?というのもありえる話ですけど、キーフレームが全部展開されてて全フレームにキーフレーム打ってくれてますんで、とても気持ち悪い;;;

のでできればもともとのモデル読み込みは使いたくないけど、そうするとｆｂｘのパーサ作らないといけなくなりますな;;

それも面倒だし・・どうしましょ；

・・クォータニオン変換ならブレンドはできるか･･

で、変換したものをデータとしてストアするとか？

･･結局面倒なことになるオチが待ってそうですが、その線でいってみようかなあ･･

これでやっとコンテンツパイプラインのなんたるかを理解しました。やっぱり言語自体の仕様がわかってないとできるはずないよなｗ

まあパイプラインの流れが理解できただけなので（つまりインポータの作り方がわかっただけなので）これからは実際のインポータの製作に入ることになります。fbxの構文解析の必要はないし、参考になるコードはあるわけですからまあ、2，3日でできるんじゃないかなー。甘いかな;

とりあえず構文解析がいらないだけバグは激減させられるのでがんばりましょう。

今までゲームというカテゴリーがなかった（汗。

というわけでかなりひさびさのゲーム製作ネタです。

ということで近々XBOXゲームの自由な配布ができるようになるということです！

まだ全然手をつけてないんですが、今年中に課金も可能かもしれないとのこと。こりゃ意地でもやるしかねえ。

あともう一件。

ソニーがXBOX360とPS3,PCのクロスプラットフォームエンジンを作成・・となｗ

これを使えばソニーがゲーム機から撤退しても大丈夫ですねｗ