Map exploration...

[Satchmo III]

Hola hackticians!

I've been sifting through the gilded zeroes and ones of the game, like a machinist recreating forgotten and mysterious technologies of old. I'm trying to get more serious about taming some Python and made some appreciable progress over the last 10 days or so. If not for gomtuu's mapping of the map files I'd have no clue how to proceed so thanks again to him. I'm in no position to make a map viewer like he has but I'm enjoying slowly retracing his steps and learning more about the game and programming/computers along the way.

Back when I was modeling/texturing map assets I was using map2gl to take screen-grabs of the texture images with each of the 16 palettes applied and splicing them together with Photoshop. My workflow was okay but slow and tedious. After explaining to Python where to find and translate the disk info I was able to automate the production of gray-scale texture bitmaps as output from Python code. It's been a struggle writing a working script, but it was exhilarating to run it last night and populate a folder with all the textures. Below is the function I defined to accommodate this, which I ran from a short py file to work through all the map files. There are actually multiple versions for most maps but they have only minor differences (some are used for alternate times of day with different shadowing and such that I don't think were used very much in the actual game).



The gray-scale images contain 16 shades of gray, and colors get applied to those shades when a map is loaded in the game. I haven't yet investigated this data yet but I spent time today working with the hex chunk of the map mesh file for Orbonne that identifies the 16 color palettes and each palette's 16 colors. I was able to successfully output a 16x16 image replicating the palette just like gomtuu programmed for the map2gl. I was elated when this worked. For this portion of the work I spent a good amount of time looking at the hex info and trying to parse out and translate hex to binary or decimal before actually programming. Taking notes and writing things out was a helpful precursor to actual programming. I only ran the script on Orbonne, but I'll be wrapping it up and making it work across all mesh files. Below is my program window in front of the texture editor from map2gl for a clear comparison.



That's it for now. It might not seem like much to experienced users but it was a hard fought climb for me. My next summit will be to better understand how the different palettes get applied to different areas of the texture images and then it's on to working with the 3D information. I intend on figuring out a way to make OBJ files to import into Blender with MTL files to apply UV textures.

For fun, below is a GIF cycling through each map's primary gray-scale texture image. I'm going to take a break for a bit (hopefully not a year this time) but I'm excited to continue on and keep unearthing ancient machina. Until next time! Take care everyone!

[Satchmo III]

I wrote code this weekend to open a mesh file from the game and write the vertex, normal vector, and UV coordinate information to an OBJ file. I only worked with 056 but the code should work for any of the mesh files. I had to play with the UV info a bit so the coordinates translate to Blender (things like dividing the coordinates derived from the mesh file by the texture image file size (i.e. 256 for the U and 1024 for the V) so the OBJ file contains UV values from 0 to 1). In Blender with the gray texture map brought in...



There are a couple issues I need to work out. The first one I don't think I really mind at this point but the normal vectors all appear to be facing inward even if I reverse them in the OBJ file. To reverse them I'm just multiplying each of the X, Y, and Z portions of the vector by -1 and I'm not sure why this wouldn't do the trick but Blender shows the normals pointed inward either way. Perhaps I mistranslated some of the bytes to begin with.

The second issue definitely needs to be fixed. The UV coordinates as they've been outputted from the mesh file are off slightly. I noticed this issue with the Ganesha viewer and early on in my map exploration days I was correctly placing UV vertices manually anyway, but there must be a way to resolve this by modifying the data when coding and creating an OBJ file.

For each tri polygon one vertex needs to be shifted +1 X unit, one vertex needs to be shifted -1 Y unit, and one vertex needs to be shifted +1 X unit and -1 Y unit. This is the same for three of the vertices of each quad polygon, and the fourth vertex stays put. For one of the triangles, below shows the UV output from the mesh file at the left and my manual adjustments to correct it on the right.



I was hoping I could easily fix this by adding the appropriate units to each UV coordinate in my code, but when iterating over all tri vertices (although the tri above was fixed) the order of the vertices in other tris appears to be different so the units were added/subtracted incorrectly depending on the polygon. It isn't clear to me currently how to resolve this, but I suspect it has something to do with the order of the vertices in the mesh file. I'll need to figure this out to both correctly apply the texture to the model mesh and to be able to parse out how the color palettes get applied to the gray-scale texture.

I haven't worked any with some of the more game specific mesh file data like terrain types or polygon visibility parameters. I don't think I'll bother with this stuff until (and if) I try to build a new map and back load it into a mesh file.

May you taste of victory until next we meet, Zodiac Braves!

[Satchmo III]

I believe the UV coordinates have been fixed. gomtuu's explanation back in 2010 will be better than I can explain (LINK), but essentially instead of moving certain vertices to increase the shape's size the solution was to shift the entire shape by 0.5 pixels in +X and -Y directions (really +U and -V in the parlance of texturing). This seems a bit strange because there's technically an unused texture border around each polygon on the UV texture, but even so when it's applied to the model the texture looks seamless.

I've had some success in looking at the gray-scale texture image and applying the correct color palette to correct polygon areas of the image, though I'm having some difficulty parsing out how to instruct python to correctly loop through all of the pixels in the bounds of every polygon. Below is where I'm at currently after trying to focus just on the quads, though not all of the quads actually got looped through it seems.

[Satchmo III]

Success! I iterated through each UV polygon to determine each UV polygon's max/min U and V coordinates and then iterated through each coordinate set to check each pixel's grayscale color and then swapped it with the appropriate real color from that UV polygon's color palette to create a color version of the texture image.

Since some UV polygons overlap, this process would happen more than once and changed the pixels in the area of overlap a second or third time to an erroneous color. To solve this I first checked if the pixel was one of the original 16 grayscale colors and if it wasn't, to ignore changing the color. That way the pixel only changed once, the first time it was converted from the grayscale to the color.

I've only ran the script for two maps (shown below) and am pretty happy with the results. I'm traveling out of state this weekend and won't be able to automate things more until I get back. Until the next update, take care reader.

[Satchmo III]

I wrote code to read each map's GNS file to determine if the game files for each map contains mesh or texture info. Only a few maps have a single texture...most have multiple full size texture images each with subtle differences (usually varying degrees of shadowing). Each map has multiple mesh files also, it seems like one primary mesh file and a bunch of others with very small file sizes. I suspect these smaller files have something to do with animation tiles and/or moving mesh parts...I haven't seen things like moving windmill blades in the primary mesh files as of yet.

I iterated through the map files to create OBJ and PNG files that I then imported into Blender. A small amount of the maps have some minor pixel color issues (if you look closely below you can see some blue where there shouldn't be blue on a couple of the maps) and 20 maps had messed up vertices. I'm a bit surprised by these glitches since 90% of everything else came out looking good...I'll be investigating these issues and looking into the moving things.

[Valkirst]

Holy hell man! (or should I say"Dark Holy") This is all such amazing work I had to re-read through most of it to even barely begin to grasp what it is you are doing but it looks amazing.

[CoderBrandon]

This is absolutely incredible work! Well done!

Awhile back I did a deep dive trying to do exactly what you've done and I only managed to get a very rough 3d model with completely broken and mis-paletted textures that would crash Blender but could be opened with some other 3d model preview programs. I got frustrated and quit shortly after that as I'm fairly good at programming but I'm terrible with 3d modeling.

I've been wanting to make a papercraft version of some these maps for years. @Satchmo III - Do you have a link where I can download the Blender files for these? And/or a link to the script you created to convert the raw map data into a Blender object?

[bizenboat]

I'm a little late to the party, but I'm also super interested in porting maps into Blender for a project and I'm really impressed with the basic models, not to mention the detailed versions of Orbonne and Dorter. I tried sending a message to Satchmo but don't know if he's around anymore... anyway, I will take a look at this myself but just wanted to leave a message here in case Satchmo comes around and can save me a ton of time and frustration.

[Zaibach333]

What has become of this? Resin printers have gotten cheaper and I thought I had only dipped my feet into this stuff but you've made a heck of a lot of progress already.

Well done, many years late but well done.

[nitwit]

In b4 the mandatory chastisement for wasting a while kilobyte of database storage.

[3lric]

In b4 the mandatory chastisement for wasting a while kilobyte of database storage.

Nope, I gave him the link myself, he was interested in 3D prints of maps. Necrobumps aren't an issue if it's actually relevant and there are no other existing topics that cover a thing they are needlessly necroing about. As are 95% of necroposts

(Also database has never been the reason any forum cares about necroposting)

[Zaibach333]

Hope you don't mind I used the Orbonne Monastery stl file from earlier in the post.

[Araujo]

The very idea that we might be able to 3D print Maps from FFT is absolutely amazing and i would really like to have access to more.

Looking online i have found Magic City Gariland ( https://www.thingiverse.com/thing:1596726 )

And with this, that makes two. Im pretty sure you can scale these up and slide in 4 equal parts to make it into a bigger map... but more experimentation is needed.
Regardless, are there any more STL files of Other FFT maps?

If anybody has access to these, please do share!

[Satchmo III]

Hi FFHackers! I apologize for not responding to anyone for, well, years at this point.

Though I haven't been able to continue my map exploration since my last post, my heart has never forgotten it. My memory isn't quite as good as my heart, but I'd like to dust things off maybe in the near future. Thanks to everyone for your interest and I simply love what @Zaibach333 was able to achieve with the Orbonne Monastery!

If you're interested in learning more about the maps you should check out the #map-editing thread on the FFH discord server. The community is doing wonderful things over there! Take care hackticians!

[Nofizo]

Thank you for sharing, I love all the works presented in this thread. I would love to get 3D pring and install it in my property in Spain. Would be really fun, will look into this idea more closely next month.