Blank-TX: Useful placeholders for map development (now on /idgames)

I present:



Make your mapping process efficient! Don't bother with texturing, coloring and alignment of details while making architecture. Design a good architecture first, then focus on texturing.

Preview of textures:




Preview of flats:





=====================================================

Download link: http://www.doomworld.com/idgames/?file=graphics/blank-tx.zip

=====================================================


Doom-styled placeholder textures for map development. Inspired by Map Development Textures at Realm667 - these offer variously sized tiling blocks and a gritty/blank texture for oddly shaped sectors, all in various colours. They exist to help you with complex alignment before assigning particular textures.

My goal is slightly different: To reduce effort connected with texturing as much as possible, before architecture is done and before textures and colours are decided. Textures in Blank-TX are all grey. They come in variously sized, tiling or non-tiling variants. Intentionally, I've tried to keep their number as low as possible, for simplicity's sake. But I think they're versatile enough, anyway. Basic useful patterns are there. If you're planning to use a texture with a complicated pattern, use outright that texture and not a placeholder!

Now there are 7 versions of the pack: Doom 1, Doom 2, TNT, Plutonia, Heretic, Hexen and Strife. Textures are the same, they're just converted to the proper palette and TEXTURE1 format in each wad. Conversion to Hexen palette has slightly degraded quality of the textures, but not too badly.

Hopefully at least someone will find this useful - just for the possibility, I think it's worth releasing.

Anyway, your feedback and thoughts are welcome as always.

Oh hey they posted my texture set at R667!

These actually look pretty cool. Thanks for making these.

Edit: I'd get a safer mirror (like Dropbox). Sendspace seems to be using sketchy (ermagerd you got a virus!!!) ads too now. I miss files.drdteam.org :(

I hate when any site on the internet wordly prompts me for entering my name and surname, and both Mediafire and Dropbox do. As long as there are other possibilities, I'd take them instead of that. I don't feel like risking making up fake names, even though it probably wouldn't be that big deal in reality, I strongly wish to avoid it. Are there good file hosts that don't require registration or at least demand only a nickname? Of course, I'll eventually use /idgames.

inb4 MEGABLANK community project megawad, using only these.

Cool idea, will give them a whirl.

This looks pretty neat, I'll try making something with this later.

New download link! https://www.sendspace.com/file/deo5qn

Now there are 7 versions of the pack: Doom 1, Doom 2, TNT, Plutonia, Heretic, Hexen and Strife. Textures are the same, they're just converted to the proper palette and TEXTURE1 format in each wad. Conversion to Hexen palette has slightly degraded quality of the textures, but not too badly.

Please let me know if you find out that something is broken or if you have any suggestions for a change. I'd like to upload this to /idgames in near future.

scifista42 said:

Please let me know if you find out that something is broken or if you have any suggestions for a change. I'd like to upload this to /idgames in near future.

The waterfall textures aren't animated :(

boris said:

The waterfall textures aren't animated :(

Liquids intentionally don't animate. In fact, only one frame per liquid is included. They're not supposed to animate because they're not supposed to be kept in the end map product. They're just map development placeholders. I stated this in the text file (known bugs).

Creating the additional frames shouldn't be hard, they're just recolored SLIME and BFALL textures from Doom 2. Do you really think it should be done?

I approve of this idea however the execution seems a little peculiar to me, at least when compared to similar texure sets for other games' editors. For example, why are there muliple textures? What relevance are the details on those textures? Wouldn't it be better if the textures displayed a varrying grid pattern to assist manual alignment in a 3D map preview?

Thanks for your input.

"Wouldn't it be better if the textures displayed a varrying grid pattern to assist manual alignment in a 3D map preview?"

That's what BlackFish's textures on R667 are for. I've tried to explain the difference (my goal) in the OP. Helping with alignment is a secondary purpose. Primary purpose is helping with designing architecture without caring about alignment in the first place.

"Why are there multiple textures?"

As I said, I've tried to make a minimalistic set of placeholder textures as versatile as possible. Different basic patterns are good for different situations. Making a wild shaped architecture? Use non-tiling placeholder. Needs aligning a wall, or the floor to a 32 or 64 grid? Use tiling placeholder. Needs a borderline texture of a specific width? Use borderline placeholder. Needs a midtexture of a specific height? Use midtexture placeholder. Wanna add a liquid, or two different ones next to each other? Use the liquid placeholders. And now: Needs to differentiate between 2 different textures? Use different variants of a principially same pattern. As simple as that.

"What relevance are the details on those textures?"

To make them distinct from each other, while keeping them similar. You can use each of them differently in different situations and still keep track relatively easily. For example, out of the 2 different 128x128 textures, you can use them on different places in your map, and then replace all of the 1st ones with marble face and all of the 2nd ones with a wooden door. Out of the 2 flats aligned to 32x32 grid, one is supposed to be eventually replaced by a normal flat, and the latter one by a flat with a light source.

Cool idea scifista. I'll try it out and tell ya what I think.

In the preview in the OP, what are the third row of textures? Support beams?

So if I understand you correctly, this set is intended to be used according to a user-defined surface level classification of surface type through texture selection, yet not choose a final "material" for a given surface, effectively deferring that decision until later?

If so then it seems to me that this would be best achieved with an editor level feature set, rather than an add-on texture set. Would you agree?

I'll present an argument here: say the mod author wants to introduce a new surface type to their palette; given a texture set based approach, one would need to create a new texture and it to pack. At which point, deciding the dimensions of the texture and what it will look like. This step could be automated in an editor level tool to generate the placeholder texture for you.

@40oz: There are vertical support beams, also supposed to be used as borderline textures. Then there are their horizontal variants, supposed to be used as step textures, railing, or 3D bridges. And finally and obviously, there are some midtexture bars.

@DaniJ: Yes, and yes (maybe). :) My textures simply aim to be universal-enough and look neutral on their own.

EDIT: Well, yes, it might be a cool feature. But while the mapper's process is still in "placeholder stage" when he doesn't want to care about texturing and alignment any more than necessary, then too many surface types to pick from would be just distractive. I thought that keeping things simple would be for the better.

In that case I think I can see an opportunity here to simplify various map authoring processes with a more intelligent model for texturing within a map editor. I'll spend some time thinking about and experimenting with this idea in an editor.

Are you talking about "pseudo textures" that will only be available in the editor and will have to be replaced (manually or automatically), or are you talking about automatic creation of neutral-looking textures by a smart level editor and adding them into the wads?

Generating the placeholder textutes automatically would simply be a convenience feature, rather than being integral to the texturing model itself.

What you are essentially asking for is a way group surfaces according to a user-defined classification of surface type. This classification can and should be completely independent from the mechanisms of the map format, including the use of surface level texture offests for alignment purposes.

With an editor level solution based around the idea of surface type "groups", one could potentially automate alignment across all surfaces within that group. Texture changes could be applied at the surface group level and have the editor automatically figure out alignment as a result (even if the dimensions are different). (Think: one set of offsets for a co-aligned surface group comprised of any number of surfaces).

I think I see now (or am I wrong?): The "surface type group" would be like an additional layer on every line segment, same like a texture, but independent on texturing. The editor would have features to align them automatically, and then (later) easily apply and align textures according to them.

Sounds interesting in theory. In practice, I'm worried about 2 things: First, intricacy of such a mapping process: Applying textures is an intuitive routine for a Doom mapper, it has a direct and clear effect on the map, so wouldn't bothering with "surface type groups" just overcomplicate it for the worse? And second (lesser one), arrangement: Wouldn't the mapper's sight be obstructed by a bunch of overlays, stats and options that will make any "user-friendliness" counter-productive?

Anyway, it sounds like a potentially useful system of placeholder texturing. If you're going to try implementing it in an actual level editor, it might be worth it, and I only wish you good luck.

Yep, thats the gist of it. As you say, the usefulness of such a system hinges on how intuitive it is in practice and to figure that out I need to spend some time with a working implementation with an actual GUI.

I think that such a model could work well and save a lot of time spent aligning things manually (even if that is simply a case of selecting linedefs and hitting the auto-align button).

I can also see some benefits to applying a similar model internally within a sourceport but that is also something I'd need to experiment with.

Hey I played around with the texture set. I definitely like the idea but I think it could be executed better. I felt a lot of types of textures were missing. If you're willing to continue working on this, I made an image demonstrating some ideas I have.

40oz said:

Hey I played around with the texture set. I definitely like the idea but I think it could be executed better. I felt a lot of types of textures were missing. If you're willing to continue working on this, I made an image demonstrating some ideas I have.

*GOING FANCY WITH VARIATIONS*

Having too many variations is not in compliance with my goal of simplicity, minimalism and paying minimum attention to alignment while creating architecture. Check out "Map Development Textures" on Realm667 (linked in the OP), and my explanation of the difference between concepts. That said, feel free to make your own pack, what you've shown looks pretty good.

Looks very interesting. I'd probably use it for custom texture sets that behave themselves, but the vanilla textures have some pretty eccentric alignments that sometimes require very specific geometry.

Having used AutoCAD in the past, the main thing I miss in Doom Builder is the lack of layers. Having a underlying drawing of guide lines to snap onto is very useful for creating architectural layouts.

Here is the final, /idgames link: (also in the OP)

http://www.doomworld.com/idgames/?file=graphics/blank-tx.zip

Only the text file has been updated with a correct release date. Otherwise it's the same version as the 2nd one I posted, the one with 7 separate versions of the texture pack for different IWADs.

Cool stuff!