I tried hacking qbsp to make func_detail not split world polys. The result was you could shoot through the func_detail things (bullets are collision detected by doing bsp traversal of hull 0). That change must have broken the bsp tree construction somehow.

q3bsp, I think, stores all of the original map brushes in the .bsp file, and uses those for collision detection. 

What? No. no way. then decompiling would be only a matter of extracting the right lump and writing it to .map? 

q3map2 has an option for decompiling:
https://en.wikibooks.org/wiki/Q3Map2#Decompiling_into_a_.map

I checked out the code to see if it was doing anything interesting, and it's pretty much just "open the 'brushes' bsp lump, write each brush to a .map file" 

http://www.mralligator.com/q3/#Brushes
I had no idea. 

Here's a picture that shows the difference between a world brush, a func_detail, and a func_wall.

Those are 16x32 octagons placed against a flat wall.

The func_wall is in the middle. Notice how it doesn't cause the wall behind to get chopped up.

http://quaketastic.com/files/screen_shots/WallvsDetail.png 

BTW, that's in Quake.

Most of the time, a detail brush in Quake 3 will work just like a func_wall in Quake. 

quake 2 also has the brushes. This is how they are able to support collision for arbitrary sized entities, rather than using N number of "hulls", one for each bounding box size. 

guess you learn something new every day

are the brushes linked to the tree at all? how's the space searched efficiently? 

when is the best situation to use func_detail? Does it have any impact on the end user or does it only impair compile times? 

The impact on end user is a level portalized in a more rational way. Visibility will be based on walls enclosing the room, not the six uber detailed pilars or the chandelier inside it, ones you will carefully turn into func_detail. Someone correct me if I'm wrong. 

adib - No, that's right. You should func_detail anything that will create a ton of cuts and portals for no real benefit. 

As far as I know, the only reason to use func_detail is to speed up vis. If done correctly, the player will have no idea that they were used. Do it wrong and the player will see brushes start disappearing. Func_detail brushes have no effect on how qbsp chops up the brushes. 

That sounds like the issue I was having with my text shaped brushes on the one wall. 

As far as I know, the only reason to use func_detail is to speed up vis

Actually, is there a run-time benefit too? e.g. let's say you have a huge and detailed map - it's better for performance to have fewer visleaves (with more polys in them) than tons and tons of small visleaves, right? I'm guessing func_detail results in less visleaves? 

tyrutils qbsp (and I assume rebb's as well) uses knowledge of which faces are func_detail in its bsp heuristic; it will try to use non-detail faces to divide up volume in preference to detail faces.

That might give a more optimal bsp tree, but aside from that, using func_detail creates just as many visleafs as not using it, so I wouldn't expect any difference at runtime. 

1) What is the correct file format for textures? E.g. let's say I want to modify an existing texture. I know how to use TexMex to export it from a texture wad, and how to add it back in, but I'm not sure what file format I should choose when doing so (I am guessing the answer is not jpg).

2) Would Gimp be a suitable programme for modifying/creating textures?

3) I think I understand the theory behind using skip textures, but why is it possible to see skip textures (as in, see a brush face with "skip" written all over it) in some maps? Shouldn't those brush faces be invisible? An example would be Day of the Lords: if you noclip through it, there are moments where you can see "skip" written on brush faces. 

Correct file format is .pcx file

I'm sure gimp would work ok. I use paintshop pro 7.

You shouldn't be able to see skip textures, must be one of those weird quirks of the game if you can see them by noclipping through stuff. 

http://www.celephais.net/stuff/texturefaq.htm

The skip faces you see are accidental leftovers i'd say, todays compilers "skip" them ahead of the final bsp compile, were the old tools just draw them and had to be removed with a special compile switch and/or tool.

Gimp is fine, dont expect it to work wonders tho.. 

Thanks for that link; I was actually reading through that before posting to see if it would answer any of my questions (I had a look here http://quakewiki.org/wiki/Textures too).

So if I shouldn't expect too much from Gimp, what is the better alternative? (Just curious; I wouldn't be able to afford any non-free software anyway) 

I've always found Gimp and Photoshop too much of a pain to use for Quake textures. Their world is 24 bit.

I have an old copy of PSP 4.0 (still runs on Windows 7) that I use for making and modifying Quake textures. It works with 256 color palette graphics pretty well. I've always used the .bmp format.

I tried a newer version of PSP (x5), but it was way overly complicated for most of what I do, so I deleted it. 

What kind of pain you have using Photoshop to make Quake textures? You can switch between RGB and "indexed" color modes, I have the Quake palette with and without fullbright lines... Want help? 

It's worth putting time into to learn imo. There are good reasons it's an industry standard (and not so goon ones).

Of course, it can be pretty cost prohibitive, which is one of the reasons I should eat my words and learn GIMP. 

Photoshop is great for Quake textures. Make heavy use of the 'gradient map' layer, and make yourself a set of gradients that match the rows of the Quake palette to use with them. 

I use LVPro 

It's just a personal preference thing, but I find these modern graphics/photo editing programs to have have an overly complex and cluttered up interface for something as simple as editing a bitmap.

I do have a copy of Gimp in my portable folder, some day I may give it another look.