Unused stuff and exploring the ccs file format *spoilers?*

[ForteGSOmega]

I'm not sure if this is the right place to post this, but I'll have a try.
The reason for this topic is twofold. Firstly, I've stumbled across some interesting stuff while looking through the textures of this games' models and secondly, I'd like to request some help/ideas on how to get to the models.

Let's start with the "more interesting" stuff.
Shortly before Haseo gets his Xth Form, he talks with Skeith, a white version of himself. We kinda never see his face so here's a side by side comparison:

Mostly just a palette swap, but the face really reminds of the B-st form. What's strange is that the game refers to the Xth form as "Haseo04" and to the white one as "Haseo0X" (and why not stick that palette into normals 3's file, anyway?)

It would also seem that there were supposed to be more AIDAs:


These were taken from the AIDA's respective models but I guess Bertha would just be a palette swap of Anna and Isabella a swap of Helen (and for some reason I can't view/find their other textures, same problem with Magus actually).

Lastly, the area where Harold was in .hack//Sign seems to be in this game:

This is the only area that has such a picture and there's all kinds of textures in the file that would fit to the place. (And this area's name is "test" so maybe it's some kind of debug room?)

If you wish to play around with that(Java 1.6 needed!): Download here

Open the Data.cvm from the game's DVD with IsoBuster or something like that and extract everything somewhere. Now start the program and drag a .ccs file onto it(or more than one). All textures that're found will be saved in ccspath/output/
Here is a sample file (a CVS card).

So, anyway. My goal is it to view the models but I've reached a complete dead end. If you have any idea about 3D in general, 3DS Max or game archives and wish to help or know where I could find some pointers, here's a summary of everything I've found out so far(the last page explains my current problem):
http://phorte.ph.ohost.de/ccs/ccs.pdf

[TheSorrow]

I have low experience with this (the most i've done is just use programs that automaticly rip the information like text files and textures and show them right away), and i've never touched any model-related program in my life (the closest to it is Photoshop .3.), but i'll try to help you with this, it REALLY interests me and seeing what's inside the games files and finding out stuff they took out of the final game is like crack to me XD

And that doesn't really look like the area in .Hack//SIGN, actually, it looks more like Lumina cloth o-o

[Master ZED]

Mostly just a palette swap, but the face really reminds of the B-st form.

Actually, the eyes indicate an AIDA infection. Strange, yes, but those are a typical set of eyes for the infected (I mean, just look at Sakaki in Reminisce when he infects himself, or Haseo while he's fighting Maxwell's AIDA), though it's probably just a coincidence since a) they look cool and b) you never get a good look at Skeith's face anyway. The X was likely to indicate an Epitaph PC model, as Skeith is the only one to take human form in R:2.

These were taken from the AIDA's respective models but I guess Bertha would just be a palette swap of Anna and Isabella a swap of Helen.

Agreed. They first appear in Reminisce's data and were likely the AIDA you were supposed to fight in place of the Anna encountered as Skeith the 2nd and the wild Helen encountered in a dungeon prior to... Megin Fi, I think? I guess CC2 felt they had too many palette swaps going already.

Lastly, the area where Harold was in .hack//Sign seems to be in this game:
image
This is the only area that has such a picture and there's all kinds of textures in the file that would fit to the place. (And this area's name is "test" so maybe it's some kind of debug room?)

That's just a photo of Breg Epona from underneath. Use a disabled model such as 1st form Haseo or AIDA Bordeaux and look around the city. The only good thing about those models in Redemption is that they have no collision detection and can walk through walls, so while they can't visit areas, you can still look anywhere around the cities with them.

I'll add more later once I've read that PDF... if I have anything further to contribute anyway.

[ForteGSOmega]

That's just a photo of Breg Epona from underneath. Use a disabled model such as 1st form Haseo or AIDA Bordeaux and look around the city. The only good thing about those models in Redemption is that they have no collision detection and can walk through walls, so while they can't visit areas, you can still look anywhere around the cities with them.

Now that you mention it, the textures are very similar but not exactly the same. Breg Epona is called town4 and this... something.. is called test03 and test04. For example, there's something that appears in both areas:

Test


Breg Epona


Generally, everything in test looks like it's been photographed (visible lighting) while Breg Epona has "bland" textures and the lighting is done in-game.
Gee, I wish we had the models to compare them <_< >_>

And by the way, I only skimmed through the Forums but you seem to have a fair idea of the game's innards. How come?

[_Tri-edge_]

It's interesting how you guys go WAY beyond the game itself for information. You two should probably work for Cyber Connect 2 in general.

Mostly just a palette swap, but the face really reminds of the B-st form.

In B-ST form, Haseo's eyes were completely white, with no pupils, and the wave symbols were more spikey as they resembled claw scratches, to suit the "animal/beast" style of the form.

[AuraTwilight]

ForteGSOmega. I hereby give you permission to propagate the next generation with me after humanity is destroyed.

[Haseo{Terror of Death}]

...so you like tore the disk apart?

[Master ZED]

And by the way, I only skimmed through the Forums but you seem to have a fair idea of the game's innards. How come?

TBQH, necessity. Hacking is something I take up only when whatever I'm after is otherwise out of my reach. I can't actually hack PS2 games, I can only read with what's given to me (PS2DIS, a hex editor, and that program to view things in DATA.CVM are all I have for G.U.), but I was able to whip up a fair amount of my own CB codes through good ol' trial and error using patch codes to erase certain data blocks that Skiller had already looked into. The keyword properties and portrait codes were things I saw in PS2DIS.

As for having seen the pics before, we already have hackstract.

[ForteGSOmega]

ForteGSOmega. I hereby give you permission to propagate the next generation with me after humanity is destroyed.

Yay, I guess <_<

...so you like tore the disk apart?

At least that's my goal, I only have textures and some text data so far.

As for having seen the pics before, we already have hackstract.

Looks like I'm a bit late, then. Although there's a difference:

Some of the images appear blank, or as a solid block of a color. This is because the original images use varying levels of transparency, which Windows Bitmaps ignore. The transparency levels are stored in the color palette (Red, Green, Blue, Alpha), which my program faithfully copies when you extract an image. A good example from the Outbreak and Quarantine data files is xddwal49, which contains several solid black images. They're not actually solid black, but black with varying degrees of transparency, being the black shadows you see on the Phantom of Nine wallpaper before you complete the event. The transparency allows the shadows to be overlaid on top of the background image without producing jagged edges.

That's exactly why I just use .pngs, there's no problem with transparency at all. His program also seems to have trouble with images which use a 16 color palette and it doesn't recognize the textures that have multiple palettes.
Pretty nice work though, and even one year earlier >_>
Does anyone know his contact details? There's nothing in the readme and he hasn't been here for a while...

And speaking of the original games; they use exactly the same format. That means that between the four years of the first original game and the first G.U. game, nothing's changed so there's a chance they'll keep the format for next(/this)-gen .hack games (or maybe it stayed the same because both series are for the same console?).
As for the models, I'm making some progress after reading up on other model formats. I think this game uses six bytes for a coordinate instead of the normal 12 bytes(three floats), so the question is how to decompress them.

[Satoh]

Sorry if this is necroposting, but this is the exact topic I've been wanting to create myself for years...

I have a friend--well acquaintance-- at qhimm that may be able to help decode the model format...

So you say that both GU and IMOQ appear to have the same model format? If that's indeed the case... well... I'd probably be able to die happy...

Anyway, as soon as I figure out what to say, and how to say it, I'll ask my acquaintance if he's interested in helping with the decoding... (he decoded the models for Final Fantasy Dissidia in less than a week... so... I have confidence that if he gets involved, it'll get done.)

As for cracking open the disc itself and extracting the .CCS's I'm gonna do that quite soon... I don't know much about decoding models... but I have helped before... Maybe I'll luck out on something.

Ok, well I thought I had a lead on something, but it's just your on a different forum XD;;

Also my friend is too busy... oh well... looks like I'm stuck with whatever info I can decipher myself...

[Satoh]

Sorry for the double post, but I believe this is some pertinent info...


The Barrier model in GU has a moving texture! I was reading your format document, and I can guess that the 0800 issue you were talking about could be some sort of instruction to make the texture map slide across the model's surface, rather than being static.

Before you say it would need coords, consider that it could be an equation or a piece of scripted code.

Personally I'm looking through the Spiral Edge model using your document to see if I can understand what's in there... I'm not great at reading hex, but I can make some guesses about things as I see the patterns.

I hope to have this figured out in the near future... (but hopes are only that.)

Also, not to sound condescending or anything... but have you tried running the MAX's through... 3DS Max?

The barrier itself is 2 flat planes of 8-10 quads each... using the camera trick I managed to cause single tris to disappear, meaning the format may not even use quads at all...

the info I gathered suggests that each plane is setup in two side-by-side columns of 4-5 quads(or 8-10 tris) like this
_ _
_ _
_ _
_ _

With _ being a set of one quad or 2 tris. The barrier extends into the wall, and does not seem to connect to the opposite side of the barrier, meaning 2 planes as opposed to one cube. (All info gathered using the no clip glitch attained by using haseo form 1 in redemption.)

[ForteGSOmega]

Oh my, now this I call luck. I haven't checked back in about two months and just decided to see if there was something new.

So you say that both GU and IMOQ appear to have the same model format? If that's indeed the case... well... I'd probably be able to die happy...

Yeah, I'm 100% sure. GU's model format is just a bit updated, but from the looks of it, IMOQ stuff would be even compatible with GU's engine.

Anyway, as soon as I figure out what to say, and how to say it, I'll ask my acquaintance if he's interested in helping with the decoding... (he decoded the models for Final Fantasy Dissidia in less than a week... so... I have confidence that if he gets involved, it'll get done.)

This would be really great. My greatest problem is that I have no experience with 3D file formats at all. It doesn't even have to be now or something.

The Barrier model in GU has a moving texture! I was reading your format document, and I can guess that the 0800 issue you were talking about could be some sort of instruction to make the texture map slide across the model's surface, rather than being static.

But even static models have 0800s, like the treasure boxes and whatnot. Though something like this could be indeed in the css. My priority, however, is to get the mesh data, so I'll look into that after that's done.

Before you say it would need coords, consider that it could be an equation or a piece of scripted code.

How would that work, exactly? Do you know any existing formats that work like that?

Also, not to sound condescending or anything... but have you tried running the MAX's through... 3DS Max?

Problem is, I don't know where each max starts/ends. And I tried looking at a "real" .max file, they look completely different than anything that's in a css.

The barrier itself is 2 flat planes of 8-10 quads each... using the camera trick I managed to cause single tris to disappear, meaning the format may not even use quads at all...

the info I gathered suggests that each plane is setup in two side-by-side columns of 4-5 quads(or 8-10 tris) like this
_ _
_ _
_ _
_ _

With _ being a set of one quad or 2 tris. The barrier extends into the wall, and does not seem to connect to the opposite side of the barrier, meaning 2 planes as opposed to one cube. (All info gathered using the no clip glitch attained by using haseo form 1 in redemption.)

I think I came to a similar conclusion once, but since I don't even know how much space a vertex(if they're used) takes up, I can't really do anything with that info.

[Satoh]

I have seen formats where model data and text information are both contained. I don't know if code or equations can be used in a model...

And I'm only interested in the mesh and UV data myself, but eliminating the unknown areas can help to un-hide the the verteces...

Unfortunately the person I mentioned is unavailable, as I said. I'm a bit of a novice myself, so I can only speculate, but I'm certainly gonna try to be of some help-- after all, I can make all sorts of cool stuff if I can get the models ripped...

As far as I can tell though, the .tmp could also have even more containers in it...

I would suggest looking at a few more files to try and find the mesh data, compare the patterns in the data that are similar... I'm using weapons because I KNOW their mesh data has to be in there since they are the only things in the EQ folder and no other folder has weapon textures...


EDIT: I did a basic search for max and tmp files,... I came across this description for .max... "PS2 Powersave File" I don't know what that is, but while unlikely, it could be related...

[Altre]

I've always wanted to do this! Where did you get these programs used to check out these specs?

[ForteGSOmega]

I would suggest looking at a few more files to try and find the mesh data, compare the patterns in the data that are similar... I'm using weapons because I KNOW their mesh data has to be in there since they are the only things in the EQ folder and no other folder has weapon textures...

And that's exactly what I've been doing the past two years (sounds like a lot, but I only worked occasionally on that)
Although I don't like weapons because they have multiple .max and also come with animations.
Some files of interest (from Redemption):

STAGE/AWAKE.CCS
-Nothing model related, but it's a very simple file where you can see the structure clearly.

STAGE/BLINK.CCS
-This one has only an animation and a texture(no mesh stuff?). Small.

EN/EGM10GST.CCS, NPC/2NPB00BRS.CCS and BIKE/XGBK01MUF1_1.CCS
-Smallest files with a single .max, no animations and the least "objects", the last one is clearly a muffler from the bike, so it's kinda cylindrical for sure.

Edit:

I've always wanted to do this! Where did you get these programs used to check out these specs?

I mostly work with Hex Workshop to view the files, although it may be confusing if you never worked with binary files.

EDIT: I did a basic search for max and tmp files,... I came across this description for .max... "PS2 Powersave File" I don't know what that is, but while unlikely, it could be related...

Somehow, it doesn't even look like the PS2 stands for Playstation 2. All I can find about "PS2 Powersave File" is related to Data Recovery.

[Satoh]

OKAY! I got something.

The beginning of the texture for d_barrier is at 0x000013EC and ends at 0x00001C5C

Now, you may ask how this helps? it eliminates any of that data as pertaining to the max at all.

I noticed, upon comparing the data in a tmp to a bmp rip from hackstract, that the tmp data is simply reversed endian from the bmp rip itself.

This means we can narrow down the area of search for the beginning and end of the max data... Though this may not be new to you, but it's progress for me XD...

EDIT: 0x00000974 to 0x00000A58 has some data of some kind... Previous to that there seems to be a listing of the alphabet and symbols that can be used by the engine... (ABCDEF....../~_? abcdef....) I'm not sure what that part is for...

but 974 - A58 may be verteces... I'm going to look into it further...

EDIT2: nope... it seems like data, but it's in between the lowercase and the numbers... so it can't be too pertinent...

EDIT3: HO **** I THINK I FOUND IT!


0xD3C - 0xEF5 of d_barrier.tmp seems to be the vert data. I say this because I see a recurring pattern.... they seem to follow coords for a flat plane. Seems like something good ne?

EDIT4: it could also be the UV map, as indicated by the file organization in the beginning of the tmp.

[ForteGSOmega]

0xD3C - 0xEF5 of d_barrier.tmp seems to be the vert data. I say this because I see a recurring pattern.... they seem to follow coords for a flat plane. Seems like something good ne?

EDIT4: it could also be the UV map, as indicated by the file organization in the beginning of the tmp.

Are you sure about d_barrier? The chunk that starts at D34 ends at D6C. It's likely that the chunk at D90 to 1280h has something to do with the model, but even if it is, the vertices are most likely encoded or something like that (like the Quake md2 file format).

Keep in mind to look at chunks as a whole, because the game must know where the relevant data is (from the respective headers), which is unlikely to be in the middle of nowhere. And even if a chunk had multiple types of data, the header would have info on that.

[Satoh]

0xD3C - 0xEF5 of d_barrier.tmp seems to be the vert data. I say this because I see a recurring pattern.... they seem to follow coords for a flat plane. Seems like something good ne?

EDIT4: it could also be the UV map, as indicated by the file organization in the beginning of the tmp.

Are you sure about d_barrier? The chunk that starts at D34 ends at D6C. It's likely that the chunk at D90 to 1280h has something to do with the model, but even if it is, the vertices are most likely encoded or something like that (like the Quake md2 file format).

Keep in mind to look at chunks as a whole, because the game must know where the relevant data is (from the respective headers), which is unlikely to be in the middle of nowhere. And even if a chunk had multiple types of data, the header would have info on that.

Yeah I considered that, but I'm not sure how the GU headers are setup... Besides... I was looking through manually.

I also had a sudden fear... Couldn't this also be the in-battle barrier?

I ask because when I looked through Dungeon4, I noticed two textures not unlike xebase... If that were the case then we'd be looking for the wrong thing entirely... or I would be anyway...

It would be very sad if these .tmp's were standard windows Temp folders.... which would mean they're a common format, but still no real simple way to open them directly...

EDIT: It occurred to me that these .tmp's could be .max's themselves... I don't have any Max 2007 files to work with though, so I can't say for certain... I haven't used Max in a long time since I discovered the ease of modeling in Maya...

Also, it might be beneficial to try decoding an IMOQ .tmp if they're the same, (or slightly downgraded from GU as you said) they might be a good stepping stone for figuring out some of the mysteries of GU's files later... granted this might take longer...

[ForteGSOmega]

It occurred to me that these .tmp's could be .max's themselves... I don't have any Max 2007 files to work with though, so I can't say for certain... I haven't used Max in a long time since I discovered the ease of modeling in Maya...

Been there, done that. Completely different structure.

Also, it might be beneficial to try decoding an IMOQ .tmp if they're the same, (or slightly downgraded from GU as you said) they might be a good stepping stone for figuring out some of the mysteries of GU's files later... granted this might take longer...

I remember trying around with them but for some reason, which I have long forgotten, I decided to stick with GU's files. It might be worth trying, though.
I'll look into them again some time.

[Satoh]

I've got a bad feeling that these .TMP's are partially compressed... which would mean the vertex data may not even be accessible at all until we pull out the .MAX's...

And I just realized... these files are backwards! The BMP data was in reverse endian compared to a windows endian format, which means even if we found the vertex data, we might not be able to recognize it because it would be out of order!

This means if we could apply the process to extract the BMP data to the entire file, we may just get something that makes sense. But this is just a hypothesis... I hope my conjecture doesn't come off as simply annoying, I am trying to help.

I'm probably about as novice as it gets at reading hex info directly... (aside from not being able at all...)

EDIT: I suspect the CCCC____ data are all some sort of opcode format... As I was looking I noticed that all of the padded alphabet data has exactly one CCCCFF01 in between them... I'm not positive, but I think this is something to allow the game to create the dialogue box that appears when you attempt to cross it without killing the monsters first. (It says something to the extent of 'This is a barrier, you have to kill all of the enemies in the area to deactivate it' when clicked on.)