Search results

I was hoping to add some more information over the weekend, but either way it's time for some more forum spam. For document I wrote, there was generally already something there so I was able to contrast with what else needed to be added. So for pvmh and pvrt, I guess I can at least add the basic...

For now I've created a "dreamcast" namespace in the wiki to document the PSO v2 formats as it. My thinking is that the Dreamcast documentation can serve as a base for file formats in Gamecube and PsoBB that haven't been documented yet. Pages added: AFS Archive BML Archive GSL Archive Ninja...

The key frame list is generally declared above the motion table, so you can use the start offset of the motion table to check against the last key frame list.

Okay last chunk to describe before jumping into the wiki Ninja Texture List So the image above it pretty ugly, but the struct are pretty simple. The first struct 0x08 is the offset to the texture list, 0x02 is the number of textures. typedef struct { NJS_TEXNAME *textures; /*...

As far as I can tell PSOv2 for Dreamcast and PC always uses the format: struct NJS_MKEY_A { uint32_t keyframe; int32_t angle[3]; } For PsoBB, i think it could use the 32 bit format, but more often than not it's probably going to be: struct NJS_MKEY_A { uint16_t keyframe...

Okay so moving on to ninja motion (.njm). Ninja Motion uses the magic number NMDM, followed by the length of the file. The first struct in the file often looks like the following: NJS_MOTION 60060000 1E000000 03000200 What this is is the pointer to the motion table (0x660), the number of...

In terms of things to rant about, the general bone structure of the nj format is easy enough to use. It's the packing method of the vertices and materials that's the stupid part. So in terms of parts that are hard to interpret you have, 1. Handling the vertex list, indices and weights 2...

So the bits chunk documentation that's already there seems to pretty accurate. When the bit type is 4 you cache the location and stop parsing that set of chunks. When the bit type is 5 you jump back to the cached location. Which just leaves the Strip Chunk. Which I might end up splitting into...

I guess I can get another quick one out of the way: Material Chunk The material chunk is used to declare the diffuse, secular and ambient color for the mesh being defined. The header probably gives a better description of how this chunk works compared to the NinjaGD.pdf /*----------------*/...

Next step is Tiny Chunk Tiny Chunk has a fixed length and sets the texture id. The texture id matches up with the texture name set in the NJTL texture list, and should generally match any corresponding PVM files. [chunk head 8 bytes] [ chunk flag 8 bytes ] [tiny chunk 16 bytes ] struct...

In all honesty it took more than a few weeks to figure this out. The thought process looked something like this. 1. I noticed that noesis was able to accurately replicate some of the geometry that my parser had problems with. 2. I double checked against the model viewer that had similar...

So the ninja flags are used when the weight of the vertex to the bone defining it is less than 1.0. I'll write the chunk header again to refer to it in a second. [ chunk header 8 bits] [chunk flag 8 bits ] [ chunk length 16 bits ] [ vertex offset 16 bits ] [ vertex count 16 bits ] So when the...

I only looked at the top level .nj documentation and didn't notice those two links mentioned in the article there. The njcm model has a pretty good explanation of chunks, and already has information on the bits chunk. Which leaves the tiny chunk, material chunk, and strip chunk. And then I'll...

Okay, I have komo.nj listed as "Sunrays" Forest 02 GSL Looks like I already picked up the small differences in assets between Forest 02 and Forest 01 aside from the rel files I'm putting to the side for now. So I guess that means I can move onto Caves. Caves 01 GSL

I don't know if someone knows what "fe_obj001_komo.nj" is supposed to be. It's this kind of shade thing that starts at a height of 0 and goes into the ground. "abeno_fs_obj001_fosuno.bml" is another weird one that always gets me. It's the normal door switch. Okay fe_obj_hako01_hahen02.bml...

So right now I'm trying to narrow down what I have done and haven't done. So a quick list of things that I haven't done are: 1. Export all of the objects 2. Export the ultimate Enemies 3. Export the ultimate Stages 4. Export the stage sky boxes 5. Export the NPC's I think that list also kind...

Okay, so posting more information in terms of Ninja Chunk model files (.nj), you have the njcm_object_t, which acts as a bone and gives the translation, rotation, and scale transformations that make up a 4x4 transformation matrix, as well as define the child, parent structure of the bones. I...

Maybe "brought to my attention" was better. Either way, it's pretty amazing to see a lot of this information start to come together into one resource. This is part of the reason I'm spamming here, so that the information posted into the wiki has a change to under go some editorial discretion...

Going on to the next step, I might as well start filling in what I'm familiar with, .nj models. The page I'll reference is here: http://sharnoth.com/psodevwiki/format/nj There's also NMDM for Ninja Direct Motion. For POF0, I've generally been referring it to "point orientation format"...

So I came across Wilhuf's Pso dev wiki, which can be found here: http://sharnoth.com/psodevwiki/start and I'm extremely impressed with how much information is there. I think I have some information to contribute, but I'm not the best at writing documentation directly to a wiki in a nice format...