[$threadinfo[title]]

[R-II]

This is somewhat of a first for me in a lot of regards - hacking game formats, reverse engineering file formats, and using 3D programming outside of a tutorial.

I've spent a fair ammount of time breaking down the structure of the model files (I assume proprietary) for Paper Mario 2: The Thousand Year Door, and I thought I'd share my progress. If this has allready been done or it's a common format I just don't know about, please tell me and point out the documentation I missed :)

Currently I've pieced together the following specs for the file format at:
http://hocuspocus.penguinia.net/rii/tplvtx.txt
(forgive my probably incorrect use of terms)
[Updated 5/30/05]
Almost all blocks now defined.

I've also got some pictures to document my testing and progress:
http://hocuspocus.penguinia.net/rii/pmviewer1.gif
http://hocuspocus.penguinia.net/rii/pmviewer2.gif
http://hocuspocus.penguinia.net/rii/pmviewer7b.gif
http://hocuspocus.penguinia.net/rii/pmviewer8.gif
http://hocuspocus.penguinia.net/rii/pmviewer10.gif
http://hocuspocus.penguinia.net/rii/pmviewer11.gif
http://hocuspocus.penguinia.net/rii/pmviewer15.gif
http://hocuspocus.penguinia.net/rii/pmviewer16.gif
I'd like to blend the planes without making them translucent, but I havn't found a good way around that limitation yet.

I hope if anyone wants to play with PM:TTYD, they'll find the document I've pieced together useful, allthough it's still a work in progress and isn't gaurenteed accurate, but if anyone else notices some things I missed that I just don't know how to see, I'd greatly appreciate knowing about it. There's a lot I don't know, especially with 3D. I'll also post my little proggy later after I've cleaned it up and if anyone's interested.

Anyway, maybe this was an easy format to break down, but it's a big accomplishment for me :)

[thakis]

*Very* nice :-)

I don't understand what you want to say with 'blend the planes without making them translucent', though. Have you tried glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); glEnable(GL_BLEND) (or the direct3d equivalent if you're using dx) or glAlphaFunc(GL_GREATER, .5f); glEnable(GL_ALPHA_TEST); instead of glBlendFunc(GL_ONE, GL_ONE); glEnable(GL_BLEND) (at least the image looks as if you were using this last method)?

[R-II]

That's the method I used (GL_SRC_ALPHA/GL_SRC_ALPHA_MINUS_ONE). Unforteunately it doesn't look nearly as pretty if I have white textures. But I need a good way of determining the order to draw the planes in, or order-independent rendering which OpenGL does not lend itself to as far as I can see.

[thakis]

There's a paper over at developer.nvidia.com (http://developer.nvidia.com/object/Interactive_Order_Transparency.html) about order independent transparency, but that's probably overkill for this purpose. The z order has to be stored in the file somewhere, because the original program has to know it too. Perhaps the scene graph stores the planes already in the right order (if there is a scenegraph stored) or there is an array which stores the order in which the planes have to be drawn.

[R-II]

waha, thank you so much, when I first read your post this morning I didn't notice your mention of glAlphaFunc, which did exactly what I wanted it to do. And in all my hours of searching, I kept seeing blending blending blending but not a single mention of an alpha test. So render order is irrelevant to me at this point in the game, which I couldn't find in the format anyway.

http://hocuspocus.penguinia.net/rii/pmviewer19.gif

Now I can get back to researching other parts of the file, which are getting a lot harder :)

[R-II]

http://mfgg.penguinia.net/uploads/post-2-1115788127.gif

I'm taking a rather blind stab at color and lightning normal blocks. The way this lock model colored and shined under a front-shining light makes me think my guess is correct, but I'm not sure yet if I've implemented it correctly. But I don't even know if all this data handles the same way under openGL as it does on the gamecube.

After this, I'll be looking into 'block 27', which I think is various poses and animation. That should be a real treat to break apart.

While I'm at it, does anyone know why there might be two blocks of incrementing integers? 0x00000000 0x00000001 0x00000002 .... 0x000005DE if there's 0x5DE polygon points. I can't even make a guess as to what they mean.

[R-II]

Figure I'll post my viewer since it's allready uploaded, for anyone who has PMTTYD files to play around wtih. The model files are stored in the "a" directory of the GCM. It should display most models, but since I've tested only a portion, some might crash it. I've allready fixed many a glaring error in that regard. Make sure the models you try to open are in the same directory. Also make sure the TPL file is present (same filename but followed with a dash), otherwise you'll only get colored models. Also be warned there might be memory leaks or other things since the code is messy, but I havn't seen it do terrible things to my computer yet. Includes a data viewer to examine the model file contents, minus block 27 (see specs).

Download: http://hocuspocus.penguinia.net/rii/pmviewer.zip
If you find a model that crashes the app, please tell me

Currently I'm trying to figure out different poses and how to hide the appropriate planes. And animation, but I don't know anything about model animation, so maybe not.

[ShizZy]

Nice job R-II, it works well.

[R-II]

I've spent the last few days battling with assembling the models correctly. I've arranged the blocks in the file into a form of a hierarchy. I also think I've figured out a hierarchy for the various planes, in which there's also entries labled as locators, joints, and groups. Every element of the hierarchy has an assoicated set of 24 floats from Block 24, which I think are broken into 8 sets of 3, and are used for translating, scaling, and rotating the different parts of the model. Each child in the hierarchy should inherit the transformation values from their parents as well I think, which makes sense. I'm applying the transformations to the modelview matrix before transforming a child, and then drawing the vertices from the point after all the transformations needed for that child are applied, which seems to work, but I don't know if it's a good method.

This is where I'm having a lot of trouble though, because the way I'm applying the transformations, some of the previously complicated and unrecognizeable models show up almost perfectly, but might have small errors (example: the ears in the pig model from twilight town are out of rotation and aren't symmetrical). Other models that allready displayed perfectly without any transformation are broken (or should I say their assembly shattered) after the transformation is applied. And a good chunk of models don't care or are slightly improved. I've updated the spec with some of my latest guesses and corrections, allthough I need to take the time to add better description.

Here's a picture of Hooktail the Dragon after transformations, looks pretty good, but I think there's some slight errors.
http://hocuspocus.penguinia.net/rii/pmviewer42.gif

[thakis]

What you are describing is the standard hierarchical scene graph, so it's probably The Right Thing (TM) to do. In bmd files, sometimes a vertex has to be transformed by more than one matrix (that's called skinning and is used for skeletal animation), perhaps you have to do this as well?

Oh, and did you try to glEnable(GL_CULL_FACE)? That might fix the dragons face...

[R-II]

Thanks for the tip on culling polygons. That just cleared up every lighting and color problem I had.

Do you have any more information about scene graphs, or more importantly, "skinning"? You're probably right, and I'm sure part of it does have to do with animation, but I don't understand really what you mean by multiplying by a second matrix, or where it comes from. I've literally taken a crash course in OpenGL four weeks ago and have no prior experience in game files or hacking, so I don't know any of the terminology, everything's named and identified from relationships I see.

[thakis]

Here's a pretty good overview on skinning:

http://www.darwin3d.com/gamedev/articles/col0598.pdf
http://www.darwin3d.com/conf/igdn0398/index.htm

Basically, there are two methods to animate meshes:
1.) Keyframes - simply store the mesh in different poses and display them on after the other (like 2d animation), quake2 does this for example. Looks good, but need much memory. And animation has to be "canned".
2.) Hierarchical animation: You have a matrix transform hierarchy and every vertex belongs to one of the matrices. To animate a model, you only animate the matrices ("joints"), and the vertices follow. Problems and solutions to this approach are outlined in the above links.

HTH.

[R-II]

Thanks for the links, I'm not entirely sure about the whole weighted vertices part, unless it just means inhereting the parent bone's transformations. I guess I need to do more exploring there, and I'll probably have to figure out more of the mysterious "Block 27". Aside from Block 19 which I've never seen change, I've figured out what all the other blocks do, and that just leaves animation.

The PDF actually pointed out something a little unrelated to skinning that just corrected all the minor errors in my 3D models - I was rotating my axes in the order XYZ instead of ZYX. Also discovered that the 4th transformation set is another rotation, so even the broken planar models appear correctly now.

[thakis]

At least in Mario and Zelda, animations are stored in a separate file, not with the model (which makes sense imo). Perhaps Block 27 contains materials stuff (shaders, texgen, texture matrices etc)? I don't know how Paper Mario looks, it might be that it doesn't need materials stored with the models, but... ;)

[R-II]

I don't know exactly what defines a material, but there's texture vertices, color, lighting normals, and such stored in the other 26 blocks. There's no obvious complementry files that go with the models in the PM rom, so I'm fairly certain everything that pertains to the model apart from their NPC data which is stored in an XML-like file elsewhere, is stored in that file, with textures in an accompanying TPL. I've actually started some work on Block 27 now, and one of the sub-blocks is responsible for animating the textures (or changing them, I don't know if texture animation is the right term), so fuses flash and little fire balls flicker.

From what I can see, there's 4 other types of animation in 4 other blocks, I think one of those is for displaying and hiding planes. The others are probably responsible for physically moving the planes, but I havn't gleaned anything from them yet. All these blocks are indexed by another list with timer offsets, perhaps in milliseconds, and either the animation loops or plays once.

And here's a screenshot from the game itself, and what I'm rendering below it.
http://www.realgamer.co.uk/screenshots/14_1.jpg
http://hocuspocus.penguinia.net/rii/pmviewer47.gif

[ShizZy]

I don't know exactly what defines a material,A material defines how a mesh is rendered. It can include lighting type (ambient, specular, diffuse, etc..) as well as vertex coloring, mip mapping, bump and env mapping, multi-texturing, etc. What's stored varies based on the format...

[thakis]

Hi, I just tried the viewer, works nicely. the file /a/a_mario looks kinda broken, though, and if I choose util->data view, it hangs. :saint:

[R-II]

I actually have a grossly updated viewer which displays most things perfectly, which I'll attach for you. Meant to get it up earlier, but...

Anyway, I got some of the animation implemented, but what I have working doesn't work for everything. The bits that control what planes are displayed and which are hidden seems to be working more completely.

I'm a bit down about the project right now because I simply cannot figure out the last couple blocks that actually move the planes around in animation, which would be rotation scaling and translation. I'm dealing with floating point values from the scenegraph, but I can't find any way to derive a floating point value from these animation blocks, and I can't figure out how to derive any kind of index either. I've had some guesses based on how the others worked (an inital index, with each index following actually being a bias to the index), but it hasn't really gotten me anywhere. Blocks in question are 27.4, 27.5, and 27.8 if you or anyone else is interested in looking (you can easily view the raw data with the data viewer inside the tool itself. I've also converted the hex to floating point and signed bytes too I think).

[R-II]

Actually, never mind that download if you followed the link, I forgot I linked the file to webspace, and that one would have been up to date.

Yeah, I don't know what's up with the Mario models. There might be some special treatment with that one because he's the controllable character and such.

[R-II]

Second note on that Util->Data View (Gee, I should really be reading your posts more carefully), it hangs for a while, especially on larger model files (most of which is due to animations, not the complexity of the model), but I think in every case I tried, it did eventually come up.

[R-II]

Well I've gone back several times over the past few months trying to wrap my brain around this block and I still havn't really gotten anywhere. Here's a sample of what I'm dealing with:

BLOCK 27.3
time * *
0: 0.000, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
1: 3.000, 0, 0, 0, 0, 0, 1, 0, 0, 0, 4
2: 5.000, 0, 0, 0, 0, 1, 0, 0, 0, 4, 4
3: 6.000, 0, 0, 0, 0, 1, 1, 0, 0, 8, 2
4: 9.000, 0, 0, 0, 0, 2, 1, 0, 0, 10, 4
This is the animation frame block - the starred collumns index and give the number of block 27.8 entries per frame, respectively.

BLOCK 27.8
Hex Signed Bytes Unsigned Bytes Float
0: A9020202 ( -87, 2, 2, 2) (169, 2, 2, 2) ( -0.000)
1: 37E9EBE8 ( 55, -23, -21, -24) ( 55,233,235,232) ( 0.000)
2: 11010200 ( 17, 1, 2, 0) ( 17, 1, 2, 0) ( 0.000)
3: 48030016 ( 72, 3, 0, 22) ( 72, 3, 0, 22) ( 134144.344)
4: 11FDFEFE ( 17, -3, -2, -2) ( 17,253,254,254) ( 0.000)
5: 00000000 ( 0, 0, 0, 0) ( 0, 0, 0, 0) ( 0.000)
6: 0000000A ( 0, 0, 0, 10) ( 0, 0, 0, 10) ( 0.000)
7: 00000000 ( 0, 0, 0, 0) ( 0, 0, 0, 0) ( 0.000)
8: 00000001 ( 0, 0, 0, 1) ( 0, 0, 0, 1) ( 0.000)
9: 00000220 ( 0, 0, 2, 32) ( 0, 0, 2, 32) ( 0.000)
10: 00000220 ( 0, 0, 2, 32) ( 0, 0, 2, 32) ( 0.000)
11: C176554A ( -63, 118, 85, 74) (193,118, 85, 74) ( -15.396)
12: 4161E6C0 ( 65, 97, -26, -64) ( 65, 97,230,192) ( 14.119)
13: 00000001 ( 0, 0, 0, 1) ( 0, 0, 0, 1) ( 0.000)
This is the evil block that supposedly represents animating the model. I converted the values to a few different types for examination, but nothing's really jumping out. I'm suspecting there may be mixed types among the block, but that wouldn't agree with any of the frame indexing (but the indexing itself looks like it's meaningless based on some general patterns I've seen). I also suspect this somehow indexes the scenegraph, but I havn't figured out how. Another thing is that some of the values near the bottom of the block appear to be floating point, but it's very spotty at best in test cases. If this was to directly manipulate the scenegraph however, all the values would have to be floating point apart from indexes, so there's more going on...

Anyway I know it's a lot to chew, but I'm hoping someone that knows more about animation can give me some better ideas at how to tackle this. You can of course get limitless examples of these blocks by using util->data view in the PM Viewer and scrolling towards the bottom.

[Elpenguino]

it's good to know you're still working on this, R-II. I really like this tool.

[BlueFalcon7]

i found a program that makes TPL files its at http://www.webtech.co.jp/eng/store/index.html nice job on the TPL viewer the only problem is that it gives me the "win XP has encountered a problem and needs to close" Im running a Ge Force MX 200 if thats the problem, i had the same problem with thakis' BMD viewer

[R-II]

It's not a TPL viewer actually, it's a 3D model viewer for Paper Mario 2. Allthough the model's textures are all stored in TPL files.

I don't imagine my code is terribly different from Thakis's (allthough much messier), so I couldn't say why you'd be encountering problems. Maybe it has something to do with your OpenGL support?

[BlueFalcon7]

i noticed that there were .tpl files in f-zero GX, for some reason its not working - not even on my friends computer (nVidia Ge force FX 5200) could you check it out?

[Elpenguino]

he just mentioned that this program is not a tpl viewer, and it's for paper mario only...

[CrazyThing]

I'm probably bringing up old and known but just a quick question. Is this even still going?

[R-II]

At some point the curiosity will get the best of me and I'll take another stab at those cryptic numbers.

I also want to see if I can make the textures 'crisper'. And maybe solve the speed bottlenecks. And a couple other little things. But at this very moment I'm not working on it.

[CrazyThing]

Better late then never. Heh. Good to know that you want to keep at it. May I assume that couple of other little things includes the messed up Mario files? ;D

[SarahHarp]

Omg this is ironic..!
I was seriously thinking of this type of thing (however for a differnt game - MP2:E ) though I was going to try something more along the lines of a model 'ripper' instead of 'viewer' (so I can edit the polygons in Maya).
However... I have NO idea how to get inside the .gcm file and look for/obtain the vertex data and whatnot (I mainly just need the Samus model.)
If you could elaborate or PM me on how exactly you did this I would GREATLY appriciate it.

Thanks.

Sarah.

[R-II]

Thakis posted a gcdumper (search it), I don't have a link offhand, but that will extract all the files from the GCM.

Then you have to start looking through the data of the different file types and deduce which ones are the model files. You might get lucky, and discover it's a known type, but otherwise you're going to have fun trying to break the file down into logical blocks and figuring out what they do and how they reference eachother.

PM2's models were stored in a fairly simple format - there's not even material data associated with them. But I have no idea how the data is stored for MP2 and it's sure to be more complex.

@crazything: Yeah, that and Peach's head and Grodus' head (something about heads). There's still data I havn't deduced a use for yet, so I'll spend more time examining that. I've got a CMS project I have to get finished though before I can spend a lot of time on other things. But then again, I just got on Winter break now, so maybe.

[R-II]

I started work on this again, rewriting it from scratch. The old codebase was a horrible scratchpad I couldn't work with anymore. The interface is a bit nicer thanks to a prebuilt Windows API I'm using, and manipulating models is equally as fast for all models now (the dragon will not go 1px every 2 seconds now). The data viewer is also redesigned to display data by block, so it won't hang launching that either.

I'm not quite up to the same level I was with the last one, still no lighting or animation, but I started to play with blending. I don't quite have it yet though. There's also what appears to be collision geometry in some of the models, but I have yet to find any difference in that geometry to get rid of it.
http://hocuspocus.taloncrossing.com/rii/pmviewer2_1.png

[thakis]

Nice :-)

[Nelde]

yes, very nice! is it available for download yet?

[Miles Lombardi]

This program looks amazing... are you still working on it? If not, could you at least post what you've made so far?

[thakis]

R-II hasn't posted for over a year. This thread is over eight months old. I doubt he'll even read your question :-P

[Sasuke3.0]

No, R-II hasn't been working on it since last year.

[R-II]

Posts? In 2007? I probably should have kept a closer eye on this place.

I should get around to posting what I've done, there has been some progress since I last visited this topic. At the very least, the newer viewer is much faster and doesn't muddy up the textures any longer.

Heh, I guess my answers are a little late for those who asked them, but maybe it'll help the next person if I get something up.

[BlueFalcon7]

Wow, its great to see that you are still working on this. I have learned way more about computers, and how 3D stuff works. I also reread the thread, and realized that my mistake was that I was going to the .tpl files, which were the textures, instead of going to the directory you specified in the beginning of the thread.

I sorta lost my copy of PM2 over many reformats, and switching hard drives, but I will get it when either Dolphin64, gekko, or the new WineCube comes out.

Anyways, the screenshots look nice. Good luck ;)

[Sasuke3.0]

hey Retriever, I never thought you'd work on this some more.
Do you think that Super Paper Mario has the same or similar format as PM:tTYD?