H
Halfer
Guest
First off, huge thanks to MakiPL for inspiring me and hopefully others with his research on ff8 battle fields. Since he's making a very good and much faster progress than i managed to make I decided to hop on to world map data. This concerns wmx.obj for now since I haven't looked on to the other files yet.
Remember that this info may be inaccurate in some parts since it is a huge file (33MB) and it is a pain in the neck to scroll through. However I'll talk about how to handle this file quicker at the end.
Insight:
For now (not sure), the world map seems to consist of 768 sections. Each section contains 16 blocks and each block can have different amount of triangles. Luckily, the sea mesh seems to have 32 triangles (formation told later) so we can do tests on that more easily. Here are pictures with 1 section/16 blocks and 1 block with 32 triangles:
Header:
Header consists of 68 bytes. Each section contains the same header structure.
- First 4 bytes are still unknown since changing these don't seem to do anything.
- Rest 64 bytes indicates the offset of blocks after the header
Data:
Possible render/collision options:
This is very complicated.
After the header, the first 4 bytes seems to remove the whole corresponding block when set to "00 00 00 00", also it creates a collision over it so it can't be fled over. Setting it something else messes with uv's as well as geometry and may cause the game to crash or freeze. Setting it to "30 30 30 30" also affects the next block for some reason. The collision is also changed and in this particular example you can go under the world (something like in ff7
).Triangle data:
The data for 1 triangle is 16 bytes long starting after possible render/collision options.
The next 4 bytes are for triangle vertices. zeroing these gives the following results for one triangle:
Here are the marked triangle vertices: And here's how they are formed:
Unknown still:
The next 8 bytes are still unknown, feel free to look at it!
Also the data between in-game blocks in a section is still unknown.
Ground type?
The last 4 bytes for one triangle data seems to contain UV data reference for the corresponding triangle. This is also how I made the example photos for this thread. Changing the value for this changes the triangles type. The marked bytes, when set to "88 88 88 88" gives the ground the type as in in-game example photos:
Also landing on this ground is possible, but as I tested I found out that you can reference to any type of ground with this and I managed to get probably a cliff type where I were unable to land with ragnarok.
Padding:
Following the data for one section comes a bunch of zeros. This is called padding. The data and padding are 36864 or 0x9000 bytes for every section.
How to manage the file:
Since this file is huge I found out a little solution for managing it. One reason for the size of this file is padding. The header, data and padding seems to be fixed amount of 36864 bytes or 0x9000 bytes for easier reading in hex editor. This helps a lot since each section is therefore 0x9000 bytes long (including padding) and for next section you just add 0x9000 bytes more from the beginning of previous section to get for next section.
How to know which section you are editing in game:
This is still TODO. However I think there is 768 sections, but i'm not sure if one section can be larger or smaller than I showcased. For what I know, the first section in the file is top left corner section in-game and the next sections goes horizontally to the top right corner of the in-game map. This way of thinking isn't true in the vertical way however:
If there was 768 sections in the world map and the aspect ratio would be 4:3 like the world map picture, it would mean that the sections would be 32x24. Here's a picture of first block from 12th section of file which possible render/collision options are nullified:
You can see that it is pretty accurately in place.
If we want 12th section vertically it would be (12x32=) 384th section in file, however it isn't correct so the 768 section hypothesis isn't correct.
Although it isn't correct we can use the first horizontal line and maybe the second one for testing purposes with this hypothesis.
Lastly:
I hope this helps someone with their research on this and someone manages to do something huge with this!
Also the very last section includes the model for great salt lake, its train station and little part of the bridge. Just remember if you replace the first section or any other section with this that there is 36864 or 0x9000 bytes in the section including padding.
Last edited:
