FF8 - Battle stage model (.X)

[MaKiPL]

I recently began researching this .X file from FF8, but I met some problems I can't figure out. I read all TIM, TMD specifications, searched for headers, everything...

First, I am attaching sample file. Here's what I found:

This is Textured model, with hardcoded texture.
Texture is uncompressed .TIM, that can be found at header

Code: Select all

10 00 00 00 09

, in a0stg105 case it's 0x8070.
File contains camera animation, that starts probably at 0x5d4, with:

Code: Select all

02 00 08 00 20

.
Next is probably vertices, that looks like TMD, has similiar ASCII pattern, but there's no header, and I can't find any software that can read RAW bytes in TMD way. By HEX'ing I found, that there're three objects there. Every new object starts with specific:

Code: Select all

01 00 00 00 08 00 00...

, also I found pattern, that has increasing ID, has 24bytes and ends with 0x2c.
Sample:

Code: Select all

20 00 35 00 21 00 36 00 54 9c 80 3c 54 68 b2 00 7e 9c 7e 68 80 80 80 2c

that is probably:
0x0 (1B) - Stands for ID, with every verticle it raises up by 1.
0x2 (1B) - Same as above (?)
0x3 (17B) - Not yet researched
0x21 (3B) - It does repeat in every single object
0x24 (1B) - End of object.

Also, there's second pattern, that doesn't match above, but also deletes triangles. Sample 16 bytes:

Code: Select all

4e 0c 4e 0c   00 00 4e 0c   68 10 00 00   4e 0c 99 ef

See? It looks like a place, where it does connects everything into faces, but this also makes no sense, because:
null'ying every 4 byte deletes one face, it's okay, but changing this to some other variables like aa aa 0c 0c makes the triangle go high up the world. This could be TMD, but even with documentation, I just can't find anything that make it work.
Please help!
Thread on Qhimm:
http://forums.qhimm.com/index.php?topic ... 223521#new

[shakotay2]

the places where you assume objects to start reveal some patterns:

a0stg105.JPG

First I thought of vertex blocks with a size of 24 bytes and face indices contained, but they are to regular:
(0x51EE: cnt= 20)
51f4: 1 21 2 22
520c: 2 22 3 23
5224: 3 23 4 24
523c: 4 24 5 25
5254: 5 25 6 26
526c: 6 26 7 27
5284: 7 27 8 28
529c: 8 28 9 29
52b4: 9 29 10 30
52cc: 10 30 11 31
52e4: 11 31 12 32
52fc: 12 32 13 33
5314: 13 33 14 34
532c: 14 34 15 35
5344: 15 35 16 36
535c: 16 36 17 37
5374: 17 37 18 38
538c: 18 38 19 39
53a4: 19 39 20 40
53bc: 20 40 1 21
53d4: 2 2 121 6832
----------------------
(0x56B2: cnt=100)
56b8: 1 21 2 22
56d0: 2 22 3 23
56e8: 3 23 4 24
5700: 4 24 5 25
5718: 5 25 6 26
5730: 6 26 7 27
5748: 7 27 8 28
5760: 8 28 9 29
5778: 9 29 10 30
5790: 10 30 11 31
57a8: 11 31 12 32
57c0: 12 32 13 33
57d8: 13 33 14 34
57f0: 14 34 15 35
5808: 15 35 16 36
5820: 16 36 17 37
5838: 17 37 18 38
5850: 18 38 19 39
5868: 19 39 20 40
5880: 20 40 1 21
5898: 21 41 22 42
58b0: 22 42 23 43
...
5fa0: 96 116 97 117
5fb8: 97 117 98 118
5fd0: 98 118 99 119
5fe8: 99 119 100 120
6000: 100 120 81 101
-------------------------

[MaKiPL]

That's probably it. Basically, this stage model has three objects:

1.Ground (simple plane)
2.Spherical mesh with some details (Either sky or BG)
3.As above

So, use of Hex2OBJ was an excellent one. I of course modified the parameters, so I got no flying vertices beneath the first object which is a plane, so I got . I read your tutorial, but I couldn't find so called "alphabet" thing. In tutorial there were clear "byte 00 byte 00 byte 00", here I'm having . This is totally other "alphabet" thing. Could you help me some more with this?




Also, there's a stage, that contains only plane for ground, and spherical sky. This one contains UV layout in texture, maybe this could be useful.
. There are numbers on the right from 00 to FF.
First object, the ground:

Thank you very much shakotay2.

[shakotay2]

This is totally other "alphabet" thing. Could you help me some more with this?

face indices as a continous scrambled alphabet is the simple version.
They also maybe appear like this:

Code: Select all

Offset 00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F

..007500 00 00 00 00 00 00 40 00 00 00 00 00 00 00 01 00
..007510 03 00 02 00 01 CF 00 3D 01 BC B3 00 20 CF 20 BC
..007520 80 80 80 2C 03 00 02 00 05 00 04 00 20 CF 00 3D
..007530 20 BC B3 00 40 CF 40 BC 80 80 80 2C 05 00 04 00
..007540 07 00 06 00 40 CF 00 3D 40 BC B3 00 5F CF 5F BC

But the max face index (80) is greater than the count of this block (64) so they may be just continous indices, not faces indices.
7ac4: 62 78 63 79
7adc: 63 79 64 80
7af4: 64 80 49 65

(Sadly the vertices of this block seem to concentrate on 4 little spots only.)

There are numbers on the right from 00 to FF.

which tool did you use?
In Texturefinder it looks like this:

a0stg160.JPG

[MaKiPL]

It's a TIM texture, so TextureFinder will make the texture look with wrong colors. Either way is to use TIMviewer, or cut bytes to end from header

Code: Select all

10 00 00 00 08

, and save as .TIM, then open in graphic software that is capable in opening this.

Here: http://www.zophar.net/utilities/psxutil/tim-viewer.html

I pointed that file, because it has that ground, that is just a plane, but has this simple UV for it, so the UV for this plane is just... a plane.

[shakotay2]

thx, I have that viewer on my harddrive, even a newer version (v.104b) but seems I've forgotten it
(rare to no use because I don't have a console ).

[MaKiPL]

I cut the objects from the header

Code: Select all

01 00 00 00 08

to three files. Then tried to work on those objects individually. How long is one vertex? I took ,
divided length by 6, and I got 152, which looks exactly like a stage vertices. . The additional vertices by the main square are as I can see in-game some extension to ground. The model unfortunately contains UV, this harders face searching. In tutorial, you're dividing it by 2, maybe this face has more size than WORD.



EDIT:

Looks like I found it, but this giant numbers inside are making the max vertex index go great also.
I can do manually "Cut" those things, but does this do the thing?



Notes:
* I'm at school ATM, so I leave here some notes:
0xC - 152
01 - 01 ~3D-5? ...

[shakotay2]

In tutorial, you're dividing it by 2, maybe this face has more size than WORD.

yes, "face indices" (not "faces") can be DWORDs (or even bytes in some rare cases).

Looks like I found it, but this giant numbers inside are making the max vertex index go great also.
I can do manually "Cut" those things, but does this do the thing?

well, it's not too easy with face indices in this format.
What you mention starts from 0x8F4 and I don't think they are face indices (too regular and the max face index is 137, which should equal the vertex count)
8f4: 1 2 10 11
90c: 2 3 11 12
924: 3 4 12 13
93c: 4 5 13 14
954: 5 6 14 15
96c: 6 7 15 16
984: 7 8 16 17
99c: 8 9 17 18
...
126c: 132 123 131 126
1284: 124 125 127 128
129c: 131 126 130 129
# max fInd= 137

Also it's 4 indices (quads, which hex2obj doesn't handle) instead of 3 for triangles. (the column after the address column could contain just a simple counter but after 107 it steps to 137)


What looks more like face indices (but I'm not sure) is this:

3a4: 1 138 2
3b8: 2 138 139
3cc: 2 139 3
3e0: 3 139 4
3f4: 4 139 140
408: 4 140 5
41c: 5 140 6
430: 6 140 141
444: 6 141 7
458: 7 141 8
46c: 8 141 142
480: 8 142 9
494: 18 9 143
4a8: 18 143 135
4bc: 27 18 135
4d0: 27 135 36
4e4: 36 135 133
4f8: 45 36 133
50c: 45 133 54
520: 54 133 132
534: 63 54 132
548: 72 63 132
55c: 72 132 131
570: 81 72 131
584: 90 81 131
598: 90 131 130
5ac: 99 90 130
5c0: 108 99 130
5d4: 108 130 144
5e8: 117 108 144
5fc: 116 117 145
610: 116 145 146
624: 115 116 146
638: 114 115 146
64c: 114 146 147
660: 113 114 147
674: 112 113 147
688: 112 147 148
69c: 111 112 148
6b0: 110 111 148
6c4: 110 148 149
6d8: 109 110 149
6ec: 109 150 100
700: 100 150 128
714: 100 128 91
728: 91 128 82
73c: 82 128 125
750: 82 125 73
764: 73 125 64
778: 64 125 122
78c: 64 122 55
7a0: 55 122 46
7b4: 46 122 119
7c8: 46 119 37
7dc: 37 119 28
7f0: 28 119 136
804: 28 136 19
818: 19 136 10
82c: 10 136 151
840: 10 151 1
854: 137 151 136
868: 151 138 1
87c: 9 142 143
890: 135 143 134
8a4: 130 129 144
8b8: 117 144 145
8cc: 150 109 149
8e0: 127 128 150

max face index is 151

Together with your vertices from 0x0C it looks like this:

TestMesh.JPG

but it's just the result of combining regular vertices with regular indices.
Many vertices are not connected. So I don't think it's the solution.

[MaKiPL]

Found a vertices length byte location. Tested in on many levels.

This is another stage, where I was testing this way:



Structure:
After

Code: Select all

01 00 00 00 08

header, there's from 20 to even 160 on some maps of data, to get to vertices length byte. See here:


Yellow selected bytes, are starting from that header, to get to length byte, we have to find the nearest 01 00 01 00 ** 00 STRT.
Where ** is DEC(uint) containing vertices amount. Vertices start two bytes after that (5c on screen, in red square). Then either:

a) ByteLength*6=Bytes of vertices data. (They're ending with set of 00, and probably another length appears, this time two bytes, as this section is way higher than 255.
b) Just put offset of ByteLengthOffset+2, and in count in HEX2OBJ - DEC of ByteOffset.



Also, the starting section of the file is having probably scene animation data. In every static stage, it's header is always the same, up to 500+ bytes and more. I took a look at levels, where there is animation like flowing lava, then the header is totally different.

Oh, I just want to write thanks to you, because without you we wouldn't get so far with this. Thank you shakotay2!

[shakotay2]

Oh, I just want to write thanks to you, because without you we wouldn't get so far with this. Thank you shakotay2!

you're welcome.
Always nice to see people making senseful use of hex2obj (seems there are not too many ).

For the face indices you might have a look at a smaller object like a chest or a book
(though I don't know whether the indices in there follow the same rules as with level meshes).

[MaKiPL]

Okay. Made it.

All levels use quads. The only thing I could rip with HEX2OBJ is:

Do you know any software working with quads, that can help me get over this?
Also UV in this format is hardcoded in 20 bytes quad info. Where one quad has:

8 bytes of data, for 2 uint's each point.
12 bytes for texture ID's and etc, even with brightness.

I could use a plugin source for Noesis's FF8 .DAT open.
It has pre-made texture coord's reader, the same stage models are using, and also some .DAT files contained quads, that Noesis is just doing fine with them.

[shakotay2]

PMed you.
(try a face index offset of ( quadinfo_size - 8 ) in the editbox left to the checkbox)

for me it looks like this:

a0stg105_.JPG

The holes might be a problem of face culling which Noesis and other 3D programs can handle.
(maybe the mesh_viewer hex2obj uses has an option for it)

edit: well, smaller holes but mesh overlap with 'face cull' in Noesis when loading the
hex2obj-created test.obj. Seems there's still too less face indices.

[MaKiPL]

same here

That format uses also mixed way - has a info for triangles, and quads. But for stages the triangles length byte is set to 00 00, so only quads are present. Hmph. After vertices data, there's 00's padding, and just after that is XX YY, where:
xx- 20 bytes (triangle)
yy- 24 bytes (quad)

I'll search on old topics about FF8 animated objects, they also contained quads and I think I remember similiar problem we do have here.

[MaKiPL]

User on Qhimm posted link to a old topic regarding other file reverse. They also had the same problem, here's the link for synopsis on this "half triangle invisible " thing: http://everything2.com/user/TheMoog/wri ... ngle+strip
This model is complete, just needs some post-processing for tweaking this half triangle.

[shakotay2]

Not sure whether this is a "triangle strip" problem, since we've quads here.

Maybe there's a simple solution:
have a look at the upper left part of the attached picture:

quadMe.JPG

The "bad" quad is f 4 3 6 5

# 0x732a: verts= 80
v 108.265625 23.437500 44.847656
v 108.265625 0.000000 44.847656
v 82.863281 23.437500 82.863281
v 82.863281 0.000000 82.863281
v 44.847656 23.437500 108.265625
v 44.847656 0.000000 108.265625

f 1 2 4 3
f 4 3 6 5

This is the position of vertices in space.

5 3 1
6 4 2

connecting 4,3,6,5,4 reveals a "crossing" of vertices

so the 2nd quad should be
f 4 3 5 6

So for all even quads the face indice 3 and 4 to be swapped?
Maybe it's as simple as that.

Well, "even" simpler: all quads to be handled as such.
But other problems arise, too complex for me (view lower part of pic)

How to decide which quads to be swapped and which not, that's the question.