X
ドンキーコングリターンズ　バイナリ解析
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
垢版 |
2011/09/11(日) 23:04:03.94ID:aQU6eInG
かつての改造ドンキーを夢見てドンキーコングリターンズのバイナリを解析するスレ
解析っていってもデータの構造を調べるって意味です
0003名無しさん＠お腹いっぱい。
垢版 |
2011/09/12(月) 05:34:30.14ID:LOYWZV8i
ぜんぜん人がこないから、いろいろ説明しとく

ドンキーコングリターンズ(以下DKR)のISOをWiiScrubber,WiiBrowseで展開すると.pakという拡張子のファイルがでてくる
それがDKRのステージファイルで、ステージ構成・画像・モデル・アニメーション等が圧縮されて入っている
.pakファイルは上のWikiのDKDKというソフトで展開できて、データの種類ごとに分類し、抽出やら置き換えができる
で、それらデータの構造を知れば改造が可能になるから、みんなで相談や意見交換しながら解析していこう、というのがこのスレの趣旨
0004名無しさん＠お腹いっぱい。
垢版 |
2011/09/12(月) 05:42:59.77ID:LOYWZV8i
構造というのは、何バイト目に何のデータがあるのか、ということ
データとしてはそのデータに関するデータ(サイズ・オフセット・子データの数など)、識別子、実際のデータ、などがある
一応言っておくと、ファイルのバイナリデータはバイナリエディタで見ることができる
バイナリエディタにはStirlingなどがあり、一応上のDKDKもバイナリ表示機能がある
0005名無しさん＠お腹いっぱい。
垢版 |
2011/09/12(月) 05:47:37.73ID:LOYWZV8i
ちなみに、ISOには.pak以外にもいろいろな拡張子のファイルがあって.rasという音楽ファイルはもうデコード・エンコードが可能
0006名無しさん＠お腹いっぱい。
垢版 |
2011/09/12(月) 06:18:47.35ID:LOYWZV8i
まあ、今の説明だとわからない人も多いだろうから最初のうちは質問にも答えるよ
0007名無しさん＠お腹いっぱい。
垢版 |
2011/09/12(月) 19:01:24.61ID:LOYWZV8i
ファイル上げた方がいいかなー

ひとまずこれからはスプライトのデータを探そうと思う
そもそもスプライトで障害物や敵が管理されてるかわからないけど
0008名無しさん＠お腹いっぱい。
垢版 |
2011/09/12(月) 23:02:22.80ID:LOYWZV8i
それっぽいのを発見した

MREAデータは最初に何かのテーブルがあって、そのあとで名前付きの何セクションかに別れて圧縮データが入ってる
圧縮方法はDeflateでzlibを使って圧縮してあった

MREAファイルは.pakファイルに1つだけ入っているし、セクションの圧縮データを見るかぎり、オブジェクトの配置を管理していると思う。
0010名無しさん＠お腹いっぱい。
垢版 |
2011/09/14(水) 20:28:38.59ID:1sAtctUX
もういいや
外人でも探して解析することにするわ

てか、俺しかレスしてなくてワロタｗｗｗｗｗｗｗ
俺興味ひこうと必死ｗｗｗｗｗｗｗ
0012名無しさん＠お腹いっぱい。
垢版 |
2011/09/14(水) 21:37:28.28ID:1sAtctUX
お、レスだ
一緒に解析しようぜ！

たぶん俺より経験豊富な人もいるだろうけど、やっぱり興味ないんだろうな
0013名無しさん＠お腹いっぱい。
垢版 |
2011/09/15(木) 22:15:07.00ID:upxn5HkE
MREAのテーブルの意味が分からないorz
誰か意味が分かった人がいれば教えてくれ

俺はひとまずUSB Geckoでアセンブリの泥沼をさまようことにした
ステップ実行はできるがサーチがなぜか途中で止まるという…
0014名無しさん＠お腹いっぱい。
垢版 |
2011/09/15(木) 22:44:41.74ID:upxn5HkE
サーチできるようになってた…

テーブルの意味は単純にMREAの解凍データにおけるエントリーのサイズっぽい。
解凍データが何を表しているかはまだわからないけど
0016名無しさん＠お腹いっぱい。
垢版 |
2011/09/16(金) 22:38:02.59ID:7FEL7fEV
はいはい、メモリダンプ見たら分かりました
ここに書きこむと自己解決するみたいだな

ヘッダ部の0x40の数字はエントリ数その1。各エントリは4バイトで、解凍後のデータのサイズを表す。
ヘッダ部の0x44の数字はエントリ数その2。各エントリは16バイトで、用途は不明。サイズらしきデータと、謎の整数値が含まれる。
エントリその2はエントリその1の真下に書きこまれている。
ヘッダ部の0x48の数字はテーブルの下にある文字列の個数。これら文字列はおそらく解凍後のデータの種類を更に細かく分類するためのもの。
WOBJ(World OBJect),COLI(Collision)とかがあるけど、詳細は不明。

ヘッダ部にまだわからない整数値があるからモヤモヤするけど、RASファイルの場合はわからないのを適当に0で埋めても正常に動作したから
適当にやって大丈夫かもしれない
ひとまず圧縮データの詳細を調べることにしようと思う

解析を手伝ってくれる奴はいつでも歓迎
0017名無しさん＠お腹いっぱい。
垢版 |
2011/09/19(月) 08:01:09.44ID:lw6oFBad
解析をしていてずっと思っていたのが、このゲームはいろいろな制御にスクリプトを使っているのではないかということ
文字列らしきデータがところどころ格納されているし、PARTやらCSKRはほとんど文字列で構成されている(どうもこれらの場合はプロパティを設定しているっぽいが)
MREAの解凍データにも多くの文字列があった
ただし、デバッグ用の文字列かもしれないが
0018名無しさん＠お腹いっぱい。
垢版 |
2011/09/19(月) 22:50:32.34ID:lw6oFBad
俺は>>11だけが支えで解析をしている

解析には直接関係ないが、.NET用zlibの"zlib.NET"が不具合持ちで自分でzlibのラッパーを作ることにしたわ
あんなのがいかにも正当な.NETにおける実装だぜ、って言ってるみたいなのが悲しい
0020名無しさん＠お腹いっぱい。
垢版 |
2011/09/21(水) 20:41:12.48ID:B4pJ8P9C
やっとまともな文章のレスが…
はい、がんばります
でも、一緒に解析していいんだよ？

zlibの使い方になれるまで手間取ったがラッパーはできた。
引き続きMREAの解析を続けようと思う
0022名無しさん＠お腹いっぱい。
垢版 |
2011/09/22(木) 11:35:06.08ID:qeaSHw1A
MREAを解凍して先頭にあるエントリの詳細
0x0　子エントリ数
子エントリの詳細
0x0　サイズ
0x4　常に4？
0x8、0xc　常に0？
0x10　常に0xF0F?
0x14〜0x18　パディング
以下文字列と値
文字列は予約語的な役割をしているらしく、次に続く値はその予約語に対応するものでなければならない

文字列の中身としてはPASS,DIFF,DIFFB,CLR,ENDなどがある。
ENDはどのデータの終端にもついていて、ここまでがこの子データの中身であるが、0x0に於けるサイズの値はこれを除いたものとなる

値の中身としては整数値、キーなどがある。ただし、キーは見た限りではTXTRデータのみを指しており、
CMDLや、CINFなどのキャラ関連のデータを指していない。
このことからMREA解凍データの一番最初のエントリはステージのシーン情報の管理をしていると推定できる(DIFFなんかもおそらく"Diffuse"の略だろう)。

なんて書いてみたが、結局よくわからない。TXTRをjpgやらpngやらに変換できたらなんの画像で何のためにこのデータがあるのかわかるのになあ
先にTXTRの変換に挑戦するべきだろうか
0023名無しさん＠お腹いっぱい。
垢版 |
2011/09/22(木) 23:06:20.84ID:qeaSHw1A
画像は思ったより簡単そうだが、ややわからない所がある
そこがわかれば煮るなり焼くなり好きにできるんだが、、、
0024名無しさん＠お腹いっぱい。
垢版 |
2011/09/23(金) 11:07:54.41ID:SkAC9uJW
コロコロと解析対象を変えているから今何をやっているかわからないかもしれないが、
TXTRのデコードに挑戦している。なんの画像かわかれば、MREAや他のファイルの解析の役に立つしね

TXTRは他のデータとは異なる圧縮ヘッダを持っている。それについて
1.パレットなし
0x0 dpiX(常に0xC)
0x4 dpiY(常に0xC)
0x8 圧縮サイズ(上位4ビットはフラグ)
0xC 解凍サイズ
0x10 不明
0x14 横
0x16 縦
0x18 画像フォーマット？

2.パレットあり
0x0 dpiX(常に0x14)
0x4 dpiY(常に0x14)
0x8 パレットの圧縮サイズ(上位4ビットはフラグ)
0xC パレットの解凍サイズ
0x10 画像の圧縮サイズ(上位4ビットはフラグ)
0x14 画像の解凍サイズ
0x18 不明
0x1C 横
0x1E 縦
0x20〜0x28 不明
0025名無しさん＠お腹いっぱい。
垢版 |
2011/09/23(金) 11:24:16.72ID:SkAC9uJW
普通に考えて車輪の再発明を避けるためドンキーコングリターンズの画像は広く使われる画像フォーマットを採用しているはずなんだが…
更に疑問なのはたまにヘッダの解凍サイズの値と実際の解凍データのサイズが一致しない時があること。
メモリダンプではデータは正常に解凍されていた。ということは>>24の内容は間違っているということか？
0026名無しさん＠お腹いっぱい。
垢版 |
2011/09/23(金) 13:08:40.65ID:SkAC9uJW
申し訳ない、こないだ作ったzlibのラッパーのミスで実際より大きくデータサイズが膨らんだようだ…
0027名無しさん＠お腹いっぱい。
垢版 |
2011/09/23(金) 19:38:52.60ID:SkAC9uJW
TXTRはおそらく基本的にはビットマップだと思う
データサイズがピクセル数の倍数になっているものがほとんどだから
ピクセルあたりのデータサイズは最小で4ビットがあるっぽい
そうでなければピクセル数がバイト数を上回る場合を説明できない

画像に詳しい人、吸い出し経験がある人のアドバイスがほしい…
0028名無しさん＠お腹いっぱい。
垢版 |
2011/09/24(土) 07:54:41.43ID:GDvD5/en
明らかにゲームキューブのテクスチャのフォーマットを採用しているな
devkitProのgxtexconv.exeでビットマップ画像をCMPRフォーマットに変換してみたところ、TXTRに非常に似たバイナリが生成された。
ちょっくらソース参照してコーデック作ってくるわ
0029名無しさん＠お腹いっぱい。
垢版 |
2011/09/24(土) 23:04:05.24ID:GDvD5/en
コーデック作るのに10個のフォーマットに対応しなけりゃいけないのが想像以上に面倒だったので、
ここはマリオカートハックのChadderzのソースを流用することにした。
ライセンス的にはOKなはず
0033名無しさん＠お腹いっぱい。
垢版 |
2011/09/25(日) 18:41:59.40ID:YqmYwor0
>>32
ありがとう
テクスチャハックが可能になったら人寄せもしやすくなる…はず

気になるのは、ヘッダの情報に画像フォーマットが含まれていないのではないかということ
ほとんどの画像がCMPRで一部RGB5A3だが、ヘッダに共通性がみられない
さらに一部の画像は未知の形式で、ゲームキューブ・Wiiの形式のどれでも変換不能だった

まあ、どうせ俺の勘違いか間違いで終わるだろうが
0034名無しさん＠お腹いっぱい。
垢版 |
2011/09/25(日) 22:24:42.22ID:YqmYwor0
どうもミップマップが関係してるっぽい
マリオカートやらスマブラで使われているtex0フォーマットは通常画像に加えて、縮小画像を保持している
それと同様に幾つか縮小画像を保持しているならサイズが合わない説明がつく

ちなみに未知の形式といってたやつはRGB5A3でデコードできた。
0035名無しさん＠お腹いっぱい。
垢版 |
2011/09/26(月) 22:57:28.57ID:BV76qRMr
ひとまずパレットなしの画像の読み書きを実装した
実装したと言ってもコーデックはChadderzのを使い、ビットマップの拡大縮小は.NET Frameworkがやって、俺がしたのはヘッダ情報の記入と
データの圧縮くらいで、手間はかかってない
テストして動作したらデモ動画とTXTRに対応したDKDKをアップするわ

パレット画像は今のところ実装予定なし！
ステージに含まれる枚数的にはかなり少ないし、
Wiiの画像フォーマットで一番優れているのはおそらくCMPRで、ユーザーはそれ一択でおｋだから
0036名無しさん＠お腹いっぱい。
垢版 |
2011/09/28(水) 22:57:28.01ID:Ym3XaHuF
細かい修正をするのに手間取ったが、一応バグはなくなったと見える
テストは明日か明後日しようと思う
0037名無しさん＠お腹いっぱい。
垢版 |
2011/09/29(木) 07:48:50.02ID:2sV/edQf
先に言っておくが、画像を開いていくとメモリのドカ食いが起こる
100MBとか余裕で食うんで注意
0038名無しさん＠お腹いっぱい。
垢版 |
2011/09/29(木) 22:53:36.39ID:2sV/edQf
テストに失敗した。
どういうことかというと、まずファイルロード画面(ドンキーやディディーが左から右へと走る画面)から先に進まなかった
かといってフリーズしたわけではない。
以下、原因の推定

1.内部的にファイルサイズを保持し、ファイルサイズがそれ以上だったらエラーとしてリロードを試みる
　これは無い。なぜかというとRASはキチンと読み込み、再生することができたからだ。
2.Riivolutionに問題がある
　これも1と同様の理由で否定されるほか、正規のファイルを配置したところキチンと読み込んだ。
　これはRiivolutionにファイルサイズの限界があるからだ、といった推測は誤りとなる
3.PAKデータの先頭の16バイトの数字(キーと呼んでいる)が間違っていた
　正規のファイルのキーを適当な値にいじって読み込ませたところ、動作した。よってキーの値は適当でも良いことになる
4.DKDKのファイル組み立てが間違っていた
　これは微妙であるがオフセットの値がありえないところを指している、といったことがあった場合、ゲームはおそらくフリーズするはずである。
　とはいえ、これしか原因はありえない。

テクスチャのミップマップの扱いが怪しいと思う。データサイズが、同じ縦と横、ミップマップの画像数をもつ画像と異なっていた。
よく調べて修正しようと思う。
0040名無しさん＠お腹いっぱい。
垢版 |
2011/10/01(土) 12:38:12.68ID:iJoKgsS1
応援してくれるだけでもいいと思うようになった
ステージ改造が可能になれば多分人は増えるだろうし、それまでの辛抱だと思う

TXTRのリビルドに間違いが見つからない…わからんorz
0041名無しさん＠お腹いっぱい。
垢版 |
2011/10/04(火) 20:38:36.72ID:eVGmTQwN
今週は私用で活動時間がとれない
やめたわけではないのでご心配なく

ところでRiivolutionの速度の遅さが目に余る
どんな実装したら3倍程度の読み込み時間になるんだ
0042名無しさん＠お腹いっぱい。
垢版 |
2011/10/06(木) 22:23:43.04ID:oGlRzS0O
ISO直下のファイルがあることに今気づいた
PAKファイルがあったので見てみたが、ステージのPAKとやや構造が異なっていてDKDKの手直しが必要っぽい
こんな所にファイルがあると知っていたならそれに合わせて最初から作ってたのに…
0043名無しさん＠お腹いっぱい。
垢版 |
2011/10/08(土) 06:58:48.86ID:nqD4zIG3
テクスチャのサイズがオリジナルと異なっていたのが読み込み失敗の原因だったぽい
なぜだ？　RASファイルは問題なく読めたのに、PAKは大きさを揃えないと読めない
ひとまずデモ動画つくるわ
0045名無しさん＠お腹いっぱい。
垢版 |
2011/10/08(土) 19:51:10.92ID:nqD4zIG3
だめだ、なぜサイズによって成功不成功が決まるかわからないと進めない、というか進みたくない
読み込みプロセスがわかればヒントがあるかもなー
でも逆汗はしたくねえな

誰か助けてください。
0046名無しさん＠お腹いっぱい。
垢版 |
2011/10/09(日) 09:12:27.75ID:illr7FdB
やっとわかりました、読み込みエラーの本当の原因が
答えは単純、データサイズは0x40バイトにアラインしなければならない、という規則を破っていた
データのテーブルを見てみると、データサイズの末尾2バイトが00,40,80,C0のものしかなかった
そこで、データをすべて0x40に揃えたところ、やっと読み込むことができた

これで意気揚々とデモ動画をつくれるぜ
0049名無しさん＠お腹いっぱい。
垢版 |
2011/10/09(日) 21:29:20.49ID:illr7FdB
>>48
わかりにくいって意見が出たら作ろうかな
まあ、空に大きくHello Worldって出してるから問題ないと思うけど


お次は何をしましょうかね
MREAは最後に回した方がいい気がしてきた
あれはステージを組み立てる設計図みたいなもんだし、いろいろわかってないと難しい
モデルいくか？

ちなみに俺はコード書けるだけで、画像処理やら音楽変換は完全な素人だから常にググってる
言語や知識は問わないからコード書ける人は手伝ってくれるとうれしい
3ヶ月かけてまだRAS(STRM)とTXTRしか実装できてなくて、正直一人じゃ気が遠い
0053名無しさん＠お腹いっぱい。
垢版 |
2011/10/12(水) 07:42:25.31ID:Hbhe/V58
CMDLを現在解析中
モデル関連でわかっていることを挙げると、
CHAR:
モデルの設計図。このキャラの名前は何、モデルは何を使う、アニメーションは何を使う、といったことが記述されている
CINF:
ボーン(開発者はどうやらジョイントと呼んでいたっぽい)の情報
CMDL:
モデルのいろいろ。テクスチャなど
CSKR:
スキンの情報
関係あるかわからないデータ:
CPRM、CSMP、CAUD
0054名無しさん＠お腹いっぱい。
垢版 |
2011/10/13(木) 22:26:38.58ID:twVJsK/C
難しいな〜CMDL
ていっても一番最初にあるスクリプトっぽいデータだけ難しくて後は単調な配列っぽいから、
最初さえ何とかなれば簡単そうだ

わかってることを書くと、
スクリプトは「データ型」「データサイズ」「データの種類」「データ」の順で並んでいる
データ型にはPASS、INT、CLRがあってPASSはデータのキー、INTは整数を表す。CLRはわからん
データサイズはバイト単位で指定される
データの種類はいろいろあり、CLR(データ型とは別みたい)、DIFF(Diffuse)、RFLV、RFLD、OPAC(Opacity)、TRAN(Transparent? Transformation?)などがある
ただ厄介なのが、データにはデータ型で指定されたもの以外にデータの種類に応じてプロパティが含まれる
これらの意味を一つ一つ理解していかないとモデルのインポート、エクスポートは実現できないだろう

また、スクリプト群の前と、個々のスクリプトの前にそれぞれヘッダが用意されており、それもほとんど意味が分からない
開発者はデータを一般的なモデリングソフト(3DS Maxやらmayaやら)で作成しているだろうからそれらのフォーマットを理解すればこのデータの理解にも役立つと思う
一応呼びかけるけど、3Dモデリングに詳しい人、どんどんご協力ください
0055名無しさん＠お腹いっぱい。
垢版 |
2011/10/14(金) 17:04:41.99ID:P/yB8I8v
いちおうCMDLでぐぐってみたら、なんと、メトロイドプライム2はCMDLを使用するらしい
他にも被るデータが大量にあり、おそらくゲームエンジンは同じのを使っている
製作元は両方レトロスタジオ社で、過去の資産を有効に活用してるっぽい
ここらを調べればいろいろわかるかも
0056名無しさん＠お腹いっぱい。
垢版 |
2011/10/14(金) 21:54:12.47ID:P/yB8I8v
俺が一生懸命調べてたのはマテリアルのデータだったらしい
メトロイドプライム2のファイル解析プロジェクトMPxViewer(最新リリースが5月だが)のソースがクソ役立つ
これは解析が捗るわ
0057名無しさん＠お腹いっぱい。
垢版 |
2011/10/18(火) 22:08:48.39ID:A38paXgZ
今mayaのチュートリアルを見て色々調べてる
RFLVやRFLDは反射が関係してそうだ、とかわかってきた

チラシの裏にでも書いてろって感じですねｗｗｗ
要は活動してるよってことです
0058名無しさん＠お腹いっぱい。
垢版 |
2011/10/22(土) 08:18:14.49ID:XKSZMryP
MPxViewerの助けでCMDLの構造はほぼ理解してしまった
スキニングやアニメーションは後回しにするから、ひとまずビューワーを作成していこうと思う
そのためにはまず3Dプログラミングを学ぶところから始めなけりゃならないが
0059名無しさん＠お腹いっぱい。
垢版 |
2011/10/24(月) 22:48:05.55ID:0p0hSHyz
構造自体は大体わかったけど所々にある数値の意味が分からない
それに、メッシュデータの1エントリごとのサイズがまちまちで、どこに見分けるためのフラグなり文字列なりがあるかもわからない
一つ朗報なのはバーテックスデータの変換はできるようになった
テストしてみたところ花っぽいものが出てきた
0060名無しさん＠お腹いっぱい。
垢版 |
2011/10/25(火) 07:41:45.30ID:fzhS5Cvl
俺が一番嫌いなのはバイナリ中にフラグが含まれている場合なのだが、CMDLはフラグだらけで非常に煩わしい
しかもビット単位でフラグが指定されているから8ビットすべて理解するにはかなり手間がかかる
ドンキー開発者の方は何ら困らないからしょうがないんだけれども…
0062名無しさん＠お腹いっぱい。
垢版 |
2011/10/28(金) 22:15:56.24ID:zgdOz3fj
そうだね
開発者のデータは無いけどWiiに関してはリバースエンジニアリングが進んでいるからその情報を元に推測してる
それにS○Kのドキュメントが流出してるからそれも参照しながらやってる

CMDLの状況だが、フラグは大体わかってきた
それでもまだ理解できていない数字がたくさんある
手伝ってくれるという人がいるなら、現在わかっていることを詳細に書くが…
いい加減しつこいかな
0064名無しさん＠お腹いっぱい。
垢版 |
2011/10/30(日) 14:14:00.99ID:ym40SL8i
まあ、多人数でやってるわけじゃないしな
といってもwiiマリオのエディタも一人だった気がするし頑張ろうと思う
俺の見積もりで最も時間がかかると見たのがRAS音楽で、TXTR画像やCMDLモデルはその次にかかると見ていたから
ここを終えればエディタにだいぶ近づくはず
0065名無しさん＠お腹いっぱい。
垢版 |
2011/10/31(月) 22:26:27.29ID:3+NSDEIq
現在の進捗状況
ヘッダ部：ほぼ解析完了
マテリアル：結構残ってる。CMDL内では統一された数値でもMREAでは違うという値がある(MREAにもマテリアルがあることは前に言ったと思う)
バーテックス：解析完了
ノーマル：解析完了
UV：解析完了
メッシュ：ほぼ解析完了。謎のベクトルあり。ヘッダ部にはマテリアルや幾つかの項目への参照がある
0067名無しさん＠お腹いっぱい。
垢版 |
2011/11/04(金) 22:16:43.19ID:EZZgC/KP
あ〜　メッシュがわからん
CMDL先頭のフラグによってメッシュのエントリのバイト数が1〜2バイト変化するが、それら増えたエントリの意味が分からない
そのフラグが付いているCMDLの個数を調べてみたところ、CSKR(スキン)データの個数とほぼ同一となった
面白い事にどのステージデータでもCSKRの個数はフラグonのCMDL数から3引いた数になっている
これらのことから判断して増えた1、2バイトはスキンメッシュアニメーションに関係する値であることは想像できる
0068名無しさん＠お腹いっぱい。
垢版 |
2011/11/05(土) 22:17:29.24ID:QZ7/7BNo
「ドンキーコングリターンズ　改造」でググったら俺の動画とこのスレが一ページ目にきた
まあ、そんなキーワードで調べる奴はいないだろうし、あまり人寄には役にたたないな

CMDLのメッシュのエントリの先頭につく1バイトは必ず3の倍数になることがわかった
何を表しているんだろう
1.列挙体
3の倍数にする意味がない
2.データサイズ
なんのデータサイズだろうか？　スキンメッシュアニメーションに関連があるという過程からすると、全く的はずれな推測になるが…
3.データの個数
同様に、なんのデータの個数だろうか？
4.オフセット
これはありえない　3の倍数だけ進んだデータはまだ同じエントリ内だから
5.フラグ
ありえる　だが、3の倍数が(ry
6.ID
IDであればそれぞれ違う値になるはずだが、同じ数値を持ったエントリが大量にあることからこの推測は否定される
7.数値自体がメッシュの形状やアニメーションに影響する
この場合非常に厄介である。ゲームを動かしてみて実際に実験をしながらやっていくか、アセンブラを読みといて必死に解析するか、
運が良ければ他のモデルフォーマットから相当しそうな値を探し出すことが出来るか
いずれの場合でも非常に手間がかかるのは事実
しかも、「運がよければ」の選択肢である他のモデルフォーマットを参照する、という手段はとうの昔にやっているので残り2つの泥沼しか残っていない
数値自体が影響を与えていないことを願っている

そもそも、この追加の1〜2バイトがメッシュデータ内に存在するかどうか判定するためのフラグやらなんやらがヘッダ内に存在しない
ということは他のデータ部にそれが存在するか、あるいは「このデータが存在するから追加の1〜2バイトも存在する」といったデータ間の関連付けが存在するか
0069名無しさん＠お腹いっぱい。
垢版 |
2011/11/06(日) 19:09:01.05ID:i45T3ZVX
行き詰って行き詰って、もうだめかと思ったけど、スマブラやマリオカートで使用されているmdl0に類似したデータを発見した
というより、もろにCMDLのメッシュデータと同様の構造があった
ちょっとChadderzやKryalのソースコードを覗いてくるわ
これがダメだったら死ねる
0070名無しさん＠お腹いっぱい。
垢版 |
2011/11/10(木) 18:50:09.51ID:cSohfGhu
わかってきた　わかってきたぞ
まず、メッシュデータに含まれる謎の1〜2バイトはやはりスキンメッシュアニメーションに関係ある
どう関係があるかはまだ調べてる
スキンメッシュアニメーションを疑い始めてずっと平行してCSKRデータの解析に挑戦してきたがようやくわかってきた
これは挫折せずに済みそうだ
0071名無しさん＠お腹いっぱい。
垢版 |
2011/11/11(金) 17:58:14.33ID:67oeEOyD
CSKRを完全に解析完了したのでフォーマットを書く
ヘッダ
0x0 タグ(ASCII文字列でSKIN)
0x4 バージョン(整数値0x3)
0x8 総エントリ数

エントリ
0x0 子エントリの個数
子エントリ
0x0 ボーンID
0x4 重みの値(浮動小数点数)
エントリのフッタ
0x0 参照カウント(だと思う)

エントリが並んだ後テーブルが2つある
最初のテーブルの先頭にはテーブルのエントリ数があり、符号付き16ビット整数値のエントリが続く
0xFFFFのエントリが含まれるがこれは何も参照していないエントリ
このエントリがバイト境界を合わせるために存在するのか、それとも他の用途があるのかは不明
テーブルのエントリ数は必ずスキンのエントリの個数に等しいことから、これは順番が重要になってくるはず
次のテーブルも同様に先頭にエントリ数があり、後に符号なし8ビット整数値のエントリが続く
これもエントリ数はスキンのエントリ数と等しくなるが、単純に0から1ずつ数え上げるだけなので、意味は不明

構造からしてCSKRのスキンのエントリをCMDLのメッシュデータが参照しているはず
何度も言うとおり、CMDLのメッシュデータは3の倍数になっていて、0〜0x1B、すなわち10段階の値しか取らない
しかしCSKRのスキンのエントリは何十個とある
したがってCMDLのヘッダにある謎の整数値が鍵となってくるはず
0072名無しさん＠お腹いっぱい。
垢版 |
2011/11/11(金) 18:07:10.58ID:67oeEOyD
考えてみれば非常に簡単なことだ
・メッシュデータの値が10段階の値しか取らない
・メッシュデータはすべてのスキンのデータにアクセスできなくてはならない
この2つのことを考えると、メッシュデータはスキンデータに次のようにアクセスするはずである(というよりそうでなければおかしい)
スキンデータのインデックス＝メッシュヘッダの整数値×10+メッシュデータの値÷3
0073名無しさん＠お腹いっぱい。
垢版 |
2011/11/11(金) 22:26:02.42ID:67oeEOyD
メッシュエントリの解析が完了したのでフォーマットを書く
ヘッダ
0x0　サイズベクトル(多分)
0xC　不明(常に0x8000)
0xE　メッシュデータのサイズ
0x10、0x14　パディング
0x18　CSKRエントリインデックスの10の位(>>72参照)
0x1A　マテリアルのインデックス
0x1C　不明(常に0xFF)
0x1D　CMDL先頭の文字列との対応を表す整数値
0x1E　ステージのオブジェクトかどうか(多分)
これ以降はメッシュデータが続く
メッシュデータのヘッダ
0x0　コマンド(WiiのS○KにおけるGX関数のコマンド)
0x1　エントリ数
以下にエントリが続く
エントリは前から言っているように、バイト数が場合によって異なる
すべての内容が揃っている場合
0x0　CSKRエントリインデックスの1の位を3倍した数
0x1　上の数値に0x1E足した数
0x2　バーテックスのインデックス
0x4　ノーマルのインデックス
0x6　UVのインデックス
0074名無しさん＠お腹いっぱい。
垢版 |
2011/11/11(金) 22:33:02.64ID:67oeEOyD
それにしても、まだ見てくれている人はいるのだろうか
最近停滞し続けていたからもう見限られたかなｗｗ

残ったマテリアルを解析できればいよいよビューワーの製作に取り掛かれる
一部不明な値を残しつつ来たが、それはエクスポートを実装して実験すればいいし、RAS音楽のように色々入力する必要のない値も存在する
(RASにも音量関係の数値=重要な数値がありそうだと最近思い始めたが)
0076名無しさん＠お腹いっぱい。
垢版 |
2011/11/12(土) 07:06:29.05ID:8wDVbBkP
いいんだ、定期的に書き込んでくれればモチベが保てる
欲を言うならDKDKを使ってみての感想やバグ報告なんかをしてくれると嬉しい
0077名無しさん＠お腹いっぱい。
垢版 |
2011/11/12(土) 11:12:39.90ID:8wDVbBkP
ここいらでToDoリストを書いとく
・RAS音楽のコーデック作成←済
・TXTRのコーデック作成←パレット付き以外済　パレット付きは実装予定なし
・CMDLのコーデック←50％(把握は80％)　CSKRのコーデック←ほぼ済
・CINF(ジョイントデータ)のコーデック
・ANIMデータのコーデック
・CHARデータのコーデック
・PARTデータ及びSWHCデータのコーデック
・MREAデータのコーデック
全体としてみるとスーファミ時代のドンキー並みに改造可能になるまでの道のりのうち半分以下ってところか
とはいえ、最難関の一つと見ていたCMDLの把握がそろそろ完了することを考えると、結構早く終わるかもな
半年以上必要だったら事情でそれ以降は一年以上作業ができないがorz
その場合はDKDKのソースを公開するか…
0078名無しさん＠お腹いっぱい。
垢版 |
2011/11/15(火) 22:29:07.84ID:1j+yL6gs
マテリアルわかんねー
わかったことを羅列する
1.マテリアルにはヘッダがあり、フラグ、列挙体等が含まれる
2.ヘッダの後はアトリビュート(属性)とおぼしきものが存在する
3.属性にはCLR(データにキーを持つものとマテリアルの色をRGBAで表現するデータを持つものの場合がある)、TRAN(透過部分を示すテクスチャの情報)、INCA(発光部分を示すテクスチャの情報)
　RFLV(反射？)、RFLD(反射？)、RIML(Rim Light、縁どりの光？)、DIFF(Diffuse?)などがある。
ヘッダの内容と属性は少なからず関係していて、因果関係をつかめないことにはインポータ、エクスポータは作れない
この中で特に意味が分からないのはRIMLで、必ず球体(例えばこんなの　http://viploader.net/ippan/src/vlippan245103.bmp)が指定されている
この球体を使ってどうやって縁取りを描画しろと言うのだろうか？
そもそも、反射やらDiffuseやらはマテリアル自体に適用されるものであってテクスチャに適用されるものではない。
それなのに、あたかもテクスチャそれぞれに反射光やら拡散光やらを設定してそれを合成することで、マテリアルを構成するかのごとくデータが並んでいるのはどういうことだろう？
0079名無しさん＠お腹いっぱい。
垢版 |
2011/11/15(火) 22:40:49.47ID:1j+yL6gs
うん？ちょっとまてよ
例のS○Kのドキュメントにはテクスチャそれぞれに光を設定できるようなことが書いてあるぞ
俺の勉強不足か？
0080名無しさん＠お腹いっぱい。
垢版 |
2011/11/18(金) 23:11:53.47ID:VBW0eslm
ひとまずビューワーを実装中
これが出来ればいろいろ実験できるし、モデルが表示できる事自体が楽しいはず
0081名無しさん＠お腹いっぱい。
垢版 |
2011/11/19(土) 22:35:48.32ID:OMFk8OMf
DirectXに関しては全くの初心者なので試行錯誤してようやく三角形のレンダリングまで行えるようになった
モデル表示の基礎部分はできたので、続けて作っていこうと思う
0082名無しさん＠お腹いっぱい。
垢版 |
2011/11/24(木) 07:48:50.17ID:c4ovw4SU
どうもモデルデータのフォーマットに間違いがあるっぽい
ドンキーのモデルが穴だらけになってしまった
0083名無しさん＠お腹いっぱい。
垢版 |
2011/11/27(日) 12:54:53.30ID:MgP1lmTQ
下らんバグのせいで3、4日悩まされ続けて例のごとく諦めようかと思っていた…
ようやく正しくモデルを読み込めた
まだテクスチャがおかしいのでそこを修正したら画像を上げる
0084名無しさん＠お腹いっぱい。
垢版 |
2011/11/28(月) 22:46:47.19ID:sjV1YGqj
問題はほとんど解決したが、まだ一部問題が残っているので明日画像をアップしようと思う
まあ、ゆったり待っててくれ
0085名無しさん＠お腹いっぱい。
垢版 |
2011/11/29(火) 22:54:56.23ID:lWm+mzq6
ここですかさず人寄せage
ようやくドンキーコングリターンズの3Dモデルの表示に成功した
まだシェーダを実装していなかったり、異常なところがあるが…

バナナを吐く塔
http://img823.imageshack.us/img823/5066/15099378.jpg
バナナエアーシップ
http://img213.imageshack.us/img213/2020/27341263.jpg
ディディー
http://img440.imageshack.us/img440/462/65467377.jpg
ドンキーのDS
http://img534.imageshack.us/img534/3058/51824129.jpg
バルーン
http://img507.imageshack.us/img507/3529/50441872.jpg
出だしのアレ
http://img525.imageshack.us/img525/1055/75729111.jpg
樽
http://img202.imageshack.us/img202/2402/88213877.jpg
葉っぱ
http://img265.imageshack.us/img265/3899/36157535.jpg
0087名無しさん＠お腹いっぱい。
垢版 |
2011/12/04(日) 22:06:52.65ID:8bp3LLkE
…絶賛ダウンロードありがとうございます
今のところ解析と関係ないDirectXで詰まってる
その問題が解決したらディディーのテクスチャの以上の原因を調べようと思う
0088名無しさん＠お腹いっぱい。
垢版 |
2011/12/05(月) 07:36:35.33ID:7qnzMY3a
いつもの人がダウンロードしてくれたみたいだｗ
すぐ解決すると思ってたDirectXの問題が思ったより難しい
解決したらまた進捗状況を書くから少々お待ちを
0090名無しさん＠お腹いっぱい。
垢版 |
2011/12/08(木) 22:51:30.59ID:91Nb5tAO
テクスチャ座標(UV)には二種類ある
一つは普通に32ビット浮動小数点型で記述されており、そのままUV座標として使える
もう一つは16ビット整数型で、浮動小数点型に変換した後何らかの数で除算するとUV座標に相当する値が算出できる
そして今日はその「何らかの数」を大量のデータから推測、実験して導出することに成功した
その結果がこちら
Kalimba
http://up3.viploader.net/ippan/src/vlippan248647.png
DK
http://up3.viploader.net/ippan/src/vlippan248646.png
DKは一目瞭然、kalimbaの方は一見正常だが、公式サイトで確認したところまだうまくいっていなかった
うーん、わからん
0092名無しさん＠お腹いっぱい。
垢版 |
2011/12/10(土) 12:54:16.95ID:hOEkXHjY
ドンキー
http://up3.viploader.net/ippan/src/vlippan248868.png
画像が左右反転していた理由が判明した
DirectXにおける座標系は左手座標系だが、Wiiゲームでは右手座標系らしい…
テクスチャの問題だったわけではないということ

ようやく異常がなくなったので、シェーダー作成にとりかかろうと思う
TRANあたりは簡単に実装できると思う
0093名無しさん＠お腹いっぱい。
垢版 |
2011/12/16(金) 22:24:15.17ID:PRq3fiz4
TRANの実装が終わったがどうもよろしくない
どうやらTRANで透過する対象のテクスチャがCLRで指定されているもの以外の場合もあるようだ
0094名無しさん＠お腹いっぱい。
垢版 |
2011/12/20(火) 07:42:33.50ID:AVDYvvdM
TRANで透過しているものの以外にCLRにアルファチャンネルを含む場合があるようだ…
そこまではわからないのでひとまず置いといて次のシェーダ作りに進むことにする…
0095名無しさん＠お腹いっぱい。
垢版 |
2011/12/25(日) 20:00:08.60ID:IC19vxwq
DirectXの仕様にはCMDLビューワーの実装を始めてから何度となくつまずかされてきたが、
今回テクスチャがまともに表示されない問題の原因をようやく突き止めた
テクスチャが正方形になっていないと自動的に正方形になるよう画像が切り取られるみたいだ…
(まあ、正確にはDirectXというよりD3DXの仕様だが)
まあ、まともに表示できそうなので、近いうちにアニメーションの実装に移る
0096名無しさん＠お腹いっぱい。
垢版 |
2011/12/26(月) 23:02:56.64ID:wVG0dQmz
CINFの解析を始めたが例によって難しい
最初にあるものは明らかにジョイントの名前のテーブルだが、そのあとは単なる整数の羅列にしか見えない
しかも複雑なバージョンと単純なバージョンがあって更に複雑にしている
0097名無しさん＠お腹いっぱい。
垢版 |
2012/01/01(日) 16:33:19.99ID:gJ8o9BnD
…明けましておめでとうございます
このスレを見てる人はどれくらいいるかわからないけどまだ解析続けます
まあ、今年は徐々に厳しくなってくだろうけど
0099名無しさん＠お腹いっぱい。
垢版 |
2012/01/12(木) 18:17:43.82ID:b77kkd0R
ここ最近忙しくて解析をしてない
まあ、焦ってもわかるものではないが、4月までくらいしか解析できないから少し頑張ろうかな
4月になったら解析を一年程中断する予定

一年後ヤル気があったらまたスレ立てして解析するかな…
0100名無しさん＠お腹いっぱい。
垢版 |
2012/01/12(木) 19:03:12.09ID:cBMAdp6b
>>99
スレ立てしなくても1、2ヶ月くらいに1回保守してスレを再利用したほうがいいよ

1年後にはきっと外人がスマブラレベルの解析してくれてる・・・はず
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況