.hack CMP/TMP/CCS, Inspection and inquery. Fresh Start.

[Satoh]

The contents of this post was deleted because of possible forum rules violation.

[finale00]

I'm looking at the cts5 file and went to 0x7C0, but am not getting the coords you wrote down.
Maybe they're a different kind of float that's common for PS2 games? lol I tried switching endian but didn't see those values either.

[Satoh]

I'm looking at the cts5 file and went to 0x7C0, but am not getting the coords you wrote down.
Maybe they're a different kind of float that's common for PS2 games? lol I tried switching endian but didn't see those values either.

Oops, I forgot to write down that all the numbers are Int16... There are no floats as far as I can tell.

CTS5 has a basic planar structure, as the character is drawn as a sprite that spins around... basically it's a rectangular model like so:
* * *
* * *
* * *
I can draw the vertices and they work fine, and they seem to be noted in order of triangulation, in that the vertices that are noted are each in a triangle formation in a seemingly clockwise order, but the problem I run into is I'm not sure A: what the rest of the data means, or B: how to use the order of the coordinates to effectively feed noesis the triangle data...

Well... that and obviously not knowing where the UV's are (aside from guessing) and any other problems I already mentioned of course... but what I'm struggling with mainly is turning raw positions into triangles, and then figuring out how to make individual triangles into strips and such...

Also, for sake of simpicity, here is the beginning and end of the data that contains model info (as far as I can tell) in the CTS5 file. Other files are going to be much larger obviously, but I picked this one mainly for it's simple design. I knew what the coords should look like to begin with (rectangular... no odd spheres or anything complicated)



I THINK all the data I've gathered holds true for MDL headers in other files(there are odd deviations in some files, but they still contain at least one header that fits these observations, I need to know how to differentiate between them)

In the first line, you see a 0008CCCC tag. That is what I believe to be the single bone for this file, as the positional vertex count for that header (0x788) is 0x02 00 00 00 and directly after that is 6 int16's, indicating two vertices. After that, the highlighted portion, is the MDL header for the main mesh data. the portion after the highlighted data is the mesh data, and the last line in the image is the last line before the CLUT for the texture data in the file.

Sorry if I seem to repeat myself or am longwinded... but I figure the less you all need to figure out on your own, the better chances of me getting worthwhile help

As I mentioned, nothing I've found in this format so far, is a float of any kind I'm familiar with. Everything is signed Int data as far as I can tell.

[finale00]

Is it possible that some parts of the file are still encrypted?

[Satoh]

Is it possible that some parts of the file are still encrypted?

I think it's more likely the files are just incredibly inefficient or poorly designed... The only sort of encryption I've seen on any of the files was a simple gzip compression... which isn't even technically encryption.

I missed something in my screenshot as well... The last four lines of it are in fact the material header and the bounding box header...

I believe the 0x8A0 portion to be most likely the UV data, using absolute pixel counts as the orientation... They seem to be, at first glance, the same order as the vertex coordinates... perhaps this is why some vertices are duplicated... so that the UV data can have multiple UV's to a vertex... though it seems moot in this CTS5... more testing is required I suppose...

what really bothers me is the 0x00 C0 00 01 and 0x80 80 80 80 portions.... maybe it's simply due to this file being simple, but they really seem sort of odd and useless... I'm sure they're NOT useless... but even still what the heck do they do??

Unfortunately, if I'm reading my noesis test data correctly, some models use deform shapes... which means I can't really say what is and what isn't a pertinent mesh... elga.cmp contains many copies of the same model, or maybe my importer is going haywire... so many variables, why do I enjoy doing this stuff??

I might be able to test more if I better understood the noesis API... I guess I'll work on that for a bit.

EDIT: The second portion (0x00 C0 00 01... in this file) May be... normals and triangle strip data...? nx1 ny1 nz1 connected1 ?
Where connection = 1, the triangle is connected to the last triangle... and connection = 0 it is not...? I wonder how to program noesis to test this...

Also, the vertex count seems like it may in fact be a -face- count instead... A two sided plane made of 4 rectangular divisions is in fact 8 polygons to either side, totaling 16 or 0x10...
Is it coincidental that this works out as both a vertex count and a face count? Maybe these files are more efficient than I thought... but still pretty confusing...