Thanks. and @OTP in this case I am using FraQuake to make cave walls made up of hundreds of brushes. Sounds like it may be worth the effort in this instance. I'll do a log before and after and share the results. 

Probably irrelvant in your particular example, but keep in mind skip isn't like caulk. It's really just an invisible texture that otherwise behaves just like a normal surface. You won't improve performance by putting skip on out-of-sight faces. More important than the texture used is how QBSP merges the surface.

For instance, if you have a large even wall made up of multiple brushes, all on the same plane, you can optimize the unseen faces (provided they're not removed by QBSP in which case it doesn't matter) by giving them all the same texture and all the same offset (!) - and, depending on size of the wall, upscale the texture by 2/3/4/... This is to make QBSP merge all of them into a single surface and, if the texture scale in big enough in relation to the size of the surface, it'll generate fewer polys.

Example: unlike modern compilers, back in the day QBSP wouldn't automatically optimize sky brushes, so the trick was to upscale sky textures on big outside areas or void maps in order to have each side of the sky box only be made of two polys. Otherwise it would have a lot of unncessary polys affecting the performance. 

Here's what I am up to. Judging by ad_sepulcher I should be okay in this case as you said. But good info on BSP merging. I recall reading how Levelord scaled up black void texture on HIPDM1. Now it makes sense.

https://i.imgur.com/d2TGj5Eh.jpg 

Bear in mind that a lot of tricks to reduce polycount are probably more relevant to 1996 class hardware. 

It may not have a big impact on performance nowadays, but there's still the old protocol/bsp limits. Granted, most people don't care much about these things anymore... I even upscale the texture on large triggers. :E

Another thing that comes to mind regarding that sceenshot is that, at least by the looks of it, the amount of terrain detail may be somewhat excessive for Quake. Like, how much of it is visible to the player - is it well lit or hidden in darkness, or how clearly distinguishable while playing in the first place. Not saying you should make it a flat wall, just maybe a little less 'granular' (bigger brushes)? I think it's what they call the "the ionous dilemma". 

You'll have to wait until Christmas to find out. Or until I get a decent screenshot. But most of this is viable to the player and in some cases lit fairly well. 

If I understand this correctly, I can enable phong shading on a single func_group and leave the rest of the map without phong shading:

Phong shading is enabled on a brush entity using "_phong" "1". It can be used on func_detail or func_group

However, I can't seem to do this in TrenchBroom -- when I edit the entity properties of a func_group containing worldspawn brushes, it changes the properties of all the world brushes in the map... What am I missing? 

TB groups are not the same as func_group, you want to use func_group for this. 

You add it to the func_group itself NOT the brushes within the func_group.

https://imgur.com/m33zl7R 

TB groups are not the same as func_group

Ah, I did not know this. 

so, how is the progress with the quake 2 lightmaps?

i think this is the most waited stuff for those who wants to dabble with Quake 2 Unit mapping. 

Been using the bsp, vis, & light tools. I've had significant issues crop up while mapping for Hexen 2, in all the maps I've made. Occasionally, seemingly random areas become HOM's in-game. The issue is very odd. I'll make a standard brush, often just a cube, and then the area is HOM in-game. I can delete it, and the problem will go away. But if I make another similar brush in the same place, the problem re-appears. The map is sealed (it should be, since -leaktest has been used). There are no error messages in the compilers (except for "texture skip not found", although I havent used it). It can't be the new textures, because the problem occurred when I wasn't using any. And it probably isn't a port issue because it happens in all the ones I've tested. Here are two example screenshots, with views in-game and in-editor:

https://imgur.com/a/K8F6CN7

The area in the second screenshot seems to have a separate issue from the first - there's no HOM from afar, only when you walk into the specific area. It can't be seen in the still, but the whole screen just stutters with that one frame while in the area. Also different is that no matter how I change & remove brushes in the area, the problem persists. 

Have you tried snapping vertices to grid and vertices to integer on those brushes?

Also I have seen this happen on brushes that intersect.

Not sure if this is helpful. 

Unfortunately that doesn't seem to help. I was able to fix one brush's HOM by deleting a brush next to it. But neither of them intersected, both of them were snapped to the grid, and remaking the deleted brush didn't make the problem reappear. It's so random and frustrating, it feels like it must be a glitch/bug somewhere in the process. 

Go to an older version of the tools. Might be an issue with the version you are running. 

I overcome the same phenomenon.
Not to blame the new tools, more my poor mapping skills.
I have several maps I restarted after some months and experienced rare anomilies that earlier tools just lacked to cause.

Sometimes an earlier version of the tools come out clear, while older ones causes homs and leaks. 

while the newer ones cause home and leaks. 

http://web.archive.org/web/20160929072512/http://voidspark.net:80/projects/bjptools_xt/

these tools do a great job at compiling sub-grid/float precision verts.

Maybe give them a try.

Sadly the author vanished. 

If the area is already on grid there's probably not much you can do from the mapper's side (of course even off grid shouldn't break like this); if you can post an issue on github with the .map or a reduced test case that would help fix the problem.

Alternatively trying older versions is a good idea. Maybe check 0.15.9 which was right before I did some major changes to qbsp (func_detail rewrite).
https://github.com/ericwa/ericw-tools/releases/tag/ericw-v0.15.9

I can't promise a quick fix, I'm taking a break from working on tools right now and I have a backlog of bugs piling up, but I do intend to get back to it and try to fix things at some point. 

I tried some older versions and the problems persisted. Will post an issue, thanks. 

Seems like a vis issue ...just throwing this out but maybe try -fast vis?

It is wierd how switching to txqbsp actually hsndles stuff better in a lot of cases of wierd geometry. You should still at least use ericw's vis and light...so much faster. 

Not wanting to start an argument over whats better, but I'll say that I have built some of the most absurd, overly detailed and off grid architecture and ericw's qbsp has never given me a weird error or HOM that wasn't specifically my fault. 

Random HOM like this could happen in q3 if the vis wasn't optimal, sealing or cutting sections up with hint faces could fix it. Also try increasing your engines limits; or dividing your map up so it's not rendering so much at once. 

when I qbsp-compile a(non-trivial, more than 1 room)map with a detail-brush in it, and use the cmd-switch: _forcegoodtree.
I get the error message: "C:\projects\ericw-tools\qbsp\outside.cc:97: Q_assert(p->nodes[1]->planenum == -1) failed.
#### Finished with exit status 1
"