.EMD (Evil Zone)

[BMarquis]

Hello.

I'm trying to find a way to view models from Evil Zone using Blender. I've stumbled upon EMD files which seemed to be the model files I need. some of the EMD files are small and easy to determine the file size by adding 0x18 to the short integer stored in 0x0A.

struct
{
char magic[4] // "EMD/20"
short version // assuming version number
short numobj // assuming the number of objects
short offset // where the data begins
short size // size of data
long unknown2[3]
}

This allows me to manually extract most if not all the hitsparks of the game. however not all EMD's follow this. I was wondering with the ones I do have, how can I determine the structure of the files? I'm using:

HxD for hex editing
PCSX-Trace to understand the ASM aspect of it
pSX for breakpoints.

Thanks in advance.

[mariokart64n]

post samples

[BMarquis]

http://www.bmarquis.com/misc/type1.emd
http://www.bmarquis.com/misc/type2.emd
http://www.bmarquis.com/misc/type3.emd
http://www.bmarquis.com/misc/type4.emd

Here you go.

Type 1 is the first emd file which was more than 5KB that follows the way I was referring to.
Type 2 is a small version of a different one. offset 06 is 0x1F vice 01 all EMD files either have one or the other. Also, I noticed that all files with 0x1f as offset 6 has an additional 240 bytes of information.
Type 3 is a somewhat longer version
Type 4 is an even longer version which does not even follow the 240 byte pattern that the other two does.

[FurryFan]

http://www.bmarquis.com/misc/type1.emd
http://www.bmarquis.com/misc/type2.emd
http://www.bmarquis.com/misc/type3.emd
http://www.bmarquis.com/misc/type4.emd

Here you go.

Type 1 is the first emd file which was more than 5KB that follows the way I was referring to.
Type 2 is a small version of a different one. offset 06 is 0x1F vice 01 all EMD files either have one or the other. Also, I noticed that all files with 0x1f as offset 6 has an additional 240 bytes of information.
Type 3 is a somewhat longer version
Type 4 is an even longer version which does not even follow the 240 byte pattern that the other two does.

Hello, I think I see where the vertexes, and texture maps are: They are stored in sections of 12byte arrays which are in turned stored in chunks. Each vertex coordinate is a 32bitsigned integer, and each texture coordinate is also a 32bitsigned integer. I can probably work something out tomorrow, but it would be easier to figure out the format if you could send me a Epsxe save state (a save state is two files one is about 1megabyte and the other is .pic which is about 30kilobytes, make one and select the right ones by saving a new one and then going to the folder and sorting by "data modified".

[FurryFan]

Heres what I found to be the format of the "Type4" emd:

#Vertexes ?? 01 00 (most of the groups of vertexes contain "4B" vertexes (75 in decimal):
32BitSigned Vertexes(X,Y,Z) and Normals/Goruad(X,Y,Z)
#Variable2 00 00 34
32BitSignedDataforVariable2(1,2,3,4,5) 00 00 (probably some type of texture information to put on each face)
#Variable3 01
12ByteDataforVariable3 (probably sometime of face list)

[BMarquis]

Sorry for the late reply.

Here's the savestate.

http://www.bmarquis.com/misc/SLUS_008.55.000
http://www.bmarquis.com/misc/SLUS_008.55.000.pic

[surix]

Great, im glad someones working on evil zone!

Type 2 is a small version of a different one. offset 06 is 0x1F vice 01 all EMD files either have one or the other. Also, I noticed that all files with 0x1f as offset 6 has an additional 240 bytes of information.

I noticed that extra info is because 31 * 8 is 248 and 1 * 8 is 8 so 240 is the difference.

struct
{
char magic[4] // "EMD/20"
short headersize// assuming the size of this header
short numobj // assuming the number of objects
short offset // where the data begins
short size // size of data
short unknown1 //always 8?
short unknown2 //always 8?
}

then comes an array of 8byte entries of length 'numobj'
long[numobj]

now we are at offset where the data begins

[FurryFan]

Thanks for the save state, this is making things much easier.
I worked on it a little bit today. The model for the blue character on the right begins at about the absolute (ie Epsxe.exe) memory address 0069D038 before this is the header EMD, now this mesh is made of about 30 different sections. But for some reason only 8 sections respond to editing and the other 22 or so you can fill up with anything. Maybe it has different body parts for each different costume. Here are the middle of each section:
0069D038 0069E1DC 0069FBCC 006A0BF0 006A1AE4 006A5094 006A8AAC 006AC120
If you change the byte at any of the addresses to 0 then that body part will not be displayed. Change it to 0hFF (255 decimal) then there will be major graphical glitches and lag but not enough to freeze the game.
I will do a lot more work on this later and post screenshots.

[FurryFan]

Here is a screenshot of me disabling the guy's body:

Here is a screenshot when I change the number to a section to a higher number that exists so that the game reads memory from one section like it is from a different section:

Here are names of the body parts for the section I posted above:
Body, Head, LeftLeg, RightLeg, LeftArm, LeftHand, RightArm, RightHand.

[BMarquis]

Actually, it does.

I just learned how to read the game's PAC File. It's basically a VFS (Squee of the newbie!) I've come to deduct that a character is made of at least 7 parts. some have more due to external afairs (Bendis and Meldis, Karin for Setsuna, etc.). I dumped a chunk of the PAC file with the directory of a character and see if I can reconstruct the model that way.

[BMarquis]

Read the official docs. This EMD file is similar to PMD, kinda like most EMD formats on the site.

I also believe the first short is actually the offset(including header) where objects began. There's always at the least one object, so the next variable always have to be at least one.

{
char magic[4] // "EMD/20"
short objofs// where object data begans
short numobj // assuming the number of objects
short vertofs // where the data begins
short size // size of data
short unknown1 //always 8?
short unknown2 //always 8?
}

Now, since the actual header structure is different in a since, I do not know if it follows the same concept as the other EMD/PMD files found on the site. My investigation continues by creating a viewer.

[BMarquis]

Upon messing around with the Hex Editor, I've noticed that every time unknown1 does not equal to unknown 2, there are 4 groups of data sized size. Although it doesn't explain exactly why, it does give light the reason Type4 is different than the other types. I can now create a EMD extractor for Evil Zone.