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. 

Oops, I've forgotten to test this with other compilers since my last post.

Now I don't remember if the one that gave me this problem was the one included in Worldcraft 1.6, the one included in Jackhammer, or the one from EricW. Anyway, good to know that this was fixed in recent compilers. 

So I have a question. Is it possible to trigger another door or item after another has been triggered?

In this case I am talking about doors, Secret once more specifically. If I shoot / hit a secret door I would like to have another door / panel slide open / trigger once the other door has opened completely. Is this possible in quake?

Thanks in advance to any map guru's