A lot of the heavy lifting has already been done. This was actually a fairly simple - but still a little time consuming - pipeline:

1. Extract the art from the original Doom WAD file using WadExt (thanks, total cunt Graf Zahl).

2. Import the PNG files into a Quake WAD file using Joshua's Tools.

3. Bbatch convert the PNGs into TGAs using XnConvert.

Now, you may already realise why was this last part important - Doom's palette is very different from Quake's palette, to the point where hundreds of original OTEX textures would display really badly in Quake. Remember that this is regardless of engine.

Luckily, however, Quakespasm inherited Fitzquake's external texture support - a feature that save for handful of releases, is still largely unexplored territory. This allows every mapper to straight up ignore Quake's palette and have the originals display exactly as-is.

Compare for yourself: without / with external textures.

OTEX has a lot of very rich greens, blues, purples, and even browns(!) that would convert extremely poorly into the Quake palette. Trying to recolor 3,800 textures by hand to make them fit a more restrained color scheme would be like trying to paint an aircraft carrier with a ball pen.

The end result of this fun escapade is a 76,6 MB wad for Quake. The previous winner in the size category was the Kingpin wad at 22,2 MB - making OTEX over three times as big. I was actually surprised that neither TexMex or Trenchbroom crashed while loading it!

The next step, obviously is lots of optimization. See you soon! 

otp: I saw your first post and started writing a reply asking you if you were going to do a dual-purpose release including both a WAD and external true color textures. Very glad to hear that you already had external textures in mind!

I posted only a couple of days ago in this thread about how Necros' ne_marb map made really good use of external textures to transplant Doom's green marble textures into Quake. So, yes, IMHO allowing the use of external textures is a very, very good idea! 

Thanks for the reply. I'll probably not be doing a dual-purpose release per se, as the WAD on its own is effectively useless: https://cdn.discordapp.com/attachments/521609816162959367/617366837956706330/unknown.png

If you liked ne_marb, you should also try SM189, a few entries make good use of the green marble as well. 

Ah, I didn't word that very clearly -- by "dual-purpose" I meant I assumed there would need to be a wad in addition to the external textures, even if the wad is mainly there as a formality. I was assuming (possibly incorrectly?) that the wad is necessary so that textures can be displayed in all map editors, even if they look bad in the editor, and so there are textures to compile into the BSP file, even if those textures are going to be overridden by the external textures at runtime.

Thanks for the tip about SM189, that may be one of the packs I haven't played, will check it out if so! 

When the Q1 port of these textures is done, this would be a great theme for a community map pack, especially given the diversity of textures here. (OTEX Jam maybe?) 

Yes, definitely. I hope to get this out before Halloween Jam 2 is running. 

I'm unfamiliar with the source, but this seems a worthwhile pursuit. I look forward to seeing the final product. 

You really need to familiarise yourself with Eviternity for Doom 2, probably one of the greatest set of maps for that game ever made. 

Step 2: Eviternity 

Doom 2's "campaign" has aged like total milk. You might be better off just going straight into Eviternity on one of the lower skill levels, it should be a very good entry drug. 

ionous prompted me for a progress update on his stream, so I thought I may as well post here, even though it's disappointing - this will be on hold until October. 

I dig the Eviternity Doom 2 megawad, thanks for tip, nice HD textures. OT: playing it using STRG WEP mod https://www.doomworld.com/forum/topic/74791-struggle-antaresian-legacy-now-available-in-idgames/?page=7 (hammer/drill/uzis...) 

It turns my out my pipeline had a major error I hadn't anticipated, because of my complete lack of knowledge of Doom's inner workings.

The wad I had prepared back in August had two major problems. One of them being that across the 3.8K files extracted, there was no trace of a single wall texture, and lots of 64px tall "stripes" of bricks instead. Which is why the test map had to do this:

https://cdn.discordapp.com/attachments/292234299896365056/639474892609290240/unknown.png

Awful, right? I was already bracing for weeks of manually photoshopping the stripes together into solid surfaces like a simpleton (hence my earlier comment about the next step being "lots of optimization"...)

The second problem were the completely undecipherable texture names:

https://cdn.discordapp.com/attachments/639477405827989508/639477487746678814/unknown.png

I didn't think too much of it at first (other than being completely aghast), since Doom has understandably harsher texture name limitations. But then I figured out that that's bullshit, since I remembered this passage from the OTEX website:

What do the names mean?
Most of the 4 letter sequences can be figured out, while others are more far fetched. BRCK is obviously brick, but BNKR meaning bunker is less clear perhaps, and I’ve honestly forgotten some of the names.

I went to ask Ukiro himself about the above, and came out with a lucky solution - to problems that my own ignorance caused.

The way Doom stores textures is, in short, some fucky shit. What I had initially extracted from the OTEX wad wasn't "textures" per se, but patches, which is what textures are made of.

Ukiro's instruction was to try extracting the images directly from the "TEXTURE2 lump". I still have a very vague understanding what that means, but a brief search revealed that Slade is a Doom editor capable of extracting the textures that way.

With that done, I could reapply the process as before, i.e. batch convert the PNGs to TGA and also create a .wad for the editor.

Interestingly, though this resulted in a total of 2356 textures (a 40% decrease from the original 3892), the .wad filesize has actually increased to 87.7 MB! Is this somehow a fault of how mip textures are compressed? I can only guess.

At any matter, the original problems were resolved, and now (relatively) clear brushwork can commence. https://cdn.discordapp.com/attachments/639477405827989508/639489561256263731/unknown.png

There's still work to be done with the wad though - I have to figure out switches, liquids, transparent textures, and more. So, until next time! 

Good stuff. Keep at it.