Finding models inside EEMemory.bin files?

[shakotay2]

here you go:
WA3_3ds_as_obj.zip
It's 1, 2 and 5.3ds as obj. Will provide the rest as soon as you confirm that they are as you expected them to be.

For 5.3ds I had to cut the face indices from 1758 to 10961 since the vertices built a flat useless mesh.
So the uv map is not complete.

(Guess the errorness 5.3ds is caused by the bms script. Don't know the reason - maybe a submesh problem.)
Leaving the face indices uncut is no solution.

[SmashFan127]

here you go:
WA3_3ds_as_obj.zip
It's 1, 2 and 5.3ds as obj. Will provide the rest as soon as you confirm that they are as you expected them to be.

For 5.3ds I had to cut the face indices from 1758 to 10961 since the vertices built a flat useless mesh.
So the uv map is not complete.

(Guess the errorness 5.3ds is caused by the bms script. Don't know the reason - maybe a submesh problem.)
Leaving the face indices uncut is no solution.

Yes, they are what I expected them to be.

The problem in separating meshes by loose parts is that the main body other than the head is in a single mesh when it is not supposed to be. This could make things more difficult when reorganizing different parts of the model.

[shakotay2]

So here's the rest:
WA3_Part2_3ds_as_obj.zip

(Face winding is reverse to the one of the 3ds models.)

Model 8's mesh is a complete mess. The vertices are near 0.0 0.0 0.0 and some texture coords are out of bounds/wrong.

[SmashFan127]

So here's the rest:
WA3_Part2_3ds_as_obj.zip

(Face winding is reverse to the one of the 3ds models.)

Model 8's mesh is a complete mess. The vertices are near 0.0 0.0 0.0 and some texture coords are out of bounds/wrong.

Thanks!

I have been wanting to find a way to fix the mesh in model 7. Do you have any tips to make it easier?

[shakotay2]

Model 7 looks o.k. to me. You mean model 8?

Well, you'd to go through the bms script inserting print commands as a debug help.
for example:
print "nuv: %nuv%"
For cvb = 1 To nuv ;
print "nuv-addr: %werefox%"
GoTo werefox 0 ;
(nuv is number of vertices, but not max vertex count)

As you know the structure of the basic data blocks is rather simple:

4ByteNumberofVertexes ORunknown
00 40 1E 31
12 04 00 00
4ByteFloatingPointWeight
{3x 4ByteFloatingPointVertexes(X,Y,Z), 4ByteFloatingPointWeight, 3x 4ByteFloatingPointNormalMappings(X,Y,Z),
4ByteFloatingPointWeight, 2x 4ByteFloatingPointTextureUVCoords(U,V), 4ByteFloatPointWeight, 4ByteUnknownInteger}

where the first 12 bytes are some kind of header (the 00 40 1E 31... sequence is used by the bms script to find the blocks) and the following 48 bytes block is present nuv times (nuv=3..21 for the first mesh).

You might use the addresses of your debug output to look into the eeMemory.bin file to understand what goes wrong with model 8 (and 5).

This tends to be a little bit time consuming (while finding how to get the uvs was not).
Since the models are not of vast interest for me I don't think I'll dig deeper into this.

btw: to get all the debug output you'll have to enlarge the command window or redirect the output into a file like this:
quickbms WildArms3\WildArms3eememoryto3ds.BMS WildArms3\eeMemory.bin > logme.txt

(Be sure to delete the 3ds files before a second run otherwise you'll find this "batch session" blocked.)

[SmashFan127]

Model 7 looks o.k. to me. You mean model 8?

Well, you'd to go through the bms script inserting print commands as a debug help.
for example:
print "nuv: %nuv%"
For cvb = 1 To nuv ;
print "nuv-addr: %werefox%"
GoTo werefox 0 ;
(nuv is number of vertices, but not max vertex count)

As you know the structure of the basic data blocks is rather simple:

4ByteNumberofVertexes ORunknown
00 40 1E 31
12 04 00 00
4ByteFloatingPointWeight
{3x 4ByteFloatingPointVertexes(X,Y,Z), 4ByteFloatingPointWeight, 3x 4ByteFloatingPointNormalMappings(X,Y,Z),
4ByteFloatingPointWeight, 2x 4ByteFloatingPointTextureUVCoords(U,V), 4ByteFloatPointWeight, 4ByteUnknownInteger}

where the first 12 bytes are some kind of header (the 00 40 1E 31... sequence is used by the bms script to find the blocks) and the following 48 bytes block is present nuv times (nuv=3..21 for the first mesh).

You might use the addresses of your debug output to look into the eeMemory.bin file to understand what goes wrong with model 8 (and 5).

This tends to be a little bit time consuming (while finding how to get the uvs was not).
Since the models are not of vast interest for me I don't think I'll dig deeper into this.

btw: to get all the debug output you'll have to enlarge the command window or redirect the output into a file like this:
quickbms WildArms3\WildArms3eememoryto3ds.BMS WildArms3\eeMemory.bin > logme.txt

(Be sure to delete the 3ds files before a second run otherwise you'll find this "batch session" blocked.)

Actually, I meant removing the double vertices and separating by loose parts in Blender separates the head and weapon, but the main body is still a mess in a single piece. I was hoping if it were possible to make the task a lot easier. Thanks anyway.

EDIT:



Here, after, using applying textures that I ripped, I removed double vertices in Edit Mode, then proceeded to separate the objects by loose parts. However, the main body without the head and weapon is a mess. I dunno if this has something to do with the way the script extracted the model. Is there anywhere to fix it to resemble how it appears in-game?

[shakotay2]

[...]I dunno if this has something to do with the way the script extracted the model.

It obviously has since the script doesn't care for submeshes.

You could try to insert "g lines" into the objs I provided to create submeshes
such as
g sm0
f 1/1 2/2 3/3
...
f 998/998 999/999 1000/1000
g sm2
...
f 1997/1997 1998/1998 1999/1999
g sm3
...

These were just for a quick test You'll have to find the correct positions of the lines by trial'n error.

Importing the 3_3ds_as_obj.obj into blender with the group button selected shows this:

3ds_as_obj_groups.JPG

[SmashFan127]

[...]I dunno if this has something to do with the way the script extracted the model.

It obviously has since the script doesn't care for submeshes.

You could try to insert "g lines" into the objs I provided to create submeshes
such as
g sm0
f 1/1 2/2 3/3
...
f 998/998 999/999 1000/1000
g sm2
...
f 1997/1997 1998/1998 1999/1999
g sm3
...

These were just for a quick test You'll have to find the correct positions of the lines by trial'n error.

Importing the 3_3ds_as_obj.obj into blender with the group button selected shows this:

3ds_as_obj_groups.JPG

I see... and what about fixing the mesh to make it closely resemble its in-game appearance instead of a pile of ruined mesh?

[shakotay2]

I don't owe the game so I don't know how the meshes look like ingame.
All I got is a script that extracts them as 3ds from the EEMemory.bin file without UVs.

I cared for the UVs but now I'm sorry - all I can do is to quote myself:

Since the models are not of vast interest for me I don't think I'll dig deeper into this.

[SILENTpavel]

nice thread!
I was interested with textures extraction from "Plugin GS.dat" and "eeMemory.bin" of pcsx2 unpacked saveState files, here is some help:
http://forums.pcsx2.net/Thread-PCSX2-ss ... ure-viewer

[SmashFan127]

nice thread!
I was interested with textures extraction from "Plugin GS.dat" and "eeMemory.bin" of pcsx2 unpacked saveState files, here is some help:
http://forums.pcsx2.net/Thread-PCSX2-ss ... ure-viewer

I can certainly agree that textures are an important thing to a model. However, I am not good at finding textures inside the savestate. My biggest concern right now is trying to fix the mesh to resemble how it looks in-game while having proper UVs to fit onto the textures I have. Thanks for letting me know about the textures, though.

EDIT:

Is there anyway that the models inside eeMemory.bin can be extracted and not put in a mess while keeping the UV coordinates?