News | Forum | People | FAQ | Links | Search | Register | Log in
OTEX Texture Pack
The OTEX texture pack for the original Doom has finally been released.

During development I decided I wanted OTEX to become a de facto standard for non-derivative DOOM textures, and realized that meant I’d have to outdo all other texture sets in terms of versatility, and do so while sustaining a very high quality level. The incredible work in BTSX has remained a major inspiration in this pursuit, but I also wanted the broad range of CC4-TEX so that mappers would be happy to use OTEX as their one and only texture resource. These are more aspirations than quantifiable goals, but served as my guiding principles.

It's most notable for having powered the well acclaimed custom wad Eviternity, as well as many others.

It's brand new, mostly hand drawn, and fucking huge (over 3,800 textures). And it looks great!

For those reasons, I've decided to port it to Quake.

In lieu of a development blog, this thread will serve to document my progress and provide updates.
Day One. 
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! 
External Textures! 
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:

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. 
Good Luck 
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 1: Play Doom 2 
Step 2: Eviternity 
To Be Fair 
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 (hammer/drill/uzis...) 
October Update!! 
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:

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:

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.

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. 
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.

Composing textures out of patches is probably a type of optimization, where the patch can be unique art which is shared by many textures and only stored once. Now they are baked into the textures so you have a lot of duplicate runs of pixels (e.g. 3 different panels with only a different stripe at the bottom.) 
Curious why that wouldn't have been a factor for Quake in 1996 though. 
well it was 3 years later, maybe the increase in available memory made it not worth the trouble. 
Animated Switches 
When it comes to buttons, OTEX has a huge variety of symbols and colors to choose from:

Unfortunately, Doom does not support animated buttons out of the box the way Quake does, and as such, they are not provided in the original WAD.

However, there's nothing a little Photoshopping won't fix:

So, proper Quake-style animated switches are now in! 
Double Post... make up the otherwise low-on-content previous one.

I plan on getting this pack up and running by December 1st.

Most of the heavy lifting is done, what's left is still a whole lot of small nitpicky stuff that's simultaneously easy, and also time consuming, but will leave the wad feeling fatally unpolished if it was to be left out.


- liquids (easy)
- animated textures that aren't buttons (this will be tricky)
- fence textures (no idea if this will even work with external TGAs)
- some actual example maps (argh!!!)

The next two weeks should prove quite productive, hopefully.

Until next time! 
External fence TGAs use alpha channel for transparency. 
That Is Great News! 
GG Otp 
Looking forward to combing through these suckers.


@Chedap - please tell me you are making more maps. Your Halloween map was stellar. 
External textures can't have fullbrights, right? :( 
Sure They Can 
You use a separate texture with "_luma" suffix. I think every engine that supports external textures follows this naming scheme, but I haven't checked all of them.

Keep in mind that most engines (QS included) use "additive" luma rather than "masked". This means the values of _luma texture get added to the underlying base. This, in turn, means that to get correct behavior you'll want to "cut out" any fullbright areas on the original texture by painting them black.


Additive is compatible with masked but not the other way around.
Full range of colors can be used.

@dumptruck: that's the plan 
Holy Shit! 
This explains a whole lot.

Executive Decisions. 
Despite sharing a lot of the id DNA, the fact remains that Doom is a different game than Quake, and their engines do many things differently. (Moreso for Doom's wide bench of source ports.)

The sad consequence of this is that porting a modern Doom wad to Quake can't be done on a 1:1 basis.

One of the most notable omissions in the Quake version of OTEX will be the animated assets used to denote teleports, i.e. animated telepads and animated "slipgates".

The reasons behind this are:

1) Quake's texture animation speed is a fixed 5 frames per second. This is much too slow for the vast majority of animations provides in OTEX. While there is a way of circumventing this limitation, having the wad rely on them would create yet another barrier of entry in a texture pack already more complex than usual.

2) There are several such animated textures in OTEX, and they have a considerable number of animation frames. Because of Quake's texture format, this would mean that there would be multiple animations at the very top of the wad "obstructing" the view to the rest of the wad. I find it quite frustrating even in wads with relatively few animations, and I'm deciding to spare myself from the extra aggravation ;-)

3) The way I see it, making these textures animated was a way of drawing the player's attention to important progression points. Quake has better tools of achieving that goal than a small spinning heptagram - including actual rotation of 3D geometry!

4) Possibly the most subjective reason - the anims simply don't fit in Quake the way they do in Doom. The latter, whie not really Keen or Wolf3D anymore, still has a more "video game-y" feel than the solemn, edgy favorite of ours.

With all of the above in mind, I've decided to cut out most of such animations. What will be remaining is:

- Two opposite-facing frames of each heptagram, since it's a cool graphic and it would suck to see it go entirely,
- One frame per each of the "slipgate" exits, to be used as liquid textures in typical Quake fashion. It's a mediocre compromise but it's better than nothing.

While it does feel sad to have to make decisions such as these, I can already feel a great load gone off my chest (no, not yours, Shambler) - not having to worry about these animations has given me more time and brainpower to tackle the remaining problems.

Hopefully by next week I will be able to provide proper screens of proper maps! 
On That Note 
Another big omission will be the skyboxes. Sorry, but the sky textures in Doom are just completely irreconcilable with how Quake does things.

Luckily, Quake has no shortage of skyboxes or custom skies, so this should be a very minor, of not almost irrelevant, issue... 
Starting To Take Form... 
Incredible Work 
I converted a few textures myself as "design tests" but converting everything is an insane and thankless task.
This might spark a slew of new and interesting maps/jams :) 
GG Ootp 
We've needed new wads for quite some time. This is gonna be crazy. 
Guess Who Went On Vacation With A Broken Charger? 
That's pretty much a "no" for a Sunday release. 
Gimme Dat OTEX 
Looking forward to this. 
So What Ever Happened To This? 
Too optimistic to hope for a 2020 release or not? 
I've done some small steps here and there, but I've been hearing that ukiro is planning a v1.1 release in the near future, so this is on hold until then. 
Great News! 
Ukiro has released OTEX v1.1:

Production will resume momentarily. 
It's a shame there's no easy way to convert them to the quake palette. So many times I have tried to convert them and greens will turn to browns, whole swathes of detail is lost because quake doesnt have enough greys, red highlights completely disappear etc etc.

The only quick solutions I can think of are either converting the whole lot to the quake palette without really caring how it messes the textures up and then having external textures enabled
converting the Quake monsters etc to the same palette as OTEX and dropping the .pal file into the folder

Or you can just convert all 5,352 textures and slowly descend into madness 
I think the best way to go is making OTEX an external texture source. It's easy, quick and you don't lose any colors since there's no convertion.

Changing the .pal of quake will screw up every texture in the game: monsters, weapons, ammo, powerups, all the mdl and bsp models, all the number and letters of the HUD, all the animated sprites... everything would have to be converted and replaced. It' too much. 
Fifth, Tribal: That's exactly what I've done before, yes.

OTEX v1.1 made this all that much simpler because it already provides a 24-bit PNG download for UDMF mappers.

However I will still be doing manual texture extraction in some cases because of... reasons that should be apparent quite soon. 
having external textures enabled

FitzQuake has had this feature for almost 20 years now. ;-) 
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.