The trouble I find with 8 unit stairs is that it takes forever to elevate the player. Seriously ...

So many stairs... 

Even going up a standard Quake wall height, 128 units, = 16 stairs! 

It's personal preference really.

I sometimes use 8 units, I sometimes use 16. Depends on what I want the map to look like. 

http://imgur.com/S8j9qDh
http://imgur.com/PSZD5eU
http://imgur.com/r1m4vWa
(on phone, sorry for no album)
The design of the stairs suggests the relationship between the spaces it connects. You should use what�s appropriate for the level you�re designing 

last post is mine 

Obviously? 

Altho, those stair images were cool and I saved them. Thanks. :P 

They're from a book called Architecture: Form Space and Order by Francis DK Ching. It's ~50 AUD and serves a good introduction to a variety of architectural concepts that's really accessible to non architecture majors. Architecture touches frequently on the psychology of spaces so I feel like its a pretty useful pickup if you have the disposable income. 

That's a great book. 

There's a bunch of books called that on Amazon ... a dozen different covers and prices ranging from $12 to $60. Nice... 

http://www.amazon.com/Architecture-Francis-D-K-Ching/dp/0471752169

I personally own this. The 12 dollar prize point is amazing, considering its over 300 A4 pages of illustrations and insight. 

I know I've posted this before, but this is a very good reference to have around.

Pictorial Encyclopedia of Historic Architectural Plans, Details and Elements

Each pair of pages has twenty or so small, numbered, pen and ink sketches on the right side with a brief description on the left. Get a used copy for cheap.

http://www.amazon.com/Pictorial-Encyclopedia-Historic-Architectural-Elements/dp/0486246051/ 

Cheers man, think i'll grab myself a little extra christmas present 

those drawings on the cover of the Pictorial Encyclopedia look like they could have been pulled from the orthographic views in a level editor. and the intersecting arches look like the cramped tunnels from my vault :P 

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.