ccs file format... part 3

[Satoh]

Can't the sequential vertices form up a triangle in which 2 triangle form up a polygon?

Actually I am not sure what I am saying here, is there any trailing values right after the vertices data?
the character model do seem to have a different way if storing the 3d model [I am assuming due to other information like animation?] comparing to the normal models.

I am/had been trying to figure out the character model by comparing it with normal model data to see if something strikes out. If something does, then perhaps by skipping that values/bytes we would be able to export out the character model (without the extra animation/bone/linking/etc).

All that I know right now is character model is also broken into parts face/body/weapon instead of a single model file.

That's about the extent of what I've been thinking... I discovered that weapons seem to have a peculiar structure compared to static objects as well... I suppose since Forte's busy I'll have to scrutinize the source for his exporter...

Unfortunately I'll have to go find some more scrute for that... Luckily it seems to look enough like C# that I can understand the syntax and maybe(?) rewrite it... or at least glean the structure of weapons and in turn learn something about characters in the process... I wish MA were helping with this... he'd have this cracked in a number of days no doubt...

[Forte]

Can't the sequential vertices form up a triangle in which 2 triangle form up a polygon?

That wouldn't work, you really have to work with the tristrips.

If something does, then perhaps by skipping that values/bytes we would be able to export out the character model (without the extra animation/bone/linking/etc).

There's extra info right in the header. The rest of the chunk seems somewhat similar to the normal format, but exporting it as-is doesn't turn out well.

I'll try documenting the format.
A dword(integer) is 4 bytes and float is two bytes.

To calculate a float (byte0 and byte1 are signed bytes):
float f = ((byte0 & 0xFF) / 256f) + byte1

Basic format:

Code: Select all

//Header
dword chunkID //0xCCCC08000
dword chunkSize

struct Unknown0 {
byte unknown
} unknown0[20]
dword mdlType //assuming it's not 0x80000000 in which case the following structure is different
struct Unknown1 {
byte unknown
} unknown1[12]
dword vertexCount

//MeshData
//Vertices
struct Vector3f {
float x
float z
float y
} v[vertexCount]

if ((vertexCount % 2) == 1) { //ignore trailing zeroes that appear if the space used by the vertices is not multiple of 4
word trailingZero
}

//TriStrips
struct VertexConnection {
byte unknown0
byte unknown1
byte unknown2
byte connect
} vc[vertexCount]

//Unknown
struct Unknown2 {
dword unknown
} unknown2[vertexCount]

//UV
struct Vector2f {
float u
float v
} uv[vertexCount]

The connection byte in VertexConnection can either have 0, 1 or 2 as value.
2: reverse vertex connection
1: normal vertex connection
0: TriStrip end

You can count the zeroes to find out how many triangles there will be.

Now, the usual format is something like "1 or 2, 1 or 2, 0, 0". Let's assume the vertices these connections belong to are called A, B, C and D respectively.

For 1, 1, 0, 0:
Triangle1: ABC
Triangle2: CBD

For 2, 2, 0, 0:
Triangle1: BAC
Triangle2: BCD

If there is no 0 after the first 0:
For 1, 1, 0:
Triangle1: ABC

For 2, 2, 0:
Triangle1: BAC

As far as I'm aware, combinations like 1, 2, 0, 0 or 2, 2, 0, 0, 0 are not possible.

Now, there are three major problems at the moment:
1. Deal with chunks which have mdlType = 0x80000000
2. Deal with character models
3. Find rotation/scaling info

1. seems easy enough, but I haven't really checked yet.
2. I have no idea what to do about this. Even if I ignore the extra info, the models turn out completely wrong.
3. Haven't really looked into it yet; the info should be in the chunk header somewhere.
Examples would be the bird (proportions of body are wrong, and the wings' rotation seems to be wrong) and the bike (either the wheel is way to big or the main body is too small)
(Sorry, don't have the exact file names at the moment)

[FurryFan]

Can't the sequential vertices form up a triangle in which 2 triangle form up a polygon?

Actually I am not sure what I am saying here, is there any trailing values right after the vertices data?
the character model do seem to have a different way if storing the 3d model [I am assuming due to other information like animation?] comparing to the normal models.

I am/had been trying to figure out the character model by comparing it with normal model data to see if something strikes out. If something does, then perhaps by skipping that values/bytes we would be able to export out the character model (without the extra animation/bone/linking/etc).

All that I know right now is character model is also broken into parts face/body/weapon instead of a single model file.

That's about the extent of what I've been thinking... I discovered that weapons seem to have a peculiar structure compared to static objects as well... I suppose since Forte's busy I'll have to scrutinize the source for his exporter...

Unfortunately I'll have to go find some more scrute for that... Luckily it seems to look enough like C# that I can understand the syntax and maybe(?) rewrite it... or at least glean the structure of weapons and in turn learn something about characters in the process... I wish MA were helping with this... he'd have this cracked in a number of days no doubt...

I am pretty sure some data could be in Binary format that looks funny because the values for a say vertexes (as an example) could be spread between bytes. For example I know a few PS1 games like Spyro the Dragon and atleast one PS2 game (The Golden Compass) store vertexes X,Y and Z as something like the following:
11 SignedBits for the X (eg one full byte plus two Bits from the next byte) 11 SignedBits for the Y and 9 SignedBits (not a typo) for the Z plus a null bit, for a grand total for 32Bits=4 whole Bytes.
This is very unsymmetrical, and noncommunitive compared to simple 4byte floating point values for each vertex.
The advantage is that each vertex takes up only 1/3 the space of floats.
Please send me a sample character model file, and I'll see what I can do.
Even better would be an emulator save state, so I can manipulate each bit and deduce by seeing for far each vertex moves for each bit.

[Null2]

Hmm so how does someone, who doesn't know a lic or terminlogy explain what he's asking. Alright I know this maybe repetative but can someone explain this CCS format. I've extract them using the quickbms program but never seen anything like it before. I'm trying to get images from them. What else do I need to do. Also is there a tutorial? It doesn't matter how hard the work is I'd need to do I just want to understand what I'm doing. (Because it bugs me to all hell when I don't.) Is there a way to covert code into bmp? Can someone explain?

[raz]

If you just wanted to extract the image files, just use forte's tool. Otherwise it's more about reading the binary CLUT and exporting it out? (Need to refer to my notes back home)

Forte Tool
viewtopic.php?p=35504#p35504


CLUT Explanation
viewtopic.php?p=36522#p36522

[Null2]

Thanks, for me it's both. I want the images because that's mainly what "this" game is about. However I'm also here because I'd like to understand about file format, and conversion. I doubt it's something I'd carry beyond this but it makes me feel at ease when I can be more flexible with something because I know it. (Plus just looking at some of that mess inside the tmp files just ticked me off. It was like the haha of not being able to go further.)

[Anomy]

Did any of you end up making any progress on this?

[Forte]

I hate to revive such an old thread, but several people PM'd me already about the CCS2OBJ tool (since the link is long dead), so I'm reattaching it here.
No progress on it since the last post though.