Search results

Some screenshots.

Well... fuck. I was hoping that since the Ep 3 maps are nearly working that the Episode 1&2 maps would "Just Work" (TM), but I guess that's not the case. So I guess that means we need to trace through any pointers we skipped over. We can start with the header, we have the text 'fmt1'...

A few notes on the Gamecube model format. The format seems to be best described as an indexed buffer geometry. What that means is that for a specific geometry, the game will declare a list of attributes that can consist of position, normals, vertex color or uvs. for attr in attrs...

Okay, so episode 3 maps seem to be mostly working now. There are a lot of corners I've cut on the materials. Alpha blending, diffuse color, double sided and all of that other general kind of goodness has been ignored while focusing on the geometry part. Right now the only aspect of the material...

That's not too much of a curveball. When I got into exporting 3d stuff, I thought that parsing old formats without documentation would be the hard part, and there would be some modern format that I could port to. Turns out it was the other way around, reading undocumented formats is a matter of...

Well, fml. This strip format or strip formats are really giving me more trouble than they should. In principle these should be pretty straightforward, in-practice these are quite cumbersome. I'll write what I think I know so far. For the saber, there seem to be two kinds of strips which start...

A closer inspection of this limited use-case seems to break down pretty quickly. The bytes 0x98 follows by 0x00 seem to declare a new strip. The first byte after the strip is the number of indexes. And from the there are three bytes, for pos, norm, uv. And this seems to go until 0x90 which seems...

Using this as notes for .gj as this format gets pretty crazy pretty fast. The part that we're interested in is outlined in red. Up to this point, the format is pretty straight forward. We have the same bone/node definition as xj and nj with position, rotation and scale with pointer to child...

Okay, I need some space for notes. So for the PSOBB maps, here are some screenshots: The plugin in more-or-less working, probably not perfect. You can grab it here: https://gitlab.com/dashgl/ikaruga/-/snippets/2054101

So this is kind of interesting. We follow the pointer to 0x1d4 where we find there structs with a length of 0x10. Each one with a pointer probably to an xj node. Following that we see the other pointer of 0x204 with the 0x7c entries. And each one of these structs seems to have a size of 0x20...

We can follow the first pointer 0x2BC4 to the table. And one thing that really sticks out is the section number for every struct. Which means we can easily get a struct size of 0x34. In this case we probably have position, rotation and radius. And then we have two pointers 0x01d4 and 0x0204...

Then we come to the table that starts with the characters 'fmt2'. Followed by 0x40 and 0x0E. After that are the letters 'HD', which was the same in the Dreamcast stage models (for some reason), ending off with two pointers 0x2BC4 and 0x32EC. What this probably means is the 0x2BC4 section has...

Might as well try out the PSOBB maps. Starts the same. EOF - 0x10 points to 0x2e9c

Okay, and r.rel is probably supported now. I haven't really tried a lot of variations, but in general forest works. So that's good enough until someone send a bug report or something.

Might as well move on to 'r.rel'. We start at EoF minus -0x10 which has a pointer to the header. In this case 0x27E4. That gives us a pointer to 0x253c and then a count of 0x11. From there we have a similar table that starts at 0x253c and ends at 0x27E4, which gives us a length of 0x2A8. And...

Added color to the flags for each collision mesh. The colors aren't exactly nice looking, I threw in a random color for each flag, since it's pretty hard to know what each flag does until you assign a color to see what it is. If you want anyone wants to adjust the colors, the rgb values should...

Okay, added collision map functionality: https://gitlab.com/dashgl/ikaruga/-/snippets/2052429

Okay, we can actually solve two mysteries right away. If we follow the first pointer we come to 0x2A8. We get the value 0x0A followed by 0x0000. So 0x0A is probably the count of triangles, and 0x0000 is probably to the pointer for the start of the triangle block. We know that the size of the...

I guess we'll take a look at the c.rel collision maps. Like pretty much all of the .rel files, we start at the end of file minus 0x10 bytes, which gives us a pointer to the header. In this case we read the pointer 0x018B34, seek to it. And all we see is another pointer 0x0184A4. We can then...

I'm going to call this good enough for now. I went and added in the animated models as a static part of the mesh. If needed I can go back and export them as separate animated meshes. In that case I would need to add in some user data of where the animated model is in the scene.