Thunder Brigade 3D format - kindly asking for help

[Einheit-101]

Hello everyone! I got sent here by a true archive expert (Watto) in order to ask for help trying to find out how to do anything with 3D models from Thunder Brigade, an old game from 1998. Watto managed to extract the files from their DAT archives in no time but the files are obviously not easily readable. They have no extension and contain no clear text (like Aquanox MSH or X3 bod files, easy).

The models of this game are pretty low poly and simple structured. I don't know if this is just a well known old format where just the file ending is missing. I am sure someone who has a little bit of experience can quickly find more information or give at least some help deciphering the data. We don't even need texture coordinates, the raw mesh or even vertices alone would be more than enough. I would gladly pay you a coffee or two for a success here.

I uploaded 3 examples on my dropbox, UTH and UTH+ are flying tanks and TH2 could be a building, the file is very small, maybe only a part of a building. Thanks everyone and greetings, Einheit-101. 

https://www.dropbox.com/scl/fi/bd5onc8n52tgik0dzyzx9/UTB?rlkey=9y5r0q9oeccpwt74qe4ylufrc&dl=0

https://www.dropbox.com/scl/fi/fgi3yno3j79dndwsx6mm1/UTB?rlkey=ku6gnwhs4xb756b8jy65s7h5f&dl=0

https://www.dropbox.com/scl/fi/9t09k7zz4vkccklylv2t7/TH2?rlkey=9bboxbvsfi49c2vzfwuf0r9pr&dl=0

[shak-otay]

There's some mesh structure, but the face indices need some filtering, I guess:

TH2

[Einheit-101]

I have seen that program during my research. Maybe i can try that out on UTB since I know exactly what it should look like and we can find correct values by fiddling around with that program. 

[Einheit-101]

I have looked into it and your hex2obj seems to be able to read this format just fine with the right settings. 

TH2 is a homing missile model, I found it in the game and connected a few vertices from your obj manually in 3ds max:
Now all we need is a way to find start and end points for hex2obj reliably for all 3D models and as a bonus the ability to automatically connect these faces. A good first step however!

Edited November 4 by Einheit-101

[shak-otay]

The DWORD offset to the vertex floats blocks can be found at file offset 0x1C. You'll need to add 12 (decimal) to get the start address of vertices.

edit: face indices for UTB+ are strange and don't fit the vertices at 0x52C4:

f 221 22 23
f 209 24 25
f 207 26 27
f 205 28 29
f 446 30 31
f 442 32 33
f 203 34 35
f 201 36 37
f 199 38 39
f 197 26 40
f 195 41 42
f 191 43 44
f 189 45 46
f 366 47 48
f 360 49 50
f 185 51 52
f 105 53 54
f 95 55 56
f 91 57 58
f 87 53 59
f 83 60 61
f 79 62 63
f 54 64 65
f 46 66 67
f 77 68 69
f 34 70 71
f 28 72 73
f 20 74 75
f 14 104 105
f 42 119 120
f 64 78 121
f 60 132 133
f 85 131 120
f 72 74 136
f 84 91 137
f 76 109 143
f 102 89 144
f 96 161 162
f 136 163 164
f 103 130 162
f 101 171 176
f 122 177 181
f 128 192 193
f 147 194 195
f 228 196 197
f 224 198 199
f 117 200 201
f 148 202 203
f 142 185 221
f 143 49 222
f 141 223 224
f 139 225 226
f 133 225 227
f 172 228 224
f 131 229 227
f 158 231 236
f 164 244 245
f 192 242 243
f 137 250 252
f 190 237 260
f 206 250 252
f 216 250 183
f 222 250 265
f 220 6 272
f 155 273 274
f 151 277 278
f 153 277 283
f 244 286 287
f 183 288 289
f 179 290 291
f 177 292 293
f 175 294 295
f 173 296 297
f 278 290 298
f 169 303 313
f 272 314 315
f 264 336 337
f 294 340 341
f 304 276 349
f 310 296 352
f 334 215 353
f 328 348 363
f 344 180 365

Edited November 4 by shak-otay

[h3x3r]

It's voxel if it's matter..

[shak-otay]

Hi! That's funny - so I tried to interprete voxel data as face indices?

Do I have to apply the marching cubes algo to those voxels to get a polygonal surface?

If so I need to build a voxel array from the concerning data; That means to assign an array v[0,0,0] to v[n-1,n-1,n-1] n*n*n values (integers)?

edit: forget, what I wrote: seems I need to become familiar with MeshLab

Edited November 5 by shak-otay

[Einheit-101]

On 11/4/2024 at 1:38 PM, shak-otay said:

The DWORD offset to the vertex floats blocks can be found at file offset 0x1C. You'll need to add 12 (decimal) to get the start address of vertices.

So you literally select the 2 bytes at 0x1C, get that decimal number, add 12 to it and whoops, you get to the exact byte where the vertices start? Thats quite simple (I guess your "12" is found by experience?)
That means 3F76 is the starting point for File UTB. Got it. So thats the value used for Step 3, except for the vertex count. I found 920 vertices by just trying to set higher numbers at the "go3" area and a count of 921 will deliver -99999999 as last result, which is a clear sign that 920 is the end for that model, am i right?
Finding the right vertex count with try&error method may work pretty well on these models thanks to the fact that the models are rather simple. I successfully imported all vertices of that UTB model, its btw called a "BCC-110 Talon", the most famous vehicle of that game (I dont like it :D)
All i need to do is upload the created OBJ file to an obj-fbx converter because 3ds max doesnt like to read obj files that contain only vertices.

 

10 hours ago, h3x3r said:

It's voxel if it's matter..

Well the world is rendererd with a Voxel engine, but does that mean the 3D models of vehicles are also stored as "voxel data"?

There are some vertices that dont seem to fit into the model, maybe its some kind of LOD that is imported aswell, but a nice early success:
€DIT: I found a sphere consisting of hundreds of vertices in the model center and some other junk.

Edited November 5 by Einheit-101

[Einheit-101]

I further analyzed UTB and i have no clue where the actual model ends. Currently i am around line 339 and i think this is where the end is, after this line i could no longer identify any meaningful vertices. However everything between 0-339 is still filled with garbage among the good vertices, mostly values that could be vectors.
This is not really bad since it only creates a sphere of vertices around the center of the model, which can easily be deleted after import.
I dont understand how that can be read by the game because the order makes no sense, sometimes its 4 vertices in a row but sometimes its also 4 vectors in a row:
 

[shak-otay]

7 hours ago, Einheit-101 said:

(I guess your "12" is found by experience?)

Yep.

Quote

and a count of 921 will deliver -99999999 as last result, which is a clear sign that 920 is the end for that model, am i right?

Checked TH2 and UTB+ only, but yes, sounds good. You can check the created test.obj file to get a better overview.

Btw, what you named "Garbage" in your latest picture is "normals". As the size of a vertex block (aka FVF size) is defined by the distance from one valid vertex to the next one we've a "floating" FVF here. That's weird.

That "sphere of vertices" is the normals.  The radius of that sphere is 1, you can get it by adding the square values of the x, y and z component of the normals. (You need to take root of the result but since root of 1 is one you can skip that step.)

 

Edited November 6 by shak-otay

[Einheit-101]

Yes I also expected normal vectors because what else. Did you find any entry that tells the game the number of vertices? Surely somehow the game needs to know that UTB only has 182 vertices (the amount that i found) embedded into these normal vectors? 

[shak-otay]

Nope, didn't find the vertex count so far. Searching for 42 00 xx xx xx xx xx xx 42 00 after the vertex start address will lead you near to the stop address of the vertex block. (Works for TH2 and UTB+)

[Einheit-101]

UTB has exactly 194 vertices. The last vertex is byte / count 368, followed by 4 normal vectors. Bytes 373 onwards are "trash" vertices with unknown purpose; i can only imagine it may be some kind of LOD model following there because these vertices beyond byte 372 are SUSPICIOUSLY close to the actual model. The only useful location where i could find "194" was at address 01E6 pretty much at the start of the file but that is just a coincidence.

I was successfully able to restore UTB by manually connecting faces, it took 2 hours. Finding the correct vertex count and connecting all faces is a pretty tough job for all 20 vehicles, but doable.

€DIT:: UTB+ has a count of 481. The last vertex is at count 478 (Hex address 6920 - 692C) with 3 normal vectors following. Still have not found any clue where that info is stored.

Edited November 15 by Einheit-101
Found UTB+ vertex count

[h3x3r]

I believe that the most accurate vertex count can be found at 0x2c offset.

Edited November 15 by h3x3r

[shak-otay]

2 hours ago, h3x3r said:

I believe that the most accurate vertex count can be found at 0x2c offset.

maybe, but... for UTB+ (0x2C: 971 dec.) I found this block giving a decent point cloud:

0x52c4 vCount 485, FVF size of 24

when doubling the count to 970 I would have to use an FVF size of 12 which results in v vn v vn etc.

For TH2 126 would fit (since the FVF size is 12 there) for v block at 0xCE6.

 

[Einheit-101]

I found something. Address 0056 gives a scary accurate result for the "count" to be used in hex2obj. 

I used count 368 for the last UTB vertex, the file says 367.

I used count 478 for UTB+, the file says 476.

I used count 369 for UTH, the file says 363. (didnt upload UTH yet).

I don't know why it's not accurate or where the deviation comes from, but i guess i need to check some more files. 

€DIT: I just checked UTD and address 0056 says 370, while the real count is at least 411... So it must have been a coincidence.

https://www.dropbox.com/scl/fi/gwncahw6gk8pfrbg189rb/UTD?rlkey=ofwwrgpi1coort2fg6vz2oyou&dl=0

Edited November 17 by Einheit-101

[Einheit-101]

I guess we can mark this as solved. There is still a lot unknown, but i managed to manually rebuild 12 models in just 4 days now which means 6 days to go until i rebuilt the whole game. I wrote down the correct vertex count for every model that i find in this process, so even that information is no longer relevant. 

What i did find out in the mean time is that vertex blocks after the regular vertices are not trash or LODs (the game has no LODs), they are literally points exactly between 2 vertices, basically the center of the edge connecting them. This is why it's very easy to find the correct vertex amount. It's very obvious and easy to detect these edge centers on models with such a low vertex count: just select 3 suspicious vertices and if one of them is exactly at the average center of all 3, delete it. You do that as long as possible until you come across the first vertex that is obviously part of the model. It helps a lot that vehicles in this game all have roughly the same vertex count, between at least 145 and up to 252.

I used these settings in hex2obj:

Step 1 start address 0x48, set PtCld, click "go1"

Step 2 FVF size 12, click "go2"

Step 3 enter start address found at 0x1C and enter a nice number for "count", the largest count i found yet is 481, click "go3" and then click "mesh" to get the point cloud as obj file. Upload this obj file to an online obj - fbx converter, because 3ds max does not import obj files that contain only a point cloud. Done. 

€DIT: Adding 12 decimal to the start address is not required because these 12 bytes basically just generate a vertex at position 0, 0, 0 that can be deleted together with all other garbage vertices that are sitting around the center of the model.

Edited November 21 by Einheit-101