Texture Names in Code

Question for people who make large texture packs, or mappers who make maps with a huge resource pack, or anyone who is smart with organizing large pools of files/data. Is there a smart way to “code” the 8 character names of texture entries in a TEXTURE1 lump so that it’s easier to filter exactly the texture you need for a specific linedef in a texture pack with hundreds of textures?

I get so frustrated with mapping when I spend too much time trying to find exactly the texture I need in a large resource. My heads a little scrambled here because in looking at the Doom 2 IWAD, textures are named a single word or compound word that describes what it looks like, followed by a number. We are used to this, but I’m not so sure how important it is that textures are named this way. The only reason this works is because I memorized the names of my favorites and can quickly type their names into the search bar to eliminate everything else. This is not going to be useful when I’m making a texture pack that includes many more textures than the IWADs have.

For example, I have many varieties of borders and support beams specific for certain alignments. They also come in a variety of colors, materials, patterns, or have special circumstance details on them like endcaps, signs, logos, computer screens, or something else on them.

Would it be worth my time to perhaps try naming my textures in some sort of a code?
eg. Type, Color, Material, Pattern, Vertical Alignment, Horizontal Alignment, Special(?)

I would categorize my textures in a set of lists where each type, color, material etc. is represented by a single character. Has anyone done anything like this before? Are there other mediums outside of Doom where large sets of data have to be organized under these limited conditions? Is it important that textures that are like each other are near each other when casually scrolling through the alphabetical window of a texture browser in the map editor? Suppose I had to share this texture pack, along with a key or a legend to use as a reference, would it still be confusing as fuck? If so, what do you suggest?
 

Doom Builder lets you create categories and sort textures into them within the editor. Chances are you know that already, and it's a lot of work, though I'm not sure it's any more work that coding those same categories into the textures themselves. When I first loaded up Baker's Legacy, it took me days to make lists and sort out all the textures into color/type groupings, but it has been well worth the effort, because now I can easily find what I'm looking for every time.

As a creator of textures, you can certainly make this process a bit easier for yourself or other mappers who use your textures. I start all my textures with NJ followed by around 4 characters that contain a color or other grouping. So my Brown recolors have all been named as NJBRWN[number], which allows mappers to enter a single string into one of Doom Builder's texture category lists and add all of them to that same list. I can't think of any way to add more than one variable into the same texture name and still have it be reliably searchable by each variable, though.

17 hours ago, Not Jabba said:

Doom Builder lets you create categories and sort textures into them within the editor.

Yeah I suppose I could look into that. If it also supports categories within categories, that could help a lot.

ive seen other texture packs, and they do have the authors initials as the first few characters like the N_ stuff of nick baker or the adel_ stuff of adelusion. I'm not sure what is helpful about that. I'm not sure a mapper would want to filter their textures for their map based on who made them.

my current setup has the first 3 characters of the texture entry as the color. BRN for brown, GRY for gray, GRN for green, etc., with numbers after it. This is ok until I have many hundreds of brown gray and green textures. Now I kinda wish I had them organized better. So for example lets say I need a 16width Gray support beam texture. I could create some sort of a key (shown below) where I could type 242 into the search bar to quickly filter exactly the texture i want (named something like "242xxxxxx" where the x's may be some other codes indicative of increasingly specific details about the texture)

Color:

0 = Other

1 = Brown

2 = Gray

3 = Green

Type:

0 = Other

1 = Wall

2 = Door

3 = Border

4 = Support

Alignment:

0 = None

1 = 8 Units

2 = 16

3 = 24

4 = 32

5 = 64

7 hours ago, 40oz said:

Yeah I suppose I could look into that. If it also supports categories within categories, that could help a lot.

 

ive seen other texture packs, and they do have the authors initials as the first few characters like the N_ stuff of nick baker or the adel_ stuff of adelusion. I'm not sure what is helpful about that. I'm not sure a mapper would want to filter their textures for their map based on who made them.

 

my current setup has the first 3 characters of the texture entry as the color. BRN for brown, GRY for gray, GRN for green, etc., with numbers after it. This is ok until I have many hundreds of brown gray and green textures. Now I kinda wish I had them organized better. So for example lets say I need a 16width Gray support beam texture. I could create some sort of a key (shown below) where I could type 242 into the search bar to quickly filter exactly the texture i want (named something like "242xxxxxx" where the x's may be some other codes indicative of increasingly specific details about the texture)

You can always name your categories things like "City - Gray" and "City - Brown" and so on so that the subthemed category names all appear together in the list.

Personally, I think it can be frustrating to find the sources and give credit for textures that I've found in other people's wads; a couple of characters for the author's name at the beginning of the texture makes it easier, and having that NJ there also makes it a lot easier for me to sort my textures into categories than it would be if I just started my texture names with "GRN" or "GRY" or whatever, since lots of existing texture names already start that way. If you are using your own textures exclusively, then this may be irrelevant.

I've also found that after sorting my textures just by color and/or intended purpose/setting (metal, natural rock, city, hell, doors, decorative panels, etc.), I don't really need to do any further sorting. Out of the 1700+ textures in Baker's Legacy, only around 250 are sorted into my Gray category, for instance, and that's the largest category I have. If I really need a 16-wide texture, I can just look quickly through that list to find one. YMMV if your overall texture set is more like 5,000 textures.

The code you listed does sound useful and would probably help you a lot with sorting your own textures if you want to go to the effort, but I think it would be hard for anyone else to make sense of, and it may not jive with how they intuitively categorize things. Sorting by border vs. wall vs. support is something I wouldn't find particularly useful, for instance, and it would be hard to sort by intended setting (like if people want to find Gothic Hell textures vs. Flesh Hell textures).

I feel like you don't need complex naming conventions with multiple variables. If I'm looking for a damaged blue door with skulls on it, I'll just go to the door section and then use my eyes to find what I want. So I think usually when naming textures it's enough to put its "main" feature in the name.

Color is probably not the best feature to choose since it's so general. What's easier: going to blue textures and finding a door in there, or going to door textures and finding a blue one there? In the latter case you immediately narrow it down to a much smaller selection, which is nice.

5 minutes ago, Memfis said:

Color is probably not the best feature to choose since it's so general. What's easier: going to blue textures and finding a door in there, or going to door textures and finding a blue one there? In the latter case you immediately narrow it down to a much smaller selection, which is nice.

Possibly true. Color works for Heretic textures, because 90% of them are stone walls. I prefer the hybrid approach; I have a Blue category *and* a Door category, and blue doors appear in both, so I find the right texture either way.

You could try using single letters for color. Now I know that black, blue, brown all start with b, and gray and green both start with g, but perhaps you could look for other names for these colors and get unambiguous single letter codes. For example:

i (indigo) - blue

v (viridian) - green

k (as in CMYK) - black

Then you have a single letter for theme -- Tech, Hell, Medieval, City, Surreal, whatever. And a single letter for the use -- Door, Wall, Support, Border, Trim, Platform, Misc...

So let's say you have a green tech door that's 64x128, it could be named VTD and you still have five characters left for anything else.

Thanks Gez. I was planning on using numbers because the number pad keys are all near each other, and because the texture browser in GZDB is in alphabetical order, it would put all my new textures in one spot instead of scattered in between the rest of the IWAD textures like they currently are. I do lose the advantage of having 26 possible categories instead of 10 though.

I see some people wouldn't find this very useful but in my texture pack I have a lot of muted color themes and a lot of special usage type things that makes many of the textures look very similar until they are examined very closely. So to give you an example, I'm not really choosing between a blue door and a wooden door, but more like choosing between two wooden doors, one with minor scratches on it and one without. And for some reason this is important to the appearance of the map. The example of the specific gray 16 width support texture is common too, but for the purposes of my mapping project it also gets more complex than that.

Here's some sort of draft of a coding pattern I thought of. I can already tell coming up with specific definitions for every thing is going to be a pain. I'm thinking of looking at the IWAD textures to see how I would code each of the existing Doom textures. Currently 4 character codes, the remaining 4 characters I guess can be variants 0-9999 for when there are more than one texture that fits exactly the same set of categories. I'll have to review the IWAD textures and try and sort out each one. Hopefully there aren't too many things that land in 0000. I'm curious to know if there are any textures that definitely not fit anything ._.

1.) - Color

0 Other
1 Gray
2 Brown
3 Tan
4 Green
5 Red
6 Pink
7 Blue
8 Pink
9 Black

2.) - Type

0 None
1 Wall (Flat general surface)
2 Object (Walls with an object on it, i.e. computer screen, gargoyle face, window, poison sign, etc.)
3 Usable (Doors, lifts, switches)
4 Middle textures (fences, bars, vines etc.)
5 Horizontal Border (step textures, borders, trims, etc)
6 Vertical Border (SUPPORT3 or WOOD8)
7 Lights
8 Stuff (Pipes, skulls, tekwalls, etc.)
9 Special Usage (nukage trims, waterfalls, etc.)

3.) - Alignment

0 None
1 8
2 16
3 24
3 32
4 64
5 128

4.) - Pattern

0 None
1 Brick
2 Rock (any natural/irregular pattern)
3 ??? (I'm sure there are more patterns, I just can't think of any atm)

Now that I'm looking at it, this kind of code is kinda prioritized in the qualities I tend to look for first while choosing textures. I don't know if this applies to everyone's mapping style. I'm curious to know what kinds of categories are missing, or how they should be rearranged, etc.

For the time being I'll have to limit something like this to my own projects just to make mapping more streamlined for myself.

Is it impossible to have longer names in GZDoom Builder? Sounds like a good feature request. I mean, we shouldn't be struggling with the 8 char limit in 2017.

1 hour ago, 40oz said:

I was planning on using numbers because the number pad keys are all near each other, and because the texture browser in GZDB is in alphabetical order, it would put all my new textures in one spot instead of scattered in between the rest of the IWAD textures like they currently are. I do lose the advantage of having 26 possible categories instead of 10 though.

Mostly I think the problem with numbers is that they're very arbitrary and there's no good memory-aid thing to remember which is which. I mean, perhaps you could try to work some, like "one is brone, two is blue, threen is green" but it's kind of hard.

36 minutes ago, Memfis said:

Is it impossible to have longer names in GZDoom Builder? Sounds like a good feature request. I mean, we shouldn't be struggling with the 8 char limit in 2017.

It's possible but the issue is more about whether the game will accept that. Currently GZDoom in UDMF lets you use longer texture names. For vanilla/Boom/other non-ZDoomy things, you'd need to have some sort of alias where long texture names are mapped to short texture names and that's a whole other kettle of fish.

Disclaimer: Didn't read all the prior posts. Ain't nobody got time for that.

My upcoming OTEX pack has one naming convention for patches that no one needs to understand, and another for textures:

• They all start with O because no IWAD textures do and my name starts with O. This also makes them all easy to find in the editor rather than being scattered among vanilla textures.
• 4 letters are for texture type. This can be BRCK for bricks, CONC for concrete, LGHT for lights, etc.
• Then it's A-Z for what variety of bricks, concrete, lights or whatever.
• The last two characters are numbers, 00-99. Within these there's a naming convention too, where 00-09 are plain materials with little to no patterning. Then 20-70 are mostly for orthogonal lines, where I kinda messed up and made them YX instead of XY but whatever. 1 horizontal subdivision and 0 vertical, i.e. a texture that is 128px tall and infinitely wide in terms of lines, is 20. With 2 vertical subdivisions, so that it consists of two 64px tall bands, is 30. 64x64px blocks becomes 33 because now the second number is in play. So something like METAL2 would in my world be OMETLx34.
• x7-9 are often used for custom versions, like a 34 with a light at the top, such as METAL6, would be OMETLx39 or something like that.
• Number 90 and up are for things like a 0x version but with a demon face, cracks, or other decorations on it or some more complicated combination of tile sizes.

This is not perfect because there's a lot of patterns and texture types that don't fit into this structure. Like what about a railing? What about a version of METL that is also a VENT? Or a LGHT that is based on the material in an IRON? but I like having 4 letters to describe the material/theme rather than 3, and overall this feels ok to work with in the editor while at 750-something textures.

Granted, I'm not doing the super specific customizations for one-off usage that 40oz is doing, so this approach is not universally applicable.

If I had to do it, I'd use this method. This method scales to literally tens of thousands of textures:

Computers will sort the names in alphabetical order. Designate the first 6 characters to a descriptive name for a group of like textures. The last 2 characters are a number from 00 to 99, and if that fills up, use A0, A1 ... thru ZZ.

So, all green marble textures might be named GRNMAR00 - GRNMAR99 (or ZZ). Here's why this method solves the issues:

• No complex naming scheme for material, color, etc. There's just too many possibilities, and you'd go mad trying to differentiate them.
• The computer sorting of the list brings all textures of a group together. Your eyes do the rest by looking at a similar texture type as a group. You can use all these textures in one room, without having to scroll the texture list.
• 6 characters lets you be quite descriptive, and the names are memorable.
• The last 2 digits gives you room for 36x36 similar textures (0-9, A-Z: 1296 combinations)

The only thing that can help you from having chaos is the fact that the list will be sorted alphabetically, so the first few characters designate where the textures fall within the list. Now, you could break this up and try to denote which material it is, the size, etc, if you're brave, but it's not really necessary, unless you pick textures based on their material, vs. just picking something that looks nice. Either way, take advantage of the sorting - it's the only help you'll get.

I'd like to see doombuilder/slade be able to detect and parse a text lump that sorts textures into groups for mapping - would that be possible? Something that can read names from the lump and if 'they're in TEXTURE lumps then they would be found under whatever named groups of textures you've specified.

>>"Bricks"

{

BRIK01

BRIK02

}

>> "Not Bricks"

{

FIREWALL

ASHWALL

POOWALL

}

(edit: Yeah I don't understand code all that well!)

(and edit again: I'm dealing with a CTF wad that has thousands of textures. As epic as GZDB is, it hangs when loading all that. I don't just want that experience personally, I'd like for others to be able to use this wad as a good resource base for their own maps)