Recent content by kion

For clarification PSOv2 is the Dreamcast version. I wanted to make that clear since their are less weapons, stages and characters compared to Gamecube or PC. I changed the title from "PSOv2 Model Viewer and Downloads" to "PSO(DC) Model Viewer and Downloads" to avoid confusion.

I guess i should mention my Noesis Plugins are here: https://gitlab.com/dashgl/ikaruga/-/snippets These include formats such as .xj, .nj (which is already supported by Noesis, but includes my source), stage files and gamecube .gj.

I get PM'd about this occasionally. Previouly i had an ftp server with all of the extracted assets from PSOv2 on it. The ftp server is gone, but the tools used for the assets are now open source, so you can view and export the models from the Dreamcast version of the game. Tool...

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