CHRONO CROSS FILE EXPLORATION THREAD

[Unaisis]

After fiddling around with blender ::First time using:: i managed to export it in a format that i could use in the 3d program i have ::Cinema 4d:: in that program i was able to make an alpha for glens hair. although i doubt cinema 4d will be able to run animations originally from the game, or help you guys out in any way  T.T ....

[attachment deleted by admin]

[justin3009]

O___O!  That look's so cool!

[Ozzie]

I agree, it looks awesome, the models look excellent when in use, you can really see what a great job they did when creating them.

Also... I find it amusing that the first time human Glenn wonders out of Chrono Cross he winds up in extreme peril. 

[Unaisis]

indeed, excellent produce from excellent workmanship ^.^.

[secondrate]

Already been done.
 "00" == black color in blender.
 "00" == transparent color in a PS1.
Blender does not understand transparent UV maps. 

Sorry for making you repeat yourself...

I had another thought: I wonder...can a fourth UV coordinate be made, to transform the triangles into quads, and then overlay that coordinate to the 2nd UV coordinate?

[FaustWolf]

I may not be understanding the problem correctly, but I was under the impression that the major difficulty here is that the model uses a solid square or something for Glenn's bangs instead of modeling the hair pieces separately, to save on vertex space. Normally the black parts pasted over that polygon would be rendered transparent by the game engine, but Blender is incapable of transparencies. So extra polygons would have to be added, and then the UV coordinates would have to be changed such that they trace out the hair and apply them to the additional polygons.

Unaisis, what did you do exactly with Glenn's model (i.e., I don't know what it means to "add an alpha" )? If it's possible to re-export to Blender, the Compendium could archive the altered model.

[Unaisis]

Well... an alpha in cinema 4d is just the same picture but in black and white ::white being the visible part and black as the  invisible part:: cinema 4d has an option for this @.@.

below is the alpha picture

[attachment deleted by admin]

[jono]

I'd just like to ask a couple of questions about the current knowledge of the model file format. I'm slowly getting through the guide however some parts are bothering me.

In section 1 I'm having a little trouble understanding the following:

Code: [Select]

16-byte mode vertex assignment header format: #A #A #A #A PP PP PP PP
16-byte mode vertex assigment format: NV NV 00 00 J1 J1 W1 W1 J2 J2 W2 W2
   Where...
   #A: Number of assignments that follow.
   NV: Next NV Vertices are assigned to J1 J1 and J2 J2.
   VO = Offset into the Vertex Pool, relative to the VP offset given in the Construct Header.
   J1: Index of the first joint to which the body of vertices is assigned.
   W1: Weight of the association between NV and J1 for animation purposes.
   J2: Index of the second joint to which the body of vertices is assigned.
   W2: Weight of the association between NV and J2 for animation purposes.
Is PP simply the offset into the vertex pool? In other words, is PP equivilent to VO.
Also in the 16-byte assignments are the two zeroed bytes in the assignment format just zeroed bytes (packing to keep to the four byte allignment), or do they contain values and the '00' are a symbol that isn't defined here?

I only ask about the '00' being used as a symbol because lower in the document I believe it is.

If I understand correctly perhaps the VO should be changed to PP (or vise-versa) and maybe the VO and NV definitions could be swapped to better represent the order of the actual bytes. Also maybe the two zeroed bytes (if thats what they are) should have a note just to clarify that they are zeroed bytes or otherwise.

Sorry to nit-pick, you guys have done a fantastic job with all this, just looking for a little clarification .

Cheers, Jono.

EDIT:

Also I was wondering where the '**' byte is in the vertex pool information. I understand its purpose but don't understand which byte is the direction reversal byte. I think I'm missing something, any explination would be much appreciated.

Code: [Select]

"8-byte mode" setup...
   ZZ ZZ YY YY XX XX 00 00 - ZZ ZZ YY YY XX XX 01 00
   ZZ ZZ YY YY XX XX 02 00 - ZZ ZZ YY YY XX XX 03 00
  "16-byte mode" setup...
   ZZ ZZ YY YY XX XX 00 00 - ZZ ZZ YY YY XX XX 00 00
   ZZ ZZ YY YY XX XX 01 00 - ZZ ZZ YY YY XX XX 01 00
    Where...
    ZZ: Magnitude of coordinate on the up & down axis on the screen plane
    YY: Magnitude of coordinate on depth axis; toward or away from you with respect to the
        screen.
    XX: Magnitude of coordinate on right & left axis on the screen plane
    **: A directional reverser byte. If 00, the vertex is placed in one direction on the axis,
        and if FF, the vertex gets placed on a coordinate the same "magnitude" but opposite 
        direction on that axis. (In actuality, it merely specifies whether the value is
        positive or negative in hex).
 00 00: The vertex index; two bytes per vertex.
Thanks again for all you hard work guys!

[FaustWolf]

Thanks for the astute observations, jono! Those were my wikification flubs, and have now been corrected.

1.) PP PP should be VO VO, just as you stated.
2.) The 00 bytes in the 16-byte mode vertex assignments are, indeed, just buffers.
3.) Oopsie, I did away with the directional reverser byte concept altogether when MDenham informed me that the 3D axis magnitude values include two bytes, and when it reads something like ?? FF or ?? FE, the magnitude is simply negative because it's a negative hex value.

Take a look at it again when you get a chance and make sure that all your points are now addressed.

[jono]

when it reads something like ?? FF or ?? FE, the magnitude is simply negative because it's a negative hex value

So I should read the x,y and z co-ordinates of the vertex as signed 16 bit numbers rather than as unsigned magnitudes with seperate information for direction. In other words the direction (-ve or +ve) of a vertex co-ordinate is given by the first bit of the second byte for that co-ordinate. Correct me if I miss understand

Sounds good, thanks for clearing that up, I'm still playing catch up with all that you guys have done and every bit of help is appreciated. 

[MDenham]

when it reads something like ?? FF or ?? FE, the magnitude is simply negative because it's a negative hex value

So I should read the x,y and z co-ordinates of the vertex as signed 16 bit numbers rather than as unsigned magnitudes with seperate information for direction. In other words the direction (-ve or +ve) of a vertex co-ordinate is given by the first bit of the second byte for that co-ordinate. Correct me if I miss understand

Well, correctly, they're not just a signed 16-bit number; they're a signed fixed-point (4.12, I believe) number.

Not like it matters a whole lot, but it's good to keep in mind (especially as rotations are in the same format - "1.0" = a full rotation).

[jono]

Ahh, ok, I thought they would be fixed point but had wondered how they would be split. Signed 4.12 fixed point numbers, thanks mate.

[FaustWolf]

Alrighty, I'd better get the signed fixed-point info in the wiki. I'll have some reading to do here first. What's the significance of the number 4.12 with respect to the 3D coordinates, guys?

[halkun]

Alrighty, I'd better get the signed fixed-point info in the wiki. I'll have some reading to do here first. What's the significance of the number 4.12 with respect to the 3D coordinates, guys?

The PSX had a 3D coprocessor called the Geometry Transformation Engine, or GTE. This device did various 3D maths (Dot products, matrix transformations, vector math, etc, etc) much faster than the normal CPU. The GTE used fixed point 16-bit numbers. the first 4 bits are the whole number part and the second 12 bits were the decimal part. (4.12) This means that when you loaded the GTE with number to preform math on, it had to be in 4.12 format.

Oops here a little vocabulary.

Fixed-point is a kind of format that computers use to express decimals. Computer, by themselves, are quite terrible at decimal math, so this is a way for them to "understand" what a decimal is. "Fixed point" means that the decimal does not move, and the whole/factional parts are "stuck" at a particular accuracy. With computers, fixed point math is really quick, but is prone to rounding errors. (That's why you see "warped" textures on the PSX sometimes... That and there is an actual bug in the GTE that Sony never fixed. On the other hand, if Sony fixed it, it would of screwed up all the games before it was fixed). The opposite of fixed point is "floating point"

Floating point is a number where the decimal point can float all around the number so the system is not limited to a particular whole/factional split all the time. The problem is floating point is *MUCH* slower and *much* more complex and expensive to implement in a computer. The PSX can not do hardware-based floating point math, and is stuck using a 4.12 format when it needs to do anything with a decimal quickly.

Does that make sense?

 

[FaustWolf]

Crystal clear. Thanks as always!