XeNTaX

Well, they specify how the data in the unpack blocks: are handled.

The ordering and contents of the block are specific to each developer. So you would have to determine that visually, as has already been done. But even then there are times when the data will not be entirely complete until it is fully unpacked due to things like masking, where data can be partially written between multiple unpack blocks.

For formats that are nicely structured for us, a lot of this information can be glossed over, because in those cases even in the packed form, it still resembles the standard in order list of values we are used to. Simply decipher the counts from the commands and process normally. But if the developer decided to get more creative with their use of the commands, it can get far more interesting.

The ## ## 00 01 specifiers, basically tell how often to read and write elements within each unpack block. So you can essentially read data and write it to memory one after the other, or every other line, etc.

The memory in the vu on the ps2 is aligned to 16-byte boundaries, and the unpack commands write this data out 16 bytes (four 32-bit values) at a time, using masking to specify which, if any, of the "x", "y", "z", or "w" data should be written each time.

This allows for either writing data consecutively one after the other, or interleaving the data between multiple unpack operations.

For example, lets say you have 10 vertices, normals, and uvs.

Using: This basically says for every read of the data, perform a write to memory and advance to the next data to read, and address to write to.

You could write the vertices to address 0x0000, and they would appear one after the other, causing the normals to have to be written to address 0x00A0, and the uvs need to be written at 0x0140, to avoid overwriting previously written data.

But these commands can also be used to write the data interleaved in a way the the order is [vert1, norm1, uv1, vert2, norm2, uv2, ...] using: Which would essentially cause the order of operations to now be: read, write, skip, skip, read, write, skip, skip, etc. So for every read/write, it would then skip two memory locations (0x20 bytes), and perform the operations again.

This would cause the start addresses of the write operations to be different as well. The vertices could still start at 0x0000, but the normals would now start at 0x0010, and the uvs at 0x0020. Because of the skipping the space for the normals and uvs, would be untouched during the vertex unpacking, in the same manner when writing the normals, the uv and next vertex value would be skipped over, and so.

This can also be used for he inverse of writing more data than you have read, i.e. reading data and writing it multiple times, and various other combinations.

To top it all of if that wasn't deep enough, masking can change which values are even written in the first place, even being able to replace masked out values with constants in other registers. So you could write to the "x" and "y" locations in one unpack command, masking the "z" and "w" so that they will be untouched, and use another unpack command with the masking reverse to write only to the "z" and "w" areas with completely different data. Or the more common case of writing out the xyz position of a 3d vector, and masking the "w" location so that a constant value of 1.0 is written.

There are a lot of things possible with the ways this works, and unfortunately even with a way to unpack them the way the ps2 does, they way they are order and the data contained within the commands are completely up to the developer to choose for each game. The values don't even have to be geometry related, you can pack the entire header of another self-contained format within these commands, where after unpacking you have a completely different format to parse.

Whew, sorry for the long description...while not xenosaga specific, its the main reason why there is still a little more work involved than simply unpacking the data in a lot of cases. Will see if i can post something more useful, heh.

wow thats very interesting...

okay soo basically before importing the strip I have to read everything between two VIF command blocks ex. "01 01 00 01" .. I assume the command is closed by an empty space "00 00 00 00"

cause with each new VIF tag in between it'll add, or mask certain parts of my memory or the array I'm storing the face list to??

if that's right then the reason for the bad faces before was that we weren't taking in account of all the VIF tags before we read a new VIF command "01 01 00 01"

The separation for this for mat would be 00 00 00 17 which is the MSCNT command. This is one of the commands that starts execution of microprograms on the VU processor.

Has been a while since i have looked at the format taking these things into account, but if i recall correctly there should be a header section, followed by a number of data sections, each full section starting with 01 01 00 01 and terminated by 00 00 00 17 commands (or a variant therof).

Will have to see how this all relates now that i know how it should work. SHould be able to find more counts and data sizes hopefully, as i now know that they are usually specified in terms of 16-byte chunks instead of the number of bytes, so the sizes will often be the full size divided by 16, if specified in quad word count format as the ps2 calls it.

I poked around in the emu and found that if this one byte was even, the face was to be draw, but if it was odd, then you had to skip it... really nutty cause the hide this in the exponent of the 32bit float O_O ??guess thats what you meant by bit masking?

Hi, mariokart64n.
Could your tool convert *.wpn files?
I think it is same structure that *.chr files.

-*.wpn samples at "\mdl\wpn\"-

porimac wrote:Hi, mariokart64n.
Could your tool convert *.wpn files?
I think it is same structure that *.chr files.

-*.wpn samples at "\mdl\wpn\"-

just change the name *.wpn to *.chr

just change the name *.wpn to *.chr

Oops, Sorry for my silly post.
I'm waiting for mario in feelings like a kid who looks forward to Santa Claus so.

Apparently some were not happy that I did not supply more details on the findings. I just want to say that I was only hesitant because of the over exposure and abuse I've been seeing alot of ripped 3d models since the release of tools such as noesis and umodel. I'm sure most know of what I'm talking about.

anyway it was not my intention to withhold any information, I didn't post the script last night because its buggy as hell its far from release ready. reguardless I'm posting the script and the spec details in hope someone with more programing skills can take over the project.

here's the maxscript: http://pastebin.com/Xt8jH2PF
the script was modified from a script that chrrox and codeman wrote last year (someone posted the same script above)

format specs..

the VIFtag info was already supply up top, and the PXY header is straight forward for any programmer hacker. so I'll only touch basis with the 2 problems that plagued the previous attempts
1. UVs
2. Faces


when vertex data is defined, its defined in two loops*count
the first loops defines the x,y,z of the position data and then the U of the texture coordinate.
the second loop contains the x,y,x of the vertex normal data, then the V of the texture coordinate.

its weird how they did that but pretty apparent when you look at it.

then you just generate for faces in a strip pattern, but you need a draw or don't draw flag to tell you when to restart the strip.

as I said last night they store this bit in the V of the texture coordinate
I just read the first byte of where the V float would be, then read the 1st bit... if the files even the bit should be 0 i think, if its an odd number the bits going to be 1.. using that I was able to proper draw the faces, with working UVs.

please forgive my sloppy interpretation of the format, i'm just a hobbyst hacker. please refer to the maxscript above if you want more details on how to read the geometry.

mariokart64n wrote:I've been seeing of ripped 3d models since the release of tools such as noesis and umodel. I'm sure most know of what I'm talking about.

Im kinda new and dont know. What's been going on?

Dear mariokart64n.
I can't tell you how thankful I am.
I would like to help you by something, But it seems that is difficult for me as long as it saw although..

not that this matters much, but I fixed the face directions in the script above. thanks to revel8n for pointing out my mistake.. forgot to reset the direction on each new strip [fixed]
http://pastebin.com/yFqzv6L5

Thanks, mario!! I got it!

Here is a xenosaga 3 fast import script for max.
Ill work on bones and weights next it does not look that hard to add.

Ill work on bones and weights next it does not look that hard to add.

Thank you so much, chrrox!
You are truly awesome...

Can someone upload kosmos textures from the 2 or 3 models from the game pls? I'll be gratefull