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/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で通じるんじゃね
そういうスレが有るのかは知らないけど

**名前は開発中のものです。** · 2006/01/26(木) 06:41:21

いや、普通に、意味がわからんだろ。16itだろうが、32bitアセンブリだろうが。
結果の10進数の意味が完全に抜けた記述だし。

**名前は開発中のものです。** · 2006/01/27(金) 05:44:04

実際本スレでは通じたし

**名前は開発中のものです。** · 2006/01/27(金) 06:37:55

必死だな。質問内容が明らかに厨だろ。
条件を整理して書けてないし。指摘されたら「8ビットアセンブリ知らないとわからない」とか、
「本スレでは通じる」とか言いながら情報を小出しにする。いつものパターンじゃねーか。
ついでにいい加減スレ違いって気づけ。

**名前は開発中のものです。** · 2006/01/27(金) 14:17:38

さすがにそりゃおまいがアフォだ。スレ違いも何も誤爆の時点で撤回だろうｗ
以降は訊かれたから質問者も答えているだけだろ。

**名前は開発中のものです。** · 2006/01/28(土) 07:15:09

いい加減、馬鹿はスルーしろっての。ｱﾌｫか。

**名前は開発中のものです。** · 2006/01/28(土) 19:40:53

if　((baka && ++kagen　<　KAGEN_MAX)　||　!baka)　//馬鹿なら加減値より下、または馬鹿ではないなら真
{
　return　Respons();　//レスを返す
}
else　if　(afo)　//ｱﾌｫなら真
{
　return　Respons();　//ｱﾌｫなのでレスを返す
}
//スルー

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

ｘファイル再生するのﾒﾝﾄﾞｲ気がする

**名前は開発中のものです。** · 2006/01/29(日) 08:13:03

プロならD3DXLoadMeshHierarchyFromXなんてオシメ使うな

**名前は開発中のものです。** · 2006/01/29(日) 10:07:49

>>242
なんで？9cになってこいつが出来たおかげでコード量が減ったんだけど。

**名前は開発中のものです。** · 2006/01/29(日) 15:20:36

D3DXLoadMeshHierarchyFromX使ってる、プロじゃないし。
今8.1の時に書いたソースを9cに移植中。

**名前は開発中のものです。** · 2006/01/30(月) 06:48:46

なんか、自作自演で8bitCPUの話をしだしたり、D3DXLoadMeshHierarchyFromXを
オシメ呼ばわりする自称プロが来たり、変な奴が増えたな・・・。

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

ミイラ取りがミイラになるようなことなのにね

**名前は開発中のものです。** · 2006/09/08(金) 14:30:59

こんにちわ。
フレームによってメッシュの表示/非表示ってできるんでしょうか？？
さぱーり謎っす・・・

**名前は開発中のものです。** · 2006/09/08(金) 14:56:08

アニメーションキー４で出来そうな気がするのですが・・・

**名前は開発中のものです。** · 2006/09/09(土) 08:59:50

描画しなければ表示されない。

**名前は開発中のものです。** · 2006/10/13(金) 17:48:55

だまれ。

**名前は開発中のものです。** · 2006/11/09(木) 00:28:42

いや、まったくもってそのとおり
自分で描画方法管理しろ

**名前は開発中のものです。** · 2007/04/04(水) 23:59:37

昔のMeshViewerだけDLってできんかなぁ？
なんかDirectX Viewerだとバイナリで保存しなおす事ができんっぽい･･･。

**名前は開発中のものです。** · 2007/08/22(水) 14:03:44

Xファイルのサンプル置いてあるページってありますか？

**名前は開発中のものです。** · 2007/08/23(木) 00:07:40

http://pc11.2ch.net/test/read.cgi/gamedev/1068375798/116n

**名前は開発中のものです。** · 2007/10/23(火) 21:24:24

Ｘファイルを自分でロードしてアニメーションをさせようとしており、
tiny.x を動かすところまではできました。
そこで、もっと多くのＸファイルに対応させたいと思い、
PANDASOFT にあるサンプルのドラゴンのＸファイルを見ているのですが、
複数の Frame に対する処理がイマイチわからず、悩んでます。
具体的には、最初の Frame で、
Frame {
・・・・・・
Mesh {
・・・・・・
SkinWeights {
"Bone-chest";
・・・・・・
}
・・・・・・
}
}
という感じでメッシュとボーンが定義され、次の Frame で、
Frame Dummy0 {
・・・・・・
Frame Bone-chest {
・・・・・・
}
・・・・・・
}
という感じでボーンの階層構造が定義されているのですが、
２番目の Frame で定義されている Dummy0 という Frame が最初の Frame 内には見当たらず、
この２つの Frame からどのように Matrix を計算していけばよいかが理解できていません。
理解できる方、教えていただけないでしょうか。

**名前は開発中のものです。** · 2007/10/24(水) 10:40:45

階層構造をたどるだけ。

**名前は開発中のものです。** · 2008/10/24(金) 04:44:27

兄弟じゃないの？

**名前は開発中のものです。** · 2008/10/24(金) 05:20:22

ってオレのレスは１年後かよ

**名前は開発中のものです。** · 2008/10/24(金) 11:04:47

なんかすごいいいスレにきた気がする。