PM:TTYD model file format, pet project

[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


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/I...nsparency.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.



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

[R-II]

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.

[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...