Is it poor technique to leave "unseeable" walls as untextured?

[LVENdead]

I'm talking about walls like the doors that open when triggering monster spawn traps (in the sectors that house the ambushing monsters outside the playable area of the map) and other things that a player would not feasibly see unless using noclip cheats. It certainly saves time as a mapper, but of course it also throws up a whole bunch of "errors" when running the checker in Ultimate Doom Builder. Is it common for skilled mappers to texture these walls or can I get by leaving them untextured? Are there things that could break by not texturing these walls that aren't obvious to new mappers?

[ViolentBeetle]

It shouldn't take you too long to texture them in random texture. I often texture them in key textures because I can.

 

But it's not necessary.

[RonnieJamesDiner]

I try to make sure everything has a texture on it, but generally my monster closets and other "unseeables" remain the default STARTAN2. 

[JadingTsunami]

As others have mentioned, from a player's perspective, there is no difference and thus no real "etiquette" or rule there.

 

However, it's considered good general practice not to leave known errors in a map because it makes it easier to miss legitimate errors when you run automated checkers. The checker, of course, does not have a built-in method to determine what's an "unseeable" control sector and thus safe to ignore (although a method could be devised, I suppose).

 

So in the end, I think the answer is it's better to apply textures, but this is for your benefit as a mapper to ensure the output from automated checkers remains accurate.

[Mitchfork]

I apply a dummy flat/texture (e.g. something that's entirely bright red or bright pink) to surfaces that are not intended to be seen.  That way they stick out very obviously if I see them during testing and they can be fixed.  This is more helpful for complicated stuff like portals where it's directly intersecting the main map geometry, though.

 

I've poked around only a few custom maps but I haven't seen people leave their control sectors/teleport closets untextured.  I don't think it would break anything but there's no reason not to just leave them whatever default texture/flat gets applied at least.

[Graf Zahl]

1 hour ago, JadingTsunami said:

However, it's considered good general practice not to leave known errors in a map because it makes it easier to miss legitimate errors when you run automated checkers. The checker, of course, does not have a built-in method to determine what's an "unseeable" control sector and thus safe to ignore (although a method could be devised, I suppose).

 

So in the end, I think the answer is it's better to apply textures, but this is for your benefit as a mapper to ensure the output from automated checkers remains accurate.

 

 

Seconding this. It's the same in programming that it is advisable to address compiler warnings. Although most are merely obnoxious, having too many of them will eventually obscure the serious ones that cause actual misbehavior later. It's not much different here.

 

 

[Gez]

3 hours ago, LVENdead said:

It certainly saves time as a mapper

How? Modern editors automatically apply default textures by, well, default. Leaving control sectors untextured demands therefore to go out of your way to remove the textures. How is this a time-saving measure?

[LVENdead]

50 minutes ago, Graf Zahl said:

Although most are merely obnoxious, having too many of them will eventually obscure the serious ones that cause actual misbehavior later.

 

Aside from some of the other good reasoning, this one stands out to me as something that might not be as intuitive until you have experience, and I definitely wouldn't have thought about it from that angle without your comment.

 

10 minutes ago, Gez said:

How? Modern editors automatically apply default textures by, well, default. Leaving control sectors untextured demands therefore to go out of your way to remove the textures. How is this a time-saving measure?

 

I probably have a default setting in some strange configuration then, because if I make a sector and then make like a door sector and begin lowering the height, the front sides of the door are untextured. Good to know there is probably a quick fix for this.

[Gez]

3 minutes ago, LVENdead said:

I probably have a default setting in some strange configuration then, because if I make a sector and then make like a door sector

Yeah, the default texture gets applied to the mid texture, and it's removed when connecting to a different sector without adding upper/lower textures automatically.

 

I was thinking of stuff like monster teleport closets that I've sometimes seen fully untextured despite all the lines being single-sided (except for the teleport lines of course but those genuinely don't need textures).

[Uni]

I remember John Romero specifically brought up the same issue in "Devs Play"  (start out at around 3:20) and acknowledged the fact that he should've textured unseen textures just for the sake of knowing you're leaving something unfinished. I do the same as I find it hard to leave things not textured just because no player would see them, especially since it's really easy to simply apply textures and there's no really an excuse to leave it as such.

 

I should point out that there are occasions where it's actually beneficial to leave walls untextured, especially if you're implementing the "flat bleeding" effect to your map to create fake deep water or hide a brighter/darker sector light.

Edited July 28, 2020 by Uni

[HAK3180]

I almost never texture things that "can't" be seen, especially trap monster closets. It reminds me that that area is out of bounds. I also use untextured lines deliberately for a number of things, so I pretty much ignore that particular "error."

[Doomkid]

When I go on little noclip adventures and see OOB areas untextured in a map, I honestly ask myself "what has happened to this mapper to make them think this is okay?" You're seriously going to put me in an incomplete world? That's just fuckin' irresponsible, man!

 

As for my actual answer, I don't care about it, but personally I never leave anything untextured unless it needs to be that way to achieve the desired effect. Certain ports will display loads of missing texture errors in the console if you don't do them all which just doesn't look as good as it should. I also think missing midtexures on 1 sided linedefs will flat out crash the engine in some older ports, though I may be misremembering.

[Juza]

It really doesn't matter.

[Maximum Matt]

Hey man, if map01 can get away with it, so will I

[Aurelius]

I somewhat agree about it being good practice not leaving errors where there is no need, doubly so with something like programming. However when it comes to Doom level design, this cannot really be consistently applied for a few reasons.

 

To answer your original question, it doesn't practically matter if you don't texture monster closets (the collision will still work the same way.) I sometimes do that with a specific texture/flat combination, either as an artistic self-indulgence or ... well, for that. I mean, at the end of the day if you (the player actor) are physically unable to see the wall with the missing texture, then isn't it true it's also never rendered (or not rendered?) So is there a visual error just because there's a potential for one? Sure you can IDCLIP, but if you do, you're seeing a whole lot more visual glitching than a few HOMs caused by untextured walls.

 

Spoiler

 

To sidetrack a bit, let's consider the Map Analysis Mode (a fine tool, everyone should use it!) It shows you a lot of important map statistics, and can help you fix errors caused by hard to notice things, such as overlapping vertices or linedefs that haven't been merged. But there are also a few "errors" that one might not consider errors at all. Some of these can be found when using the "Check unused textures" feature, which lists all textures that are not currently visible to the player. Perhaps you made a staircase, but later you decided to reduce the number of steps for whatever reason, and when lowering parts of it into the ground you left the lower texture on it even if the player doesn't see it. It's then considered "unused", and could safely be deleted. However, if you have a platform that is lowered into the ground but is supposed to raise later, the editor will still consider the lower texture as "unused" because it is not presently visible. So if you were to "correct" this error, you would ultimately end up with a HOM or a black wall when that platform rises.

 

Another one is the "Check stuck things", which means the the object is partially inside a 1-sided wall, making it practically "stuck". This applies to things like torches too, but more sensibly describes monsters that are actually trying to move (or maybe that bedside lamp isn't moving because it's chained to the socket by a power cord.) I consistently use stuck monsters as progression blockers and sometimes put torches in places where they might be considered stuck, while not really affecting gameplay. These would be considered "errors" by the editor, and by removing them you could inadvertently remove gameplay elements and completely harmless visual elements from your map.

 

Now the "Check missing texture" is the one under discussion, and basically tells you when a visible part of a linedef is missing it's texture. However, if I took as an example my latest map for the 1000 Lines 2 CP, I have 79 results for "Check missing textures", yet the map runs quite fine and as intended, and looks just the way I want it to. That means that all of these missing textures are intentional, and are used to create vanilla compatible visual effects that abuse the way untextured walls are rendered in software. Things such as having different floor and ceiling light levels, creating invisible walls, and making monsters rise up from the floor where no pits are visibly present.

 

How is this related to the question that was asking specifically about walls that are unseen and outside the gameplay area, like monster closets?

 

 

The point here is that you can use missing textures for intentional visual effects in classic Doom, so I would not consider them errors by default. It is (most likely) an error if you see HOMs in the playable area, but when you run the analysis check, you would have to manually wade through all of the different missing texture notifications to track down the ones that are not intentional. This can be very arduous with big maps, so ultimately a better measurement for classic Doom maps is "if it looks and runs with the target source ports as intended by the creator, it's all good". This is why I don't consider untextured walls to be a problem in closets, because you can have a ton of them in playable area without any problems. Also, while the Map Analysis Mode is really handy, it does report some "fake" errors like the ones I mentioned previously (in spoilers.)

 

I'll mention this as a semi-related side note: you can always uncheck the things you don't want the Map Analysis Mode to report. But if you just start excluding stuff on a whim, doesn't that make it completely arbitrary what is considered an error and what is not? Some might even say that this reflects community viewpoints whether to consider them as "features" that make stuff possible that wasn't originally intended, or just "engine bugs". Which leads me back to the advice "if it runs fine on whatever you're targeting, you're fine."

Edited July 28, 2020 by Aurelius

[Gez]

14 hours ago, Mitchfork said:

I apply a dummy flat/texture (e.g. something that's entirely bright red or bright pink) to surfaces that are not intended to be seen. That way they stick out very obviously if I see them during testing and they can be fixed.

That's a good idea. It's kind of like what the Doom 64 developers did, using a default texture that's neon green and with "I SUCK AT MAKING MAPS" written on it; certainly helped notice errors during playtests. But evidently not all of them (skip to 6:07).

 

 

[Dark Pulse]

4 minutes ago, Gez said:

That's a good idea. It's kind of like what the Doom 64 developers did, using a default texture that's neon green and with "I SUCK AT MAKING MAPS" written on it; certainly helped notice errors during playtests. But evidently not all of them (skip to 6:07).

 

 

IIRC to get this to happen in the actual map you have to do some real weird voodoo with crossing trigger lines that adjust floors/heights weirdly.

[Gez]

Yeah, I figure that's what the first six minutes of the video are about.

[magicsofa]

I usually slap something random on monster closet height changes, it bothers me if there are missing textures even if the player normally wouldn't see it. Sometimes, I might idclip to the area to watch what the monsters are doing, so I might see it myself. Anyway, I've seen people leaving missing textures in the actual gameplay area but on lines that face away from the player and are generally hidden. I think that's kinda sloppy... what if you change the geometry later? You might forget that one side of that crate is missing... shoulda used flood fill anyway!

[Camaxide]

What about performance? In most other engines I’ve done level design in leaving surfaces blank means they are not rendered, and thus improves performance (as the engine will render many surfaced even if you don’t currently see them) Doom might not render in this way, or might not different textured vs untextured surfaces.. Graf likely can answer this with ease :)

[pcorf]

My monster teleport areas are always textured but usually with random textures. But sometimes the teleports still use the GATEx texture. Often multiple teleport lines are added facing in different directions to speed up the teleporting process. The areas are not shown on the automap.

[LVENdead]

23 hours ago, pcorf said:

The areas are not shown on the automap.

 

Do you mind sharing a tutorial about this technique (or elaborating a bit)? My understanding is that, at least with Boom compatible maps, you need to join the sector of the monster teleport closet to the ambushing area (or an adjacent sector) so that the sound propagates and wakes the monsters up, thus allowing them to walk into the teleport linedef...but then this would preclude you from hiding the sector from the automap since it is joined with a sector that is in the playable area. Is there a way to build these closets/triggers so that they can be "activated" AND hidden from the automap?

[JadingTsunami]

57 minutes ago, LVENdead said:

Is there a way to build these closets/triggers so that they can be "activated" AND hidden from the automap?

 

Automap hiding is done on a per LINEDEF basis, so it is possible to hide some parts of a sector and not others.

 

This allows you to make an automap-hidden monster closet that has the same sector definition as a visible sector (to allow sound propagation as you mention).

[Mitchfork]

2 hours ago, LVENdead said:

 

Do you mind sharing a tutorial about this technique (or elaborating a bit)? My understanding is that, at least with Boom compatible maps, you need to join the sector of the monster teleport closet to the ambushing area (or an adjacent sector) so that the sound propagates and wakes the monsters up, thus allowing them to walk into the teleport linedef...but then this would preclude you from hiding the sector from the automap since it is joined with a sector that is in the playable area. Is there a way to build these closets/triggers so that they can be "activated" AND hidden from the automap?

Doombuilder has an automap mode that allows you to mark lines as hidden or as solid walls by left or right clicking them.