GtkRadiant1.5 & Quark6.5
It is not so much the editor, it is the txbsp that report the leak.

I think it a bit strange, as in the years the editors have become better.
Lots of maps I made in '99 I can't compile anymore of this reason. 

Ok, I have a series of questions pertaining to Q3map2 and what is considered correct brushwork. I know this post might be better suited for Quake3World, but I think I need to give that a break lest I verge on pestering :/ Also, I'm pretty sure there are a number of people here that are experienced with Q3Map2.

It occurred to me recently that there may be number of things I should be doing/not doing:

1. Use caulk as the base texture then only apply art/diffuse textures to visible faces

2. Faces with non-caulk/diffuse textures should not be covered by other brushes. If this happens, cut the bush up so any non-viewable surface is caulk instead of diffuse

3. Use detail brushes more liberally. If it's not simple and doesn't have vis blocking utility make it detail. (this is a generalization and may be overall incorrect, I don't know)

So, in theory this all sounds very nice. Even in practice with simple geometry adhering to these standards is very doable. I did a small test with slightly more complex geometry to see the impact this would have on time, brush count, tri count and light maps.

Brushwork Comparison & Lightmap Comparison

"Sloppy" is simply laying down enough brushes to get the job done and disregarding the techniques listed above (aside from non-viewable surfaces being caulk). "Clean" is the result of using said techniques and is what I am currently presuming is the correct way to do things.

From my observation, these are the pros and cons of doing things "correctly":

Pros:

The lightmap more is accurate and simply prettier, particularly along the concave seam of perpendicular faces. The lightmap data itself is smaller and able to be more efficiently packed. This could be meaningful with a large map.

Cons:

Requires more brushes, which requires more time and produces more tris. I should note that I went ahead and split most faces into tris manually as the compiler wasn't spitting stuff out that was as pretty. However, the compiler might know what's better and perhaps I shouldn't meddle with it.

Ok! Questions:

1. Is the described "correct" way of doing things truly correct?

2. It's my understanding that brush count really only affects compile time, but once compiled it's irrelevant (aside from any axtra tris that may be produced).

3. If collision and sealing aren't necessary in a particular instance, is NoDraw preferred over Caulk? I ask this because I don't understand how collision works and want to avoid creating needles collision data.

4. Is a pocket of empty space surrounded by caulk brushes bad? In my test, the ceiling is flat, between the flat ceiling and the arched roof is a pocket of empty space. This could be filled with extra brushes, but is it necessary?

5. Is manually splitting faces advantageous such that it's worth the time?

6. Did this post need to be so fucking wordy? (thanks for getting this far)

Any insight would be greatly appreciated! 

brushes are used for collision - they remain relevant because of that. they won't affect render times, just tracelines/traceboxes/pointcontents/etc.

triangle counts are kinda unimportant. what matters more to vanilla q3 is vertex counts. with engines that use vbos for everything vertex counts start to become even more insignificant than triangle counts.
thanks to culling, triangle counts do still matter for cpu performance, but always much less so than the surface count.

note that you can use -patchmeta to combine multiple surfaces into one.
Its somewhat tempting to get q1bsp compilers to generate non-planar trifans rather than strict planar polygons too, but software renderers would hate it (gl wouldn't notice, although texture vectors would be a nightmare to calculate).

if you have many unique textures, you may find a benefit from atlasing them. 

The "pretty" method is basically you turning yourself into a human QBSP program. I don't see the value. 

Thanks Spike, what I understood was informative :P

My understanding of what affects rendering speeds and in what way is very weak. Looking at r_speeds doesn't do a lot for me so I just test the maps on low end hardware. I'm not sure if a core i3-3217U and its IGPU is indicative of the the low end, I should probably look at some stats on that. Anyway, that still pumps out upwards of 1.5K fps at 1366x768.

I've recently run some tests with the rain/snow system in darkplaces. Sadly, having any meaningful density results in a massive fps hit.

I plan to try some other ways to imply rain that aren't so taxing, such as having mass of pillars with each side having and alpha'd animaps of rain. Will probably look like shit, but it's worth a try. 

Try to make the rain texture animate on window glasses, so at least you don't have to simulate depht. With lighting flashes and sound behind them. 

Like water washing a skylight with rain drops hitting and making ripples.
Damn, I never make just one post. 

Indeed, that method is fine for that application. However, I'm using large, open maps in my instances. 

So what's a good place to grab cool skyboxes from? 

This could be a nice starting point -

https://t.co/XyIsslqeu6

I also made kind of a guide for it -

https://twitter.com/GavinEdgington/status/670624431459442688 

Thanks but that stuff is little too "programmer art" for what I'm looking for. Was just wondering if there was a good repository or two that all the cool kids go to. 

These are the collections I know of:

Kell's: https://www.quaddicted.com/webarchive/kell.quaddicted.com/skyboxes.html

sock's: http://simonoc.com/pages/artwork.htm

hipshot's: http://www.quake3world.com/forum/viewtopic.php?t=9242

Q3 skybox collection: http://lvlworld.com/review/id:2023

hipshot's are the most organic looking, IIRC he made them from photographs + photoshop, while the majority of the others are done in terragen. 

No problem, it can look a bit generic which is why I said 'starting point'. I think you'd have to find some stuff to put with it, like finding some planets online to photoshop onto it and blend etc (which is what I have done with mine).

I think most people tend to use these -

https://www.quaddicted.com/webarchive/kell.quaddicted.com/skyboxes.html

http://lvlworld.com/review/id:2023

http://www.quake3world.com/forum/viewtopic.php?t=9242 

Thanks, exactly what I was looking for, cheers. 

I went through all this digging through Twitter to provide Kinn with a link only to come third?

Is there a name for this? Like sloppy seconds, except thirds? 

I'm sure he has a pants remark about it. 

I just made that up 

Using Jackhammer, EricW's TyrUtils for compiling and Quakespasm engine. What's going on here? It's just a basic light set to 1000.

http://i.imgur.com/QB0LkP6.jpg?1 

The engine is loading a .lit file that doesn't match the .bsp. Easiest fix is always pass the "-lit" flag to light and always copy the .lit and .bsp to your maps directory together (or just compile inside quake/XXX/maps) 

That fixed it. 

Is there a way to force the BSP compiler to include all frames of texture animation in the BSP file, without having to create dummy brushes with the other texture frames? 

I thought that was automated now with modern day compilers ... 

I thought that was automated even with olden day compilers ... 

I know whatever I was using in 2007 required brushes with all the textures of animation to actually be in the map. That hasn't been necessary with the BSP versions I've been using the last 5 years or so. 

iirc those were treeqbsp.exe and variants. IIRC.