Author Topic: [PSX/PC] .MAP -> .OBJ Converter - ff7MapToObj (Missing Download)  (Read 23918 times)

Omzy

  • *
  • Posts: 205
    • View Profile
ff7MapToObj

Note: This program uses info from Ficedula's World Map Viewer (Reeve): http://forums.qhimm.com/index.php?topic=6057.0

I wrote this little program so that I could render a heightmap of the ff7 world map.

Seeing as how this is my first c++ release ever, don't expect it to be fast or efficient. In fact, since it makes external calls to LZSCDec.exe (because I didn't write my own decompressor), expect it to run slow. Also, I don't guarantee that it works on all OS's due to variability of int sizes, but it probably does.

Instructions (sorry if its not as easy as plug and play, but it is not legal to bundle the textures):
1) Extract the .rar from: http://www.mediafire.com/?c76sb586q66ee0q into your data/wm directory:
2) Use Biturn: http://mirex.mypage.sk/FILES/bi087b4.rar to extract the textures from data/wm/world_us.lgp. You MUST extract ALL textures as .TGA files AND place them in a new folder: data/wm/textures. You can select multiple textures at once and extract all at once. No need to do it one by one.

The program will read wm0.map, wm2.map, and wm3.map and output wm0.obj, wm2.obj, and wm3.obj. It uses NFITC1's LZS decompressor.

Notes: The textures for wm0 are 90% accurate, but should be exactly the same as Reeve's due to some unknown data (read thread). The textures for wm2 and wm3 are mapped differently, so are totally incorrect. There is one small hole in the wm2.map (underwater) mesh that I am pretty sure was part of the original game and not caused by me. The .obj files are rather large (wm0.obj is 20mb) so expect it to act up unless you've got a good 3d program and adequate system memory.

Downloads:
ff7MapToObj: http://www.mediafire.com/?c76sb586q66ee0q
Biturn (required): http://mirex.mypage.sk/FILES/bi087b4.rar
NFITC1's LZS decompressor (required, bundled with permission): http://www.mediafire.com/?hwyyk2zjjjj

See my Fallout 3 WIPs at the MDMD forums: http://z9.invisionfree.com/industrialpolygons/index.php?showtopic=562

Screenshots (click to enlarge):
World Map (wm0) textured mesh

World Map (wm0) mesh

Underwater Map (wm2) mesh -- Note that if you superimpose it in the central ocean of wm0, it drops in nicely.
There is a deep chasm that follows the path from Junon to Costa del Sol
and there is a channel that goes through the western continent to Lucrecia's cave.

Snow Map (wm3) mesh


Source (Visual C++ 2010):
Code: [Select]
/*
ff7MapToObj
by Omzy ([email protected]) 09/05/2010
        [REL] thread at: http://forums.qhimm.com/index.php?topic=10717.0
See my WIP at the MDMD forums: http://z9.invisionfree.com/industrialpolygons/index.php?showtopic=562

Description: Converts a final fantasy 7 .map file to an .obj file that can be opened in various 3d rendering programs.

Requires: lzscdec.exe (by NFITC1) and .map files (wm0, wm2, wm3 from data/wm) must be in same directory.
Download lzscdec.exe from http://www.mediafire.com/?hwyyk2zjjjj
        Requires: textures directory with .tga's from world_us.lgp in data/wm.

For documentation on .map format, see http://wiki.qhimm.com/FF7/WorldMap_Module
For documentation on .lsz compression, see http://wiki.qhimm.com/FF7/LZS_format
*/

#include <iostream>
#include <fstream>
#include <stdlib.h>
#include <string>
using namespace std;

string getMtl (short mtlIndex) //mtlIndex is 9 bit value that represents texture id
{
//mtlcodes.txt and mtlnames.txt are in separate files to make texture swapping easier
char * mtlCode = new char[2]; //mtlcode is 2 alpha characters
ifstream mtlcodefile ("mtlcodes.txt", ios::in); //Codes match material names in mtlnames.txt
if (mtlcodefile.is_open())
{
int count(0); //This loop gets the code at line mtlIndex
mtlcodefile.seekg(0, ios::beg);
while (!mtlcodefile.eof() && mtlcodefile.good() && count < mtlIndex)
{
mtlcodefile.get(mtlCode, 3);
mtlcodefile.ignore(100, '\n');
count++;
}
}
else cout << "Unable to open" << "mtlcodes.txt" << endl;
mtlcodefile.close();

char * curCode = new char[2]; //Current code in file
string mtlName = "";
ifstream mtlnamefile ("mtlnames.txt", ios::in); //Names match material codes in mtlcodes.txt
if (mtlnamefile.is_open())
{
mtlnamefile.seekg(0, ios::beg); //This loop gets the name at the line starting with mtlCode
while (!mtlnamefile.eof() && mtlnamefile.good())
{
mtlnamefile.get(curCode, 3);
if (mtlCode[0] == curCode[0] && mtlCode[1] == curCode[1])
{
mtlnamefile.seekg(0x0001, ios::cur); //Skip '=' in file
char * temp = new char[1];
while (*temp != '\0')
{
mtlnamefile.get(temp, 2);
mtlName.append(temp);
}
break;
}
else
{
mtlnamefile.ignore(100, '\n');
}
}
}
else cout << "Unable to open" << "mtlnames.txt" << endl;
mtlnamefile.close();

//cout << mtlIndex << " " << mtlCode << " " << mtlName << endl;

return mtlName;
}

char * getTexDims (string mtlName)
{
char * texDim = new char[4];
//Open .tga file to check dimensions given mtlName

ifstream mtltexfile ("textures\\" + mtlName + ".tga", ios::in);
if (mtltexfile.is_open())
{
mtltexfile.seekg(0x000C, ios::beg);
mtltexfile.read(texDim, 0x0004);
}
else
{
cout << "Unable to open " << mtlName << ".tga" << endl;
}
mtltexfile.close();

return texDim;
}

void mapToObj (string filename, int numblocks, int dimension)
{
ifstream mapfile (filename + ".map", ios::in|ios::binary); //Input file
ofstream objfile (filename + ".obj", ios::out); //Output file

int totalVertices = 0;
int totalVTs = 0;

if (mapfile.is_open() && objfile.is_open())
{
objfile << "mtllib tgalib.mtl" << endl;

int * meshloc = new int;
int * lzssize = new int;

for (int i = 0; i < numblocks; i++) //There are 69 Blocks in wm0.map, ignores last 6 blocks (see below)
{
//Calculate north-south block (nsblock) and east-west (ewblock) offsets of block (7x9 grid of blocks = 63)
//Block size is 8192*4 = 32768x32768 coordinate units
//Note that blocks 63, 64, 65, 66, 67 and 68 replace blocks 50, 41, 42, 60, 47 and 48 (respectively), according to the story of the game.
int ewblock = i % dimension;  //take mod to get 0-8
int nsblock = floor ((float)(i / dimension)); //take floor to get 0-6

//cout << i << " " << ewblock << " " << nsblock << endl;

for (int j = 0; j < 16; j++) //There are 16 meshes in each block
{
//Calculate north-south (ns) and east-west (ew) offsets of mesh (4x4 grid of meshes = 16)
//Mesh size is 8192x8192 coordinate units
int ew = j % 4;  //take mod to get 0-3
int ns = floor ((float)(j / 4)); //take floor to get 0-3

int pos = i * 0xB800 + j * 0x0004;

mapfile.seekg (pos, ios::beg); //Block i, Mesh j
mapfile.read ((char *) meshloc, 0x0004); //Read location of mesh (pointer is 4 bytes)

pos = i * 0xB800 + *meshloc;
mapfile.seekg (pos, ios::beg); //Mesh LZS starts here
mapfile.read ((char *) lzssize, 0x0004); //Size is 1st 4 bytes
mapfile.seekg (-0x0004, ios::cur); //Go back 4 bytes because .lzs file includes size
char * memblock = new char [*lzssize + 0x0004];
mapfile.read (memblock, *lzssize + 0x0004); //Read the compressed mesh to memory (don't forget to read the size header)

ofstream lzsfile ("mesh.lzs", ios::out|ios::binary); //Write compressed mesh to mesh.lzs file
if (lzsfile.is_open())
{
lzsfile.write (memblock, *lzssize + 0x0004);
}
lzsfile.close();

//system("lzs.exe -d -q mesh.lzs"); //Decompress mesh with Ficedula's LZS decompressor
system("lzscdec.exe mesh.lzs D mesh.dec"); //Decompress mesh with NFITC1's LZS decompressor
remove ("mesh.lzs");

fstream::pos_type meshsize; //Copy data from mesh.dec to memory
ifstream meshfile ("mesh.dec", ios::in|ios::binary|ios::ate);
if (meshfile.is_open())
{
meshsize = meshfile.tellg();
delete[] memblock;
memblock = new char [meshsize];
meshfile.seekg (0, ios::beg);
meshfile.read (memblock, meshsize); //Read size header? Just need #triangles  & #vertices
}
meshfile.close();
remove ("mesh.dec");

//Here we add the mesh in memblock to the .obj file
//May need to add offsets for block # because map is 9x7 grid of 63 blocks.
unsigned char * mem_ptr;
unsigned short numTriangles, numVertices;
mem_ptr = (unsigned char *)(memblock);
numTriangles = *mem_ptr;
numTriangles += *(mem_ptr + 0x0001) << 8;
mem_ptr = (unsigned char *)(memblock + 0x0002);
numVertices = *mem_ptr;
numVertices += *(mem_ptr + 0x0001) << 8;

//cout << numTriangles << " " << numVertices << endl;

for (int f = 0; f < numTriangles; f++) //Triangle (face) data. Each triangle consists of 12 bytes. The first 3 are vertex indices.
{
pos = (int) (memblock + 0x0004 + 0x000C * f);
mem_ptr = (unsigned char *)(pos);
unsigned char v0 = *mem_ptr;
mem_ptr += 0x0001;
unsigned char v1 = *mem_ptr;
mem_ptr += 0x0001;
unsigned char v2 = *mem_ptr;
mem_ptr += 0x0002;
unsigned char u0 = *mem_ptr;
mem_ptr += 0x0001;
unsigned char vt0 = *mem_ptr;
mem_ptr += 0x0001;
unsigned char u1 = *mem_ptr;
mem_ptr += 0x0001;
unsigned char vt1 = *mem_ptr;
mem_ptr += 0x0001;
unsigned char u2 = *mem_ptr;
mem_ptr += 0x0001;
unsigned char vt2 = *mem_ptr;
mem_ptr += 0x0001;
unsigned short mtlIndex = *mem_ptr; //Texture is 2 bytes read lower then upper, but only lower 9 bits
mtlIndex += *(mem_ptr + 0x0001) << 8; //For that reason we throw out the top 7 bits

//Debug
//char upper7 = mtlIndex >> 9; //Upper 7 bits (unknown)
//Debug

mtlIndex = mtlIndex << 7;
mtlIndex = mtlIndex >> 7;
mtlIndex++;

//cout << getMtl (mtlIndex) << endl; //Material name
string mtlName = getMtl(mtlIndex);
objfile << "usemtl " << mtlName << endl; //Use texture from tgalib.mtl
objfile << "f " << (int) v0 + totalVertices + 1 << "/" << totalVTs + 1 << "/" << (int) v0 + totalVertices + 1 << " "; //face line format:
objfile << (int) v1 + totalVertices + 1 << "/" << totalVTs + 2 << "/" << (int) v1 + totalVertices + 1 << " "; //f v1/vt1/vn1 v2/vt2/vn2 v3/vt3/vn3
objfile << (int) v2 + totalVertices + 1 << "/" << totalVTs + 3 << "/" << (int) v2 + totalVertices + 1 << endl; //Vertex and Vertex/Normal values are same

//Easier to write the UVs here since they are considered part of a triangle (face) in the .map file. Obj file doesn't care where they are, just their order
//Get texture dimensions given mtlName
char * texDim = new char[4];
texDim = getTexDims (mtlName);
short texWidth = (texDim[1] << 8) + texDim[0];
if (texWidth < 0) texWidth *= -1;
short texHeight = (texDim[3] << 8) + texDim[2];
if (texHeight < 0) texHeight *= -1;
//cout << texWidth << " " << texHeight << endl;

objfile << "vt " << (float)((float) u0 / texWidth) << " " << (float)((float) vt0 * -1 / texHeight) << endl; //Note that V's are flipped
objfile << "vt " << (float)((float) u1 / texWidth) << " " << (float)((float) vt1 * -1 / texHeight) << endl; //All UVs must be divided by texheight/width for normalization
objfile << "vt " << (float)((float) u2 / texWidth) << " " << (float)((float) vt2 * -1 / texHeight) << endl;

totalVTs += 3;
}

for (int v = 0; v < numVertices; v++) //Vertex data. Each vertex consists of 8 bytes. The first 6 are coordinates (2 each).
{
pos = (int) (memblock + 0x0004 + 0x000C * numTriangles + 0x0008 * v);
mem_ptr = (unsigned char *)(pos);
short x = *mem_ptr;
x += *(mem_ptr + 0x0001) << 8;
mem_ptr += 0x0002;
short y = *mem_ptr;
y += *(mem_ptr + 0x0001) << 8;
mem_ptr += 0x0002;
short z = *mem_ptr;
z += *(mem_ptr + 0x0001) << 8;
objfile << "v " << (int) x  + ewblock * 32768 + ew * 8192 << " " << (int) y << " " << (int) z + nsblock * 32768 + ns * 8192 << endl;
}

for (int vn = 0; vn < numVertices; vn++) //Vertex/Normal data. Each vertex/normal consists of 8 bytes. The first 6 are coordinates (2 each).
{
pos = (int) (memblock + 0x0004 + 0x000C * numTriangles + 0x0008 * numVertices + 0x0008 * vn);
mem_ptr = (unsigned char *)(pos);
short x = *mem_ptr;
x += *(mem_ptr + 0x0001) << 8;
mem_ptr += 0x0002;
short y = *mem_ptr;
y += *(mem_ptr + 0x0001) << 8;
mem_ptr += 0x0002;
short z = *mem_ptr;
z += *(mem_ptr + 0x0001) << 8;
objfile << "vn " << (int) x  + ewblock * 32768 + ew * 8192 << " " << (int) y << " " << (int) z + nsblock * 32768 + ns * 8192 << endl;
}

totalVertices += numVertices;

//Mesh added to .obj file.
delete[] memblock;

//Report progress
system("cls");
cout << "ff7MapToObj by Omzy" << endl << endl;
cout << "Converting " << filename << ".map..." << endl;
cout << "Progress: Block: " << i + 1 << "/" << numblocks << " Mesh: " << j + 1 << "/16" << endl;
}
}
delete[] meshloc;
delete[] lzssize;
}
else cout << "Unable to open" << filename << ".map" << endl;

mapfile.close();
objfile.close();

return;
}

int main () {

mapToObj ("wm0", 63, 9);
mapToObj ("wm2", 12, 3);
mapToObj ("wm3", 4, 2);

system("Pause");
return 0;
}
« Last Edit: 2018-04-24 18:35:17 by Covarr »

ItchyPanda

  • *
  • Posts: 22
    • View Profile
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #1 on: 2010-09-03 06:44:09 »
Awesome, not that I have worked with World Map yet...
But it should be pretty useful  :)

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #2 on: 2010-09-03 11:18:08 »
That's neat!

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #3 on: 2010-09-03 23:04:30 »
I'm going to try to extend this program by adding textures to the object using some of Ficedula's work. (see top)

pyrozen

  • *
  • Posts: 791
  • Team Avalanche Member
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #4 on: 2010-09-03 23:29:28 »
omzy, i praise your work! we have needed an easy to use app like this for a very long time, and im glad  that you were able to deliver!

lee

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #5 on: 2010-09-04 00:09:11 »
Thanks guys, support keeps the fire burnin'   ;D

Does anyone have an LZS decompression algorithm that I can simply "drop in" and call as a function? Needs to be a standalone c++ function using only standard libraries. Only decompression is needed, not compression. This would make the program literally 10-100x faster since I wouldn't have to make system calls.

I'll give you credit and won't post your source if you don't want it public :wink:
« Last Edit: 2010-09-04 00:39:25 by Omzy »

pyrozen

  • *
  • Posts: 791
  • Team Avalanche Member
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #6 on: 2010-09-04 02:15:06 »
now, i asked in your other thread if you would be able to recompile these files for use ingame again. Antoehr layer would be if you are able to reimport them, would changes be possible to be made to the land mass and the UVs of the original?

Sorry if these are out of the scope of the project at the moment, im just excited at the idea of finally being able to improve on the actual map itself.

lee

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #7 on: 2010-09-04 02:41:27 »
now, i asked in your other thread if you would be able to recompile these files for use ingame again. Antoehr layer would be if you are able to reimport them, would changes be possible to be made to the land mass and the UVs of the original?

Sorry if these are out of the scope of the project at the moment, im just excited at the idea of finally being able to improve on the actual map itself.

lee
Well, lets start with what we do know.

Textures) I'm pretty sure you can replace .tex files in world_us.lgp and you will see the corresponding textures change on the map in game.

Mesh) The .obj file I am outputting is missing some data from the original .map file. For some of this data, no one knows what it is, like the upper 7 bits of the 2 bytes that specify the texture. For that reason, Ficedula's viewer can't properly view 10% of the textures. There are another couple bytes following the vertex and normals data that are unknown. So, if you tried to take my code and reverse it, you would lose that unknown data and the game will obviously crash because your .map format won't be correct.

If you fill those values in with 0's, the game will either crash or (if lucky) it will put something out that looks like Ficedula's. On the other hand, if you wrote that data into the .obj file as comments and read it back when converting back to .map, it just might work flawlessly.

I am not planning on doing all that, but my .obj's will be pretty close to having all the data. Since my code is public, anyone can add that functionality (maybe you!). So, yes, in theory it is possible unless the game kernel has checksums for map meshes, which I doubt.

I'm actually doing this additional stuff because I found a tool that can add a texture map to Fallout 3. If I already have a relative map of textures (beaches, mountains, etc) I can just change the textures to corresponding Fallout 3 textures and blammo. Maybe...lol.
« Last Edit: 2010-09-04 02:44:39 by Omzy »

pyrozen

  • *
  • Posts: 791
  • Team Avalanche Member
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #8 on: 2010-09-04 02:46:46 »
as far as replacing textures on the world map, it works exactly like you say it does. I replaced nearly then entire world map with help from grimmy ONE texture at a time... extremely tedious work to say the least. The reason i ask is because the towns are a part of the map and ATM we cannot do much to improve them other than simple retextures which don't look that great because the UVs are crap.

Anyway, i appluad your work on this program, even a better version of Reeve would be a welcome addition.

lee

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #9 on: 2010-09-04 02:55:17 »
You could probably just alter extracted data in the memory block and then rewrite the data back to the .map file instead of writing it to the .obj file. If you do that and then check in-game to see if any changes occurred, you would know if it is possible or not.

Aali

  • *
  • Posts: 1196
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #10 on: 2010-09-04 08:43:07 »
Whenever I have time (which at this point looks like it might just be never) I will look into the .map format and find out what those unknowns mean, if they mean anything. I might then also write an importer/exporter, I would love to see some more WM modding.

sl1982

  • Administrator
  • *
  • Posts: 3762
  • GUI Master :P
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #11 on: 2010-09-04 14:43:09 »
Modding the world map without all the problems with tiling would be great. Awesome job Ozmy, keep it up.

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #12 on: 2010-09-04 20:22:54 »
Modding the world map without all the problems with tiling would be great. Awesome job Ozmy, keep it up.

Could you elaborate on the tiling issue? Are you talking about the Reeve program's problem with 10% of the textures or something else? When I used the direct UV values I observed that each face had the correct texture, but it tiled over the face like 100x smaller than the correct texture size.

sl1982

  • Administrator
  • *
  • Posts: 3762
  • GUI Master :P
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #13 on: 2010-09-05 00:55:40 »
I was referring to putting textures back into the game, there is a noticable tiling effect that had to be overcome by reducing the complexity of the textures. Hopefully this program can be elaborated on so we can re UV and texture the world map as we see fit. Maybe in the future perhaps.

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #14 on: 2010-09-05 02:58:54 »
I have spent a lot of today trying to understand whats going on with the UV coordinates. I noticed that dividing the coordinates by 32, 64, or 128 made certain groups of textures appear correctly. I believe this depends on the original texture size. For example, if the texture was 64 pixels wide and 32 pixels tall, dividing U by 64 and dividing V by 32 makes the texture appear correctly. If you don't do this division properly, some will be tiled and others will be correct. This is a bit of a problem since the texture sizes vary. I was wondering if the top 7 bits of the texture field somehow coded for this, but I have not been able to establish a relationship.

Update: Sorry, I pulled a stupid. The .obj format requires vertex/texture values to be floats from 0.0 to 1.0  :-[

I can at least verify that the 7 bits do not code for the texture size because several textures with different sizes have the same value. I'm thinking they code for whether or not there are other textures that cover a certain face. Like water has a different 7 bit value than all of the snowy mountainous areas and the only difference I see is that water has several textures that rotate.

Update: I've managed to get it looking exactly like Ficedula's, with the exact same textures broken. It is just a problem with the file fice used to assign textures to areas. There's a bunch of ?? marks in that file that apparently indicate that he wasn't able to find a matching texture for a particular area. If those can just be assigned properly, the map is perfect.

My current theory is that the upper 7 bits tell the game how to interpret multi-part texture files. Some texture files have multiple textured rectangles within them. So far, almost every messed up texture is one of these. The 7 bits might code for the texture layout and perhaps which rectangle to choose from the texture. Probably totally wrong.
« Last Edit: 2010-09-05 07:21:37 by Omzy »

sl1982

  • Administrator
  • *
  • Posts: 3762
  • GUI Master :P
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #15 on: 2010-09-05 15:01:41 »
Perhaps they have to do with the animated textures?

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [WIP] Omzy's .MAP -> .OBJ Converter
« Reply #16 on: 2010-09-06 00:20:20 »
Perhaps they have to do with the animated textures?
Well, after spending the entire day trying to figure it out, I can say that if it does have info for animation, it is definitely used for more than that. This is because even for textured areas where there is absolutely no animation (like mountain tops) there are different values for the same texture. I noticed that the multi-textures I mentioned before always have many different values, suggesting that it does have something to do with which part of a texture is chosen. It just so happens that most of those multi-textures are the ones that don't show up properly. My guess is that it has animation and sub-texture info encoded using flags (0 or 1), but I am not going to spend more time trying to figure it out.

So, without further ado, I will post the new release which includes textures and normals. You may need to invert the normals in your 3d program because I didn't spend time writing the algorithm for that, but its no big deal. See first post.
« Last Edit: 2010-09-06 01:51:19 by Omzy »

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #17 on: 2010-09-06 08:58:01 »
Can you post a map of the sea floor. I always wanted to contrast that with the landmass.
I'm pretty sure the snowfield map  is one huge white map with a hut :)

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #18 on: 2010-09-06 17:09:31 »
Sure, I'll turn off the texture mapping for those 2 (they use an unknown mapping scheme) and post images. Ok, they are posted--see above.
« Last Edit: 2010-09-06 18:03:12 by Omzy »

obesebear

  • Administrator
  • *
  • Posts: 1383
    • View Profile
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #19 on: 2010-09-06 18:29:35 »
The snow map is my favorite

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #20 on: 2010-09-18 17:38:31 »
Sure, I'll turn off the texture mapping for those 2 (they use an unknown mapping scheme) and post images. Ok, they are posted--see above.

Do you still need the LZS decompression code? I believe I still have this floating in my old code from examining FF7 somewhere. I believe it should be generic enough for your purposes. You might be able to use Q-gears code also. I'll have to check as I fell off the turnip truck on it a while ago. doesn't appear to have it.

Cyb

Omzy

  • *
  • Posts: 205
    • View Profile
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #21 on: 2010-09-18 21:35:30 »
At this point my little project is finished and works well enough, so I think I'll leave it at that. Thanks for the offer, though!

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #22 on: 2010-09-18 23:57:53 »
At this point my little project is finished and works well enough, so I think I'll leave it at that. Thanks for the offer, though!
Heh you just think it's done ;) OK works for me, it would have taken me a bit of time as this stuff is over 6 years old.

Cyb

kaspar01

  • *
  • Posts: 118
  • FFVIII Fan & Collector , 3D Artist , FF8RP-WIP
    • View Profile
Re: [REL] Omzy's .MAP -> .OBJ Converter
« Reply #23 on: 2013-06-20 09:03:56 »
Sorry for necro-posting but... it's possible to see anything like this for ff8 map?

I'd really need it T_T

Omzy

  • *
  • Posts: 205
    • View Profile
This is a bit embarrassing, but I seem to have completely lost this project in my file stores somehow. A few people have asked me for a download link, so if anyone has the file on their desktop, I'd appreciate if you could upload it for us. If not, at least I had the foresight to post the code, so I or someone else can recompile it.  :roll: