I made some new TEXTURE cleanup tools for SLADE

[illYay1337]

I was working on putting a bunch of texture packs together for a GZDoom mod and realized working with TEXTURE files is a nightmare. 

 

 

So I added some right click options to SLADE in a pull request.  Hope this goes through soon. https://github.com/sirjuddington/SLADE/pull/1313

There's already a tool to convert TEXTURE1/2 files into a ZDoom Textures file, but then it contains a bunch of iwad entries.  One of the tools filters out all iwad entries so you're left with only the textures defined in your texture pack.

A second tool removes all Textures that are built out of a basic single patch and moves the patch files to the texures folder.  This way you're left only with texture entries that are truly needed (basically if any special options exist, or if you use flats/sprites/non-patch graphics) and ZDoom can easily load your textures from the textures folder without a need for patches that are added to a texture.

 

Edited February 1, 2022 by illYay1337

[Thelokk]

Owe ya a cookie. Top tier and much needed.

[illYay1337]

I added another option to clean all unused ZDoom textures.

 

This way you can put together a giant megatexture pack that you reuse for all your projects, and once ready to release, clean up all the unused ones.

 

The vanilla Remove Unused Textures/Flats tools that exist now before my addition don't check flats on walls, or wall textures on ceilings/floors, like zdoom supports.  Also this handles reading the animdefs files to exclude animated textures from being cleaned.  It will also remove the texture/flats image files and also modify the TEXTURE lumps and zdoom TEXTURES files.

 

Edited February 12, 2022 by illYay1337

[Bauul]

Very nice work, especially with checking ANIMDEFS for extra textures.

 

If you want to create a truly thorough tool for removing unused (G)ZDoom textures, there are a few other places they could be being used:

• GLDEFs and its respective libraries
• ZSCRIPT and its respective libraries
• ACS scripts, both in the Scripts folder and in individual WAD files
• Any OBJ or MD3 models (especially OBJ models that are exported geometry from UDB).

There might be others too, but in my experience those are all the places a texture can be "used" in a GZDoom project outside of the map lumps themselves. If you exclude those from your checks, there's a chance your tool will strip out textures that are crucial parts of a project, and the user would need to manually add them back in.

[illYay1337]

Oh true, I do have a warning about it omitting checking scripts.

 

Another way around that for now is to keep those things in a separate archive and merge them together when ready to release.  This tool currently scans for all map data in the archive, and any textures in the same archive.  This includes wad files for indivdual maps, like Zdoom supports.  If you have textures and obj files in a different archive they'll be safe.  While developing, just load multiple archives at a time.

 

There is a dialog that lets you manually omit textures by name at least, and that was code I copied from the other tools.

 

SLADE doesn't currently parse a lot of those things out of the box so it's not an easy task.  Even my Animdefs support is kinda just, hey lemme find all the tokens in the file that say Pic, and the next token is most likely a texture name.  And every time I see the word texture/flat/switch/animdoor, the next token is also a texture name.  And if I see Range, assume the number at the end is the range of textures to omit.

Ideally, all of those files need to be opened and processed according to spec, and read into a full on data structure that makes it easy to work with the data.  So far, ZDoom Texture files are read this way, and some of the binary Boom anim definitions too, since binary data is very easy to load due to not needing a language parser.

Supporting those extra Zdoom format files could be work for another time, either by Sir Juddington himself, or other people in the community such as myself.  Then there are other engines like Eternity that may have their own special files and support may need to be added for that too.  His code for finding unused textures and flats just opens UDMF text files and does a light weight parse of that as well.  Maybe he doesn't feel like loading a full map file in for this operation even though SLADE has a level editor and should support UDMF fully.  That's code I haven't even delved into.

Edited February 12, 2022 by illYay1337

[illYay1337]

Oh nice, Sir Juddington is alive and well!  He just merged my pull request in and posted some new instructions for compiling on windows that should make things much easier.  Hopefully an official release will come out soon with these changes.

[ChopBlock223]

You are a superhero.

[illYay1337]

Well, it's now available in the 3.2.0 beta release.

 

I've been using the new tools to work on a huge base texture pack. https://github.com/ill/DooM_illTextureCompilation

(Never thought I'd use github for doom)

 

I basically took a a huge amount of the texture packs from Realm 667 and cleaned them up quite a bit.

 

Then when I'm ready to release a map pack I can use the remove unused textures tool.

 

I realized there's another potential optimization.  A lot of texture packs have textures built from patches stacked on top of each other.  Like a 64x128 texture that's made from the same 64x64 patch, one above the other.  I've been cleaning these up manually, but detecting and deleting the texture entry, and turning its patch into a texture, should be possible later.

Edited April 8, 2022 by illYay1337

[Gez]

You could take a look at Enjay's request, too.

[illYay1337]

Yeah and it seems like tools to find duplicate named entries would help too.

[illYay1337]

I made another update. https://github.com/sirjuddington/SLADE/pull/1391

 

This time it helps find duplicate texture names across all flats and textures defined as individual images while also cross referencing all TEXTURE files in original doom and also zdoom format.

 

Also it checks for duplicate patches across the ptable file and all patches that may be raw images in a zdoom archive.

 

This should help make sure you have no name clashes when working on a giant texture pack.  Especially when merging multiple texture packs together.

 

I also briefly looked at the GZDoom source to see how possible it may be to bring over some of that code over to SLADE to make it read all the different GZDoom language files natively in the exact way GZDoom does so you don't need some special language parsers.  It'd be especially awesome to some day have a specialized ZDoom project editor with an interface similar to Unreal/Unity with fancy tools for textures/switches/animdefs/sprites, etc...  I'd still leave the level editing to Doom Builder 2 though hands down.

 

Another tool I'm really considering adding is a way to detect textures made in the Textures files that just consist of tiled patches that result in an unnecessary texture.  There are so many texture packs where people made a texture that is 64x128 that is just the same 64x64 patch tiled one on top of the other.  Being able to detect that and remove the texture entry along with my "Delete single patch textures" tool would really help clean up texture packs.

Edited June 7, 2022 by illYay1337