Xファイルを再生するスレ

**万☆星太郎** · 01/11/25 02:50

　DirectXで３Dゲームを作る奴らの登竜門、Xファイル。
DirectX７の時は勝手に再生してくれたが、
今は参考になるサイトも無し、公式のサンプルもわかりにくいで
非常にやりがいのあるモノだと思われ。

　ｻﾊﾟｰﾘわからないやつ、クヲータニオンって何ぞや？ってやつ、
ノンスキンXファイルなら再生できたけどｽｷﾝﾒｯｼｭは再生できない奴、
がむばろう！

一、諦めずに粘り強くがんばれば絶対できる
一、出来たときの喜びはｻｲｺｰだYO

公式サイト
ttp://www.microsoft.com/japan/developer/directx/default.asp

情報板
ttp://www.bio100.co.jp/dev.html
ttp://isweb8.infoseek.co.jp/computer/bbx/

さあ語れ！！

**名前は開発中のものです。** · 2005/08/20(土) 03:29:48

今日はＸファイルの読み込みをやった。
ちなみにまだ終わって無いｗ

その際に面倒臭かったこととよくわからんかったこと
・なんか Frame FrameName { とかなってるけどこのFrameNameっつーのが
　あったりなかったりしてむかつく。
　次のトークンの始めの文字が括弧かそうでないかで判断するしかないのだろうか？
　なんで

Frame{
　　　　Name{"objectName"}
　　　　FrameTransformMatrix{
　　　　・・・
}

　みたいなフォーマットにしなかったのかわからない。
　Ｘファイルのフォーマットを考えた奴はアフォだと思った。

・上の例もそうだけど、わざわざトークン＋デリミタ（VBのSprit関数をイメージしてくれ）で綺麗に読み込め無い
　フォーマットのファイルを作っちゃうところがわからない。
　それともこういうフォーマットを綺麗に読み込める技（みたいなの）があるのだろうか？

・ファイルの冒頭のtemplateの使い方がよくわからんかった。
　結局、型なんて定義してあったって読み込み側が対応してなけりゃそれまでだと思うんだけどな。

**名前は開発中のものです。** · 2005/08/20(土) 06:03:52

みんなはＸファイル読み込んだ後どんな形でデータ持ってる？
俺はフレーム・ボーンとメッシュを全く別のシステムで扱って
メッシュの着せ替えが簡単にできるようにしてある。

**名前は開発中のものです。** · 2005/08/20(土) 07:39:36

テンプレートがあれば拡張された未知のデータがあっても、
とりあえずデータを受け取るだけ受け取って読み飛ばすことが出来るが、
その程度の用途も理解できないのか。

**名前は開発中のものです。** · 2005/08/20(土) 08:48:35

>>134
アンタ自前でローダー書いてんの？
よーやるよ。

**名前は開発中のものです。** · 2005/08/20(土) 11:33:34

>>135
それやろうとデザイナと考えてたら、
デザイナボスが「なに、いい加減な仕事してんだ。てめー！」って激怒したことがある。
まあ、動機が「面倒臭い」だけだからなｗ
ちゃんと１つ１つのモデルにあったボーンいれなきゃね。（それは俺等側の苦労じゃないけどｗ）

>>136
いや、だから、チャンクだから読み飛ばしは楽にできるじゃん。
で、別に受け取る側が想定してないようなデータを受け取ってもしょうがないと思うんだけど。
Ｘファイルのテンプレートは「このファイルはこういう型に基づいて作成されましたよ。」
って意思表示の為だけだと思うがな。

>>137
いや、DirectXに頼ってもいいんだけど、
大して助けちゃくれないっぽいから自前でやっちゃう。

**名前は開発中のものです。** · 2005/08/20(土) 12:19:04

データの形式はテキストでなくバイナリも存在しているわけだが、
後から拡張されたり、独自に埋め込まれた未知のデータを
テンプレート無しでどうやって読み飛ばすのか説明してくれ。
どこがデータ数を示しているのかすら分からないんだぞ？
しかもバイナリの場合、データの終端は自分でカウントしないとどこにあるか分からない。
テキスト形式しかやっていないから、テンプレートの必要性が分からないわけだが、
ごたごた無知を晒す前に圧縮バイナリまで対応してみろ。

**名前は開発中のものです。** · 2005/08/20(土) 12:24:12

結論:自前ファイルフォーマット作って読み込みもシリアライズも自分でやった方がマシ

**名前は開発中のものです。** · 2005/08/20(土) 13:18:11

>>139
そんなムキになんなくても・・

**名前は開発中のものです。** · 2005/08/20(土) 14:20:52

>>139
いや、そもそもＸファイルでバイナリである必用がないでしょ。
結局、吐き出せるツールがないからＸファイルですべてをまかなうことができないわな。
と、すると、わざわざバイナリで出す意味がまったくない。

>後から拡張されたり、独自に埋め込まれた未知のデータを
>テンプレート無しでどうやって読み飛ばすのか説明してくれ。
てゆうか、そんなファイル読み込んだところで受け側で対応できてないんだから意味無いでしょ。
っていうのが俺の主張なんだけど？

テキストだけなら別に読み飛ばすとかそういう問題はどうでもいいしね。

つーかね。Ｘファイルで将来云々心配すること自体ナンセンスだと思うんだけど。
正直、あんまり上手くできたフォーマットじゃないしね。
スキニングに対応しててたまたま吐き出せるツールがＸファイルに対応してるってだけで
それ以上の特典は全く無いわけだし。

**名前は開発中のものです。** · 2005/08/20(土) 14:39:32

受け側が対応していなくても、例えば独自のデータを定義して埋め込み、
MeshViewer等で確認するときに独自のデータは無視していいから、
形状だけ確認したい場合に読み込んでくれなかったら困るだろう。

そもそもテンプレートの存在意義について無知を晒していたから、
その馬鹿さ加減を教えてやっただけの話なんだが、何故そこまでアホなんだ？

X-Fileが合理的かどうかは関係ない。
テンプレートはX-Fileで必用、何故必用なのか分からなかったのは無知だから。
ただそれだけの話なんだが、自分は使わないという言い訳は見苦しい。

**名前は開発中のものです。** · 2005/08/20(土) 14:52:25

>>143
>受け側が対応していなくても、例えば独自のデータを定義して埋め込み、
>MeshViewer等で確認するときに独自のデータは無視していいから、
>形状だけ確認したい場合に読み込んでくれなかったら困るだろう。
これはテンプレートの利点じゃなくてデータチャンクがあるデータならなんでもそうでしょ。

テンプレートの存在意義はさっきから全然説明できてないじゃん。

**名前は開発中のものです。** · 2005/08/20(土) 19:09:58

論点をすり替えるな。
テンプレートが無いとバイナリの場合データが読めないんだと言っているだろう。
利点の話などしていない。

X-Fileではバイナリだとテンプレートが定義されていないと未知のデータが読めない。
もう一度言う。
X-Fileではバイナリだとテンプレートが定義されていないと未知のデータが読めない。
頭の悪いお前のためにもう一回。
X-Fileではバイナリだとテンプレートが定義されていないと未知のデータが読めない。

それを知らずに使い方が分からないと言うから、どういうときに使うか示しているのだが、
頭が悪いにも程がある。

**名前は開発中のものです。** · 2005/08/20(土) 19:28:00

テンプレートの利点は汎用パーサを書いたときなどに、
たとえば小数点だったら小数点のデータがパーサから、
簡単に引き出せるように作れることです。
あらかじめテンプレートの形式通りにデータの固まりを作っておけば、
受け取り処理はその固まりから、自分の確保したメモリー上にコピーするだけで済みます。
その場所に応じていちいち読み込みのコードをカスタマイズする必要が無くなります。

**名前は開発中のものです。** · 2005/08/20(土) 21:04:37

昔カスタマイズをカニタマイズとギャグで言ってみたら・・・

**名前は開発中のものです。** · 2005/08/20(土) 22:00:10

>>145
それじゃ、テキストのＸファイルの冒頭に定義してあるテンプレートはやっぱり無駄なんだな？

**名前は開発中のものです。** · 2005/08/20(土) 22:37:07

テキストの読み込みだけしかやっていないのが井の中の蛙だと存分に理解できただろう。
自分に必要なければ他人が必用とするかどうか考えず、勝手に必要ないと思いこんで無知を晒す。
頭の悪い奴はこれだから困る。

**名前は開発中のものです。** · 2005/08/20(土) 23:49:25

>>149
結局、テキストのＸファイルの冒頭のテンプレートは全く意味がないんでしょ。
ありそうにいうなよ。

**名前は開発中のものです。** · 2005/08/20(土) 23:59:46

意味を付けるかどうかはパーサの実装次第。
X-File自体にはテンプレートが必用で、テキストを読み込んでいただけの井の中の蛙には必要性が分からなかった。
ただそれだけの話。
本当に頭が悪いな。

**名前は開発中のものです。** · 2005/08/21(日) 00:06:03

>>151
アンタDirectX関連スレで
よくスレ荒らしてる人？

**名前は開発中のものです。** · 2005/08/21(日) 00:06:13

>>151
テキストのＸファイルのは意味無いだろ。
テンプレート部分まるまる削除したってもんだい無いぞ。
必用ねーじゃん。

**146** · 2005/08/21(日) 00:15:09

テンプレートの使い方に関してはきちんと書いたのですが、
スルーされているのは何故でしょう？
テンプレートの仕組みがないとデータを読み出すのが非常に不便ですよ。

**名前は開発中のものです。** · 2005/08/21(日) 01:29:04

>>154
不便もなにも、そもそもＭＳの提供するtiny.xからいって

template XSkinMeshHeader
template VertexDuplicationIndices
template SkinWeights

の３つしか定義されてないんだよね。
こういう中途半端なのもあれば、
テンプレートの定義がまったく無いＸファイルも存在するわけだしね。

それともバイナリのＸファイルの話してる？

**名前は開発中のものです。** · 2005/08/21(日) 03:57:01

わたしのためにカスタムテンプレートを書き込む時のことも考えてあげてッ

**146** · 2005/08/21(日) 10:19:59

>>155さんはご存じないのかもしれませんが、標準のテンプレートは、
SDKのヘッダファイル中にあらかじめ定義されています。
それを利用しているプログラムに関しては、
テンプレートがファイル中に存在しなくても問題ありません。
ですのでSDKのサンプルをご覧になれば分かると思いますが、
テンプレートを利用していないわけではありません。

また、カスタムテンプレート以外にも理由として、
X-Fileの初期はスキンに関するパラメータは存在しませんでした。
今後のバージョンアップで新たに標準仕様としてテンプレートが追加されるとも限りません。
しかしテンプレートに対応した読み込みのコードを書いておけば、
それらを利用するプログラムを書くのが容易になります。

**146** · 2005/08/21(日) 10:37:26

D3DXの場合、libだった昔のバージョンだとよく分かるのですが、
D3DRM_XTEMPLATESがリンク待ちの状態になっています。

**名前は開発中のものです。** · 2005/08/22(月) 02:35:08

絶対役に立たないもんの擁護によくそんなに必死になれるなｗ

まあ、それは置いておいて、今週の報告だな。
ちなみにそろそろ「チラシの裏にでも書いてろや」とか言われそうだが、
俺のレポートが俺と同じことをしようと考えてる奴の役に少しでも役立ったらいいと思う。

まあ、あんまり進捗具合がよくないのは花火だとか祭だとか色々あったせいだろきっと。

今週はメッシュデータを読んでみたが、こいつもすんなり読める形じゃ保存されてねーな。
一番面倒臭いところがマテリアルとその他のデータの関係だな。
マテリアルが複数あるタイプのメッシュだとマテリアルごとにわけねーと駄目だよな。これ。
使うシェーダも別かもしんねーし。
なんだって、いっしょに入れてあんだよ。
メッシュごとにマテリアル１つにして、マテリアルが別のデータは別メッシュにしてくれればよかったのに・・・。

**名前は開発中のものです。** · 2005/08/22(月) 03:11:57

XFileはDX9でまたいくつか拡張されたが、
それに関する情報、サポートは無いに等しい。
(本来ならrmxfguid.h、rmxftmpl.hの拡張を用意するべきだが
そんなものはない。)
MSの意図としては、XFileはMSの用意するフレームワーク又は
D3DXMesh経由で使って欲しいんだろう。
はっきり言って今がXFileを捨てる時期だな。
WGFが正式に発表されたら、一緒に代替フォーマットも発表されそうだしな。

**名前は開発中のものです。** · 2005/08/22(月) 05:24:18

>>160
Ｘファイルスレでいうのもなんだが、
俺が考えるにその頃にはゲームＰＧが描画出力ルーチンに関していじることは
ほとんど無いとおもうぞ。
シェーダなんて所詮モデルに貼り付けるか、画面に効果入れるかぐらいなのに、
汎用化するのにいつまでかかってんだよ的なものは今の時点ですらある。
誰もが感じてることだと思う。

国内でもコンシューマの方でゲームエンジンを積極的に使う動きがでれば、
当然、ＣＧＷＯＲＬＤなんかを通して、ＰＣの方でもみんなに
「そういうものを使えばこんな苦労なんざしなくてすむ」的なことが行き渡るでしょ。
いままで、そういうことを阻んできた原因にＰＣのスペックの問題があるけど、
ＭＳの新ＯＳがＤｉｒｅｃｔＸ９標準装備ということでこれは一気に解消されそうだ。
なんとノートＰＣの方でもすでにＡＴＩ、ＮＶＩＤＩＡ共に新ＯＳ対応済み。完璧。

問題は新ＯＳが普及して、ゲームエンジンでメジャーな物が選定されるまで時間がありそうだということ。
（もちろん国内でという話ね。日本語のドキュメントがあって、扱いやすくて云々）
＃あ、ＷＧＦなんて当然スルーね。もう、そういう時代じゃないだろ。

なんで、それまでの間の暇つぶしとしてＸファイルでも読んでモデル表示して
なんか記念に（？）フリーソフトのゲームでも一本出せたらいいな。とか考えてるわけ。

**146** · 2005/08/22(月) 08:22:20

>>159
理由をきちんと説明されても目を閉じ、目をふさぎ、
ひたすらテンプレートの存在を否定比続ける。
自分が間違えたことを間違えたと認められないとは憐れすぎる。

今回もまたアホなことを言ってるし。

**146** · 2005/08/22(月) 08:28:38

今回も言わせて貰えば、マテリアルごとにメッシュが別れていないのは、
分ければ重複頂点が増えてデータが無駄に増えるからです。
ファイルに記憶されているデータはどちらにせよ、
座標やUV等の組み合わせでデータそのものを再構築する必用があり、
マテリアルの割り当てだけ組み合わせを作っておいても何の意味もありません。
どちらにしても読み込んだ後に最適な形に直す必用があります。

といってもテンプレート同様、また他人の言うことには耳を塞ぐんだろうなあ。
こういう人ってはっきり言って成長しない。

**名前は開発中のものです。** · 2005/08/22(月) 15:35:52

いい加減放っておけ。こういう物事の価値をさっさと決めて、
それに関わる連中を馬鹿にする輩には関わらないほうが良い。

**名前は開発中のものです。** · 2005/08/23(火) 00:29:35

>>163
>マテリアルの割り当てだけ組み合わせを作っておいても何の意味もありません。
おいおい、たかが重複頂点ごときでマテリアルごとにわかれてるメッシュを
わざわざくっつける方がどうかしてるだろ。
これは俺の経験だけど、マテリアルごとにわかれてるモデルは扱いやすいよ。
何の意味もありませんとかいってるけど、後、どんな手間を想定して何の意味も無いって言ってるの？

それとＸファイルって重複頂点気にするほどファイルサイズって重要か？
もし、こんなこと気にしていまのフォーマットなら制作者のセンスないと思う。

**名前は開発中のものです。** · 2005/08/23(火) 01:18:24

>>161
どうだろうねぇ、
例えば、3DAPIの一個上のシーングラフものとか
いろいろ出てるけど、あんま流行ってなさそうだしねぇ。

**名前は開発中のものです。** · 2005/08/23(火) 21:23:25

>>165
重複頂点を気にする必用がなければ、インデックスすら必要なくなる。
もう支離滅裂で見てられない。
どこにマテリアルごとにメッシュを切り分けて出力するファイルフォーマットがあるんだよ？
少なくともMAXやLWに標準で出力できる形式にそんなフォーマットはない。

そもそもファイルはあくまで保存用データであって、レンダリング直前データではない。
扱いやすいも何も、必用ならデータを自分で並び替えればいいだけだし、
その程度のことで、わがままとしか思えない自分勝手な文句を書き込む理由が分からない。

**名前は開発中のものです。** · 2005/08/23(火) 22:39:35

>>167
>もう支離滅裂で見てられない。
はぁ？支離滅裂なことなんて言って無いじゃん。
君がそういうことにしたいだけでしょ。

だいたいここまでの流れだって、俺が
「面倒だねぇ」
っていってるところに
「それはお前が馬鹿だから」
ってつっかかってきて
結局、君の変なアドバイスで何１つ特になったことは無いよ。
で、しまいにゃ

>そもそもファイルはあくまで保存用データであって、レンダリング直前データではない。
この↑発言。
「そうなってるんだから仕方がないだろ。文句ばっかいってうるせーんだよ。」
とでもいいたいのだろうか？

既存のフォーマットの無駄なところを探して、もっといい方法を考えるとか絶対なさそうだね。君。
すでにあるもので思考停止してるみたいだし話しても無駄だし。
なんの利益にもならないからもう消えていいよｗ

**名前は開発中のものです。** · 2005/08/23(火) 23:16:48

>>167その他は中傷が多すぎるし、
とにかく言い争いに勝つことだけが目的になってるし
もういい加減やめて欲しいんだけど。

**名前は開発中のものです。** · 2005/08/23(火) 23:52:08

>>168
結局無駄なところを探すどころか、無駄な物を増やそうとしているし、
＞もし、こんなこと気にしていまのフォーマットなら制作者のセンスないと思う。
マテリアルごとにメッシュの切り分けているファイルフォーマットの方が、よっぽどセンスが無い。
そうでなければならない理由があるならともかく、面倒だからというのは理解に苦しむ。

そもそも新しいフォーマットを作ろうにも、例えばMAXでプラグインを作るとすると、
メッシュに対してマテリアルが割り当てられているデータが入っているので、
結局出力時に並び替えるか、読み込み時に並び替えるかという違いでしかない。
面倒は変わらないのに、わざわざ無駄なデータが増えるファイルを作る必用がない。
読み込む人のためとか主張するかもしれないが、そういう部分が面倒な人のために、
LWのように読み込み用のソースコードを提示するという手段もある。
重複データの固まりのようなフォーマットを作る必用はない。

そうなった理由がきちんとあるのに、それを考えようともせず、
他人のフォーマットにセンスがないと言い放つ。
それがもっといい方法を考えるということなのか。

**名前は開発中のものです。** · 2005/08/23(火) 23:55:26

何このスレ('A`)

**名前は開発中のものです。** · 2005/08/24(水) 00:11:58

>>170
はい！先生！
>メッシュに対してマテリアルが割り当てられているデータが入っているので
こんなデータ必要なら、あらかじめマテリアルごとにメッシュをわけておけばいいのではないでしょうか？

それに余計なデータ云々の話をするなら、Ｘファイルの法線データの存在も疑問が残ります。
なぜ、こんなものついてるのでしょうか？
その場で頂点から生成すればいいのではないでしょうか？

**名前は開発中のものです。** · 2005/08/24(水) 00:23:55

>>172
＞それに余計なデータ云々の話をするなら、Ｘファイルの法線データの存在も疑問が残ります。
＞なぜ、こんなものついてるのでしょうか？
＞その場で頂点から生成すればいいのではないでしょうか？

これ、もう致命的なんだが。
ポリゴンの仕組みすら理解していないのだから、話が通じないのも当たり前。
モデルデータを読み込む以前の知識が足りていない。

**名前は開発中のものです。** · 2005/08/24(水) 00:53:46

>>173
どうせ、鋭角なエッジがどうのこうのっていいだすんだろ？

さらに、こんなどうでもいいことで「致命的」ね。
あいかわらず、人を馬鹿にしないと会話ができないのか。

**名前は開発中のものです。** · 2005/08/24(水) 01:30:11

だな。面白い議論なのにもったいない。
発言内容から察するにいい大人なんだろ。
もう少し冷静になれ。

**名前は開発中のものです。** · 2005/08/24(水) 01:48:55

>>172
法線は、接線・従法線に垂直であるってのはその通りなんだけど
必ずしもそうでなければならない訳でもない。
そこら辺モデル作った人が好き勝手やれるようについているんだろう。

**名前は開発中のものです。** · 2005/08/24(水) 01:54:26

>>176
じゃあ、好き勝手やった部分だけ保存しておけば容量減るじゃん。

俺は有益な人間だから今の話がようわからん人のためにリンクまでとってきちゃうよ。
http://hell.razor.jp/column/09.html

**名前は開発中のものです。** · 2005/08/24(水) 01:57:26

自分的に疑問なのはSkinWeightsテンプレートのmatrixOffset。
これ何の為にあるんだろうか？
最初、これが無いと回転できないからと思ってたけどそんなことないよねぇ。

また、XFileから得られる情報だけで
それぞれのボーンの始点-終点(間接から間接)の座標が得られる方法って
どうやればいいんだろうか？

**名前は開発中のものです。** · 2005/08/24(水) 02:02:01

XFileで定義してるのはあくまで面法線のみだからね。
そっから先はローダーしだいよ。

**名前は開発中のものです。** · 2005/08/24(水) 08:22:51

>>177
つまり法線情報が必要ないといった間違いを認めるというわけだね。
そもそも法線が必用なのは鋭角なエッジの場合ではなく、面に対して対応する法線が不揃いの場合。
何故鋭角なエッジという言葉が出てくるのか意味が分からない。
好き勝手に法線を生成する以外にも、球体等を普通に扱っていれば>>172のようは発言は出てこない。
また法線に関してはスムーシング情報を保存する形式のフォーマットも存在するが、
法線とスムーシング、どちらかの情報は必要になる。

ちなみに紹介している内容は、データを加工する話で、
法線が存在しない場合の対応措置ではなく、今回の件とはまるで関係がない。

>>178
通常通りフレームの階層をたどってボーンの行列を作ったら、
ウエイトが割り当てられているメッシュを出力する前に、matrixOffsetに掛けて使う。
それがメッシュ側のフレームの行列のかわりをするので、元からあるメッシュのフレーム自体は無視する。

**名前は開発中のものです。** · 2005/08/24(水) 17:15:01

そもそも法線がオプションになっているのは無視ですか。

**名前は開発中のものです。** · 2005/08/24(水) 19:04:39

データそのものが必要なければ出力しないのはあり。

今言っている話は、法線が無かった場合、スムーシングに関する情報も無しに、
モデルデータを作った人の意図通りに復元することが出来ないということ。

**名前は開発中のものです。** · 2005/08/24(水) 20:12:44

>>180
>面に対して対応する法線が不揃いの場合。
これって具体的にどういう場合なの？
球体でそんな箇所あるっけ？

**名前は開発中のものです。** · 2005/08/24(水) 20:24:17

>>180
わかった。
面に垂直ではなくて球の面に対して垂直な法線を作るっていってんのね。
で、それはポリゴンだけの情報では作れない法線だと。

**名前は開発中のものです。** · 2005/08/24(水) 20:47:05

>>180
>つまり法線情報が必要ないといった間違いを認めるというわけだね。
認める認める。

>ちなみに紹介している内容は、データを加工する話で、
>法線が存在しない場合の対応措置ではなく、今回の件とはまるで関係がない。
正直、すまんかった。

>好き勝手に法線を生成する以外にも、球体等を普通に扱っていれば>>172のようは発言は出てこない。
これはどうだろね。
俺みたいにただモデル読んでそれっぽく表示できてりゃ満足な奴だと
ほとんど気にしないと思うけどね。

**名前は開発中のものです。** · 2005/08/24(水) 22:22:12

ということで煽りすぎたのを反省して消えることにする。
サラバ。

**名前は開発中のものです。** · 2005/08/30(火) 00:41:08

つーか、まだ読み込みやってるんだけど、Ｘファイルって面倒だな。
やっぱり、面倒なネックがマテリアルごとにわかれてないメッシュと
描画直前まで加工されてないデータだな。法線とかウェイトとか。
頂点ごとにしなきゃなんねーし。
いままで、誰もさわんねーわけだよ。コレ。

これのおかげで一度バラしながら読み込んでデータ加工して
描画しやすいデータに吐き出すってことをせにゃならん。

そうするとわざわざＸファイルを読み込む意味ってなに？
って疑問がでてくるわけだ面倒臭ぇ。

やっぱり、描画直前データであるべきだったよなぁ。
仮にもリアルタイム専用なわけだし。（ゲーム目的なんだろ）

**名前は開発中のものです。** · 2005/08/30(火) 01:39:19

とりあえず、わかったこと

・スキンメッシュの描画に必用なデータは、
　　①１つのメッシュに影響するボーンのマトリクス（メッシュに対して７本のボーンが影響するときは７つ）
　　②ボーンの１つの頂点への影響具合（ウェイト：頂点とボーンでセットで１ついる。
　　　　つまり、１つの頂点が複数のボーンに影響があるときはウェイトの数が増える。
　　　　ウェイトは頂点ごとに影響するボーンの数だけ必要。）
　　③頂点とセットなボーンのインデックス（つまり、①でこの頂点に影響するボーンのインデックス）

だ。多分。

んで、よくわかんねーの。

・XSkinMeshHeaderの上２つが何のデータなのかわかんね。
　必要あるのかどうなのかもいまのところわかんね。

**名前は開発中のものです。** · 2005/08/30(火) 01:48:47

>>187
Xライブラリのメッシュクラスには、オプティマイズとかメンバ関数があり
貴方の言う所の描画直前データにする機能があるよ。

他の3Dソフトのフォーマットでも、そうだけど
そのフォーマットはそのソフトで使う思想設計のフォーマットであって
自分の必要な内容のフォーマットだとは限らない。
それを、自前で自分の欲しい情報を取得したり、生成したりする手間で
文句言っちゃいかんでしょう…

**名前は開発中のものです。** · 2005/08/30(火) 03:24:45

＞・XSkinMeshHeaderの上２つが何のデータなのかわかんね。
＞　必要あるのかどうなのかもいまのところわかんね。
これはまあ参考用で要らん子だな。

**名前は開発中のものです。** · 2005/08/31(水) 01:07:24

>>189
そうはいってもだな。
もし、Ｘファイルplus（仮）なる描画直前のデータがあったりしたら、
俺は今頃Ｘファイル（通常バージョン）なんかに要はないぞ。

>>190
おお、やっぱ、いらんデータ？
ヘルプも書いてある意味がよくわからなかったな。俺は。

まあ、それはいいとして、今日の成果。
よくわからんことだけで終わってしまった。

・Ｘファイルってメッシュごとにマテリアルあるけど、モデル単位でみてマテリアル同士が重複してる場合って
　同じマテリアルであるとどうやって判断すればいいんだろ？
　＃つまり、複数のメッシュで１つのマテリアルが呼ばれてる場合ね。

**名前は開発中のものです。** · 2005/08/31(水) 11:44:03

てゆーかなんでXファイル弄ってんの？
手持ちのツールがXファイルしか出力できないとか、
D3DXで楽したいとか以外に選択する理由がないと思うけど。
てゆーか3Dモデルのフォーマットなんてどれ選んでも面倒くさいけど。

マテリアルの共有に関しては、トップレベルに名前付きのMaterialを吐いて、
各MeshのMeshMaterialList内ではその名前を参照することはできる。

個人的にはテンプレートの型毎に参照用の名前空間が
わかれていないのがXファイルの一番嫌いなところ。

**名前は開発中のものです。** · 2005/08/31(水) 12:54:34

やっぱこれからはCOLLADAなのかなぁ。
XMLの勉強にもなるし、俺はこっちの対応を考えてみるかな。

**名前は開発中のものです。** · 2005/09/01(木) 00:36:35

>>192
いやー、なんでＸファイルって手を出しづらいのかと思ってさ。
ずいぶん前からあるし、今頃、直でいじってる奴の１人か２人ぐらいいてもいいだろうと。
つーか、構造自体よくわかってねぇとやっぱりマイクロソフトの用意したクラス使っても
結局は何もできずに終わるだろうと考えた。

で、今日の報告。
わかったこと

・ボーンについて意識しとかなきゃいけないこと云々。
　　①モデル全体にあるボーン
　　②１つのメッシュに関連するボーン
　　③１つの頂点に関連するボーン
　　④アニメーションで意識するのは①
　　⑤シェーダで意識するのは②と③
　　⑥シェーダで渡す必要があるのは②（マトリクスをいくつ使うか？とかそういう話）
　　⑦Ｘファイルを一度すべて読んだ後に②の情報を出さないといけない（メンドー）
　　⑧頂点情報で必要なのは③

わからんこと
・実際にアニメーションするときってなにを動かすんだろうか？
　アニメーション情報に基づいてすべてを動かすのか？
　その場合、元のフレームの情報だのってのはどこへいくんだろうか？
　ボーンとフレームが混在してるモデルってのは無いのだろうか？

**名前は開発中のものです。** · 2005/09/02(金) 01:53:56

今日は、マテリアル読んだ。

問題なぞおこるはずもなく読めた。
しかし、毎度毎度思うんだけど、
DirectXの方だとアンビエント、スペキュラ、エミッシブって簡単だけど
モデリングソフトの方だと設定項目はこんな単純じゃなくて、
もっとわけわからん名前のパラメータがたくさんある場合がほとんどなわけだが、
一体、この辺のパラメータってどうなってるんだろうね。
俺等はモデリングソフトにできるだけ近くなるようにしてほしいわけだけど、
なんか読み込んでみるとイメージと違くていつもメタリックだよなｗ

**名前は開発中のものです。** · 2005/09/02(金) 03:33:36

だからXファイルは欠陥品だとあれほど・・・

**名前は開発中のものです。** · 2005/09/02(金) 03:50:11

やっぱり皆LightWaveとかなわけ？

**名前は開発中のものです。** · 2005/09/02(金) 12:53:05

>>195
XFileは元はDirect3DRM用のフォーマットだよ。
CGソフトよりゲーム寄りの仕様なのはむしろ当然だよ。
画像がメタリックなのは、君のエンジンのライティングモデルの所縁だろ、
BRDFにでもすればまた違ってくるよ。

**名前は開発中のものです。** · 2005/09/02(金) 23:29:57

>>198
BRDFとはなんぞや？と思ってぐぐってみたら、
t-potさんのところのBRDFに当たったけど、メタリック化にさらに磨きがかかってたぞｗ

つーか、今のところ、物体にはっつけてるシェーダは
どれも（といってもバンプ、環境、屈折ぐらいしかないけどｗ）メタリックだぞ。
シェーダをかけるとメタリック化が進むのは俺だけか？

**名前は開発中のものです。** · 2005/09/02(金) 23:54:45

>>199
BRDFっつーのは、物理的に本物っぽいライティングモデルのことだ。
よくフレネル係数って聞くだろ、湖面を真上から見ると底が透けて見えるけど
水平に近い角度で見ると周りの風景が反射して見えるっていう、これもBRDFに含まれる。
BRDFの鏡面反射成分の式には面の粗さとその方向が係数として含まれる。
この粗さに大きい値をとれば、ガサガサして金属っぽくならなくなるわけだ。

**名前は開発中のものです。** · 2005/09/02(金) 23:58:55

つっても俺もまだ実装したことなくて
ギラギラメタリックのままだけどな。
こんなもん素人ゲームにはいらねーよ。

**名前は開発中のものです。** · 2005/09/03(土) 00:47:24

>>200
解説乙。
しかし、俺はそのシェーダに関しては、
苦労の割りにあまり大きな効果がえられるもんじゃないと思ってるんだな。

とりあえず、汎用性が高くて、視覚効果が高いものふつーに扱えるようにしたいんだよね。
まあ、バンプ、環境、屈折あたりをしっかり作る方が視覚効果大きいと思うんだよね。

で、スキンメッシュも使いながら、こういうもんも使えるようにしようとか考えてるわけだｗ
あと、アルファ、ＵＶアニメーション、テクスチャアニメーションあたりをサポートできれば、
後はデザイナがなんとかしてくれるっしょ。とか、考えてる。

**名前は開発中のものです。** · 2005/09/24(土) 09:55:28

**名前は開発中のものです。** · 2005/09/29(木) 02:09:56

９月の頭から停滞状態と思いきやプログラム自体は進んでたりする。

Ｘファイルのデータの読み込みと、リアルタイムデータへのデータの加工自体は終わってて、
後は、実際にゲームに使うときにどうやってデータを持つかってところで悩んでいるわけだが。
＃つっても、実際マテリアルごとにデータわけて、アニメーションデータを取得するまで結構時間かかったぜｗ
＃この部分は面倒なだけで、特筆するべきことはないな。

悩んでる問題は２つ。

①ゲームを実行中のときのデータの持ち方はどうしたらよいか？
②ファイルフォーマットはどうやってもったらよいか？

ってので①が決まれば、自然と②も決まるだろうと考えてる。
で、昔の俺ライブラリだと、どうもノードクラスにノードクラスとメッシュクラスを持たせて、
管理してる（ノードをツリー状に管理してそこにメッシュデータがひっついてる）っぽいが、
これって設計悪いよな。ウンコっぽいなｗ
＃つまり、アルファを変えようとしたら、親からツリー状に辿ってかなきゃならんわけだ。
なんで、それは止めて、モデルクラスにノードクラスとメッシュクラスをそれぞれ複数持たせようと考えてる。
まあ、ツリー構造は描画するときどうしても必要になるわけだが、それはモデルに持たせることにしよう。
この部分はモデルの構造をそのままクラスの構造に反映させてしまうと無駄に複雑になる希ガス。

**名前は開発中のものです。** · 2005/10/02(日) 21:35:45

とりあえず、
行列パレットの番号と対応ボーン番号を固定にしちゃって
D3DFVF_XYZB4|D3DFVF_LASTBETA_UBYTE4|D3DFVF_NORMAL|D3DFVF_TEX1
で、ダーってデータ埋めちゃう。
アニメーションブレンドとかの対応を知らんです、な１ファイルはどうでしょう親方。

**名前は開発中のものです。** · 2005/10/03(月) 17:01:16

俺は1オブジェクトにMeshは必ず1つだけという制限をつけてるよ。
1つのXFlieに複数Mesh（アニメーション付き）がある場合は1つのSkinMeshに変換する。
そしてFrameクラスとMeshクラスに分けて、ツリー構造はFrameに持たせる。
動作としては、最初Frameクラスにアニメーション時間を与えて行列配列を得る。
それをMeshに与えてSkinningして表示って感じ。

**名前は開発中のものです。** · 2005/10/04(火) 12:29:47

>>206
そんなことすると、帽子とズボンのシェーダー別にできなくなっちゃったり、
１つのメッシュに関わるボーンの数が増えちゃって大変だから。
無駄にまとめるのはｲｸﾅｲ！

**205** · 2005/10/04(火) 17:18:40

すんません。>>205こんなん揺れる木ぐらいにしか使えませんですハイ。（パンチした後にキックできねー）
とりあえずtiny形式が一番だと思うけど、アニメーションマトリックスの部分は
あらかじめ行列を積算するとか最適化できそうな希ガス。

**名前は開発中のものです。** · 2005/10/05(水) 02:08:06

>>207
そこは妥協。
世にある著名なゲーム、例えばHALOとか
1モデル1シェーダでやってるし全然OK。
俺なんか1モデル1メッシュ1シェーダ1マテリアル1テクスチャセットだよ。

**名前は開発中のものです。** · 2005/10/05(水) 02:26:44

妥協しすぎだろw

**名前は開発中のものです。** · 2005/10/05(水) 09:06:55

>>209
噴いたｗ
開発しづらいなｗ

**名前は開発中のものです。** · 2005/10/05(水) 17:42:33

まぁでも分かる気がする。
doom3とかも極端にまとめてるよね

**名前は開発中のものです。** · 2005/10/05(水) 18:00:02

>>212
アメ公いい加減だから。
タイトル画面（一枚絵）のテクスチャのアスペクト比が狂ってても全く気にしない種族だからな。
かなり前だけど、800X600の画面で512X512のテクスチャ平気で使う糞野郎だったじゃん。
少なくとも日本じゃ商品でこれは無い。

**名前は開発中のものです。** · 2005/10/05(水) 21:59:20

>>213は3Dでシーンを構築するテクスチャの
解像度バラバラ状態が気持ち悪い人に違いない。

**205** · 2005/10/06(木) 11:35:47

D3DFVF_XYZ|D3DFVF_NORMAL|D3DFVF_TEX1をメッシュデータで
D3DFVF_B4（こんなんないけど）|D3DFVF_LASTBETA_UBYTE4と諸行列（事前に掛けとく）をアニメーションデータで
もっておけば、別アニメーションの再生いけますた。
再生までの手続き少なくてウマーです。最下層処理じゃないからメリット全然ないけどーっ

**名前は開発中のものです。** · 2005/10/07(金) 22:01:36

>>213
ワロタ　たしかに米国のゲームって、しょうもないアクションとかは
こっているけど、そういう点は、すげーやっつけ仕事な気がする。
グラフィックやサウンドばっか金かけて、ゲーム自体がつまらないとか
よりは、よっぽどマシだけど。

**名前は開発中のものです。** · 2005/10/07(金) 22:05:26

逆に日本のゲームは変なトコロに懲りすぎて、
肝心のゲーム自体の面白さがやっつけだったりなｗ

**名前は開発中のものです。** · 2005/10/08(土) 10:24:43

>>217
ゲーム自体のやっつけ度合いは向こうのが遥かに上だと思う。
こっちはゲームの開発者が「新しいゲームを作らないと売れない」とかいう変な暗示にかかってるから。
＃つってもＳＣＥの糞ゲーが売れ続けたことはないんだけどねｗ

**名前は開発中のものです。** · 2005/10/08(土) 13:11:22

向こうのゲームは、バランスとかユーザビリティとかがユーザー置いてきぼりの
ものが結構ある。

**名前は開発中のものです。** · 2005/10/17(月) 22:43:30

おお。こんなスレがあったなんて。
自分も、グダグダと思いつつXFileでやってみてるんですが、
みなさん半透明のポリゴンを後からZソートする時ってどうしてます？

せっかくマテリアル単位でサブセットになってくれてるんで、
半透明なマテリアルに対応するサブセットだけ半透明レンダリング
用キューに積んで、あとからソートしようと思ったんだけど・・・

サブセットに対応する頂点を効率良く引き出せないから、
今はXファイルを読む時点で半透明を含むメッシュは全部
後からレンダリングしてるんだけど・・・。
結局自前の処理でポリゴン単位でZソートしないといけないし、
これが結構な計算コストになってるんで、他の人はどうやって
効率的に半透明を含むモデルを扱ってるのかな～と常々疑問に
思ってます。

サブセットのポリゴンをZソートしながら描画してくれるサブルーチンが
DirectXにあれば、多少重くても楽だから使うんだけど・・。今は自分で
組んだ上に重いんで、凹みも倍増になってしまってるし。

マテリアルが半透明で無くっても、テクスチャがアルファを含んで
たりするんで、結局どのテクスチャファイルがアルファを含むかの
情報を別に持たせちゃってるし・・。

**名前は開発中のものです。** · 2005/11/04(金) 22:08:12

これだけ開発してる人がいるのに何故３Dゲームがほとんど見当たらないのはどうして？

**名前は開発中のものです。** · 2005/11/05(土) 21:49:29

>>221
つか、お前があるところにいかないだけ。
コミケとかでも３Ｄゲーム増えてる。
シューティング多いけどｗ

**名前は開発中のものです。** · 2005/11/05(土) 21:52:11

>>220
ポリゴン単位のＺソートなんてかけてない。から速い。
絵的に矛盾はでるけど、その分派手にする。

**名前は開発中のものです。** · 2006/01/18(水) 20:17:29

あげてみたらどうなる？

**名前は開発中のものです。** · 2006/01/19(木) 06:32:36

OpenGLで再生できてなんぼ

**名前は開発中のものです。** · 2006/01/22(日) 12:05:55

２バイト以上の値を１０進数に変換したいんだけど
どんな方法がいいですか？

**名前は開発中のものです。** · 2006/01/22(日) 12:27:01

珍妙な質問ぢゃな
コンピューター内部では１６進数も１０進数もビット列な筈ぢゃが

**名前は開発中のものです。** · 2006/01/22(日) 14:17:31

誤爆ですたすまそ

ちなみに汗んﾌﾞﾗの話

**名前は開発中のものです。** · 2006/01/22(日) 15:55:24

文字列に変換したいと言うことなら言葉が足りないし、
そういった前提条件を説明する努力をしないから話がややこしくなる。

**名前は開発中のものです。** · 2006/01/22(日) 17:45:04

BCDにしたいって事なんか？意味が分からん。

**名前は開発中のものです。** · 2006/01/22(日) 22:09:22

8ビットアセンブラ知らない人の為に説明しとくと、
・加算、減算、シフト以外の演算は出来ない
・使える変数は１バイト
これで２５６以上の値を１０進数で表示するとなると
ちょっと面倒なわけよ

**名前は開発中のものです。** · 2006/01/22(日) 23:00:08

＞8ビットアセンブラ知らない人の為に説明しとくと、
知らないも何も>>226のどこにそんな条件が書いてあるのか、超能力者キボンヌされても分かるわけがない。
それから8ビットCPUだからといって、乗除算が出来ないとは限らない。
CPUの種類まで超能力で当てさせるつもりか？

**名前は開発中のものです。** · 2006/01/25(水) 07:03:47

っていうか、表示かよ。文字列変換じゃねーか。
しかも、Z80あたりで例題ごろごろしてるだろ。面倒でも何でもねーよ。
BCDなら条件によっては面倒だけど。

>>232
まあ、8bitCPUなら無い場合がほとんどなので、乗除算は
自分でライブラリ作るけどね。

**名前は開発中のものです。** · 2006/01/25(水) 11:13:11

いやいや、誤爆なんだし、8ビットアセンブラスレなら226で通じるんじゃね
そういうスレが有るのかは知らないけど