The main import process required the usage of a bsp decompiler (bspsrc), QuArK to re-export the decompiled vmf to a .map that Torque Constructor can import, and then a big process of exporting and converting all possible textures from source games like gmod, hl2, hl2 episodes, etc (using gsfscape and VTFEdit), and then importing a bunch of those into torque constructor to try and make sure I got all textures to show up in an export.

A lot of clean-up was done to the imported interior to get rid of a lot of invis brushes and zone brushes which would've caused invisible faces and walls in the export. I could automate a good percentage of this, but a lot of manual cleanup still had to be done myself, all the while constructor was running at 10fps trying to render the whole thing.

I had to migrate lighting properties from the format source expects them to be in to the format torque expects them to be in. I couldnt transfer light intensity/brightness, so i then had to go around the entire map (multiple times! because i kept not being happy with the results (im still not, god that tunnel is terrible)) to adjust each and every light to have fitting brightness's and ranges.

I didn't bother transferring any of the spotlight lights. Apparently torque supports spotlights on interiors but I just simply did not bother to port these. Sorry

The displacements had to all be redone completely manually, using torque terrain. This also ended up being a rollercoaster. I thought it would be a great idea to reduce the terrain squaresize from 8 to 4 (half) so not only are terrain textures smaller, but the terrain itself can be more detailed. This actually produced a great result, but as soon as I added a waterblock to the water section of the map, I was met with most of that water not rendering properly. It turns out that the engines water coverage code is hard-coded to expect a squaresize of 8 and nothing else, so I had absolutely no option but to just change it back to 4, and just deal with super low quality terrain textures. Except I didn't want to get rid of all the previous hours I spent sculpting all this terrain, so I then went down a rabbit hole of trying to size down the terrain manually.

(I was able to get away with a smaller squaresize in gm_flatgrass! I also left the original terrain in the map files if you want to go uncomment it to see it yourself)

I sorta learnt how the .ter terrain file format works. The first byte is for... I don't remember. After that though are 131072 bytes for the main terrain heightmap, as 16-bit grayscale 256x256. After that are multiple texture paint maps for each texture I think? each 65536 byte long 8-bit grayscale 256x256. For me to not lose my previous terrain work, I used a hex editor to extract the chunk of data for the heightmap, and used imagemagick to convert that into a .png I could edit. After that it was as easy as editing that image to resize that heightmap down (still keeping resolution the same, just shrinking it to the center) and use imagemagick again to convert that back into raw data I can then insert back to the .ter file.

The resize process did work, but the resizing algorithm left a lot of terrain edges messed up, so I then had to go around the whole map manually fixing all of these. I could've used nearest-neighbor to scale, but I thought that the smoothened terrain would be a nice benefit.

That doesn't end the terrain adventures though. There's still more to come. I wanted the terrain outside of the map areas to be invisible, so there isn't a bunch of extraneous flat terrain all around the outside of the map. I naively went around and painted all of the terrain outside invisible, trying to be exact with it to make it neat, and then reloaded the map to find that half of the terrain wasn't invisible anymore. How come?

It turns out that the emptySquares variable on the terrain is limited to 100 words, so defining the entire rest of the map as empty is literally impossible. I fucking learnt from vitawrap that the numbers in this variable are bitmask pairs defining RLE words as 32bit integers where their lower 16bit part is the offset from 0 (terrain square) and the higher 16bit is the span of that empty line. I tried to simplify these empty spans (on the day of release even) but found that the entire map is just a few terrain squares too wide for it to work whatsoever. maybe I could resize the water area down a little bit to fix this, but I felt like I spent too long on this map port. In the end I just left the half-invisible terrain in, since it looks good enough while you're inside the water area.

Near the end of this entire adventure I was once again adjusting lighting to try and be better, and decided to experiment more with trying to raise the lightmap resolution of the interior. Previously I tried to do this so the lighting can look far better, but the game would just crash upon trying to light the mission. I found out that if I cut the interior into just a small section of the map I could export it with better lighting successfully, sooo I then decided to split the gigantic interior up into segments. It turns out this was probably a huge mistake, but I rolled with it anyway. I split the interior into 7 parts, but this meant that the amount of export issues greatly increased, especially when my method of splitting the map abused the undo stack in constructor, so I couldn't just restart constructor to fix these issues immediately. I spent hours re-exporting these parts of the map over and over to try and get the best exports I can, and in the end I can't even easily re-export these segments because I'd have to manually split up the entire map again. I am very silly and I sorta rushed this just to try and finish this damn map already. Some export issues still remain in this final release, oh well.

If you really read all the way to the bottom of this insane rant then I'm actually kinda surprised. I apologise for making this insanely long.