func_detail entities should help. As for optimizing the map itself ... is it actually slow? It's hard to make a machine run slow with Quake these days. 

It's hard to make a machine run slow with Quake these days.

It really isn't. 

Is there a way to add up 2 .lit files?

I've been playing around with Q1Rad a little and I like the area lights and indirect shadowing it gives.

I've got a light_environment for the sky and light emitting slime as ambient lightsources but I wonder if these can combined with lightmaps from Bengt's light tool for the pointlights?
I like the idea of having bounced area lights to supplement the crisper lighting from pointlights. 

maybe it's my machine? I find I have to tweak settings a bit on some of the newer custom maps. I've started using RMQ as my main engine a lot of the time because it usually always gives me a solid framerate (plus I love them coloured coronas) 

Not that I aware of. Lit files only hold colour data, btw.

think it might he cool to bring back radiosity lighting for quake, but in a more controlled and sutble way... 

It really isn't.
Maybe you need a better machine. :) I have yet to see a Quake level that gets my machine above "bored". 

Maybe you need a better machine. :)

You try playtesting somebody's 100+ monsters map without a fullvis and come back. But eat a bowl of dicks with deqer first. 

That may as well be just luck. Some Quake engines are not as optimized as others, and then performance depends completely on the driver. For example, I got severe slowdowns on my 2012 iMac before I patched QuakeSpasm to use a different texture and lightmap format. 

Wasn't trying to offend, otp, just fooling around. My machine IS a beast though. 

The Quake engine scales differently than modern game engines. So a large map can indeed make even a fast computer choke. Like Sleepy says, some ports handle it better than others (RMQ and DirectQ come to mind). For example, the unvised version of Tronyn's latest map ran quite poorly on my machine, at least initially, and it's by no means a slow computer.

And this is only about polys. If you take additional features into account, replacement graphics and real-time lighting, it's actually fairly easy to make the game run slow. 

I'm not aware of any distinct guides. There's always room for optimization. Func_detail won't help here, it only makes the vis complete faster. It's sometimes possible to bring down the wpoly count by turning certain things into func_walls and illusionaries or move touching brushes apart. This requires experimenting, however, as it can well turn out to be counterproductive. Check the map with r_showtris and r_drawflat to search for and investigate locations where unnecessary brush face splitting can be avoided. 

part of the problem is due to Deck being simply a big atrium, plus the detail I've put into it also.

I can't seem to get r_drawflat to work, I think it's due to there still being a giant hole where I haven't made the ceiling work.

Am I supposed to use skip textures on the void-facing polys? (haven't done that yet either if you are) 

Void facing "Polys" (I assume that you mean the faces of brushes that are touching the void here) are ignored however putting a skip texture on them would probably confuse the bejesus out of any bsp compiler.

You might be able to make a big "Curtain" of additional skip brushes that occlude the faces facing inwards. I don't know if that's going to help or hurt you though. 

Once you fill that hole, the compiler will automatically remove all void-facing ploys. This will cut your r_speeds in half, probably. So basically you can't accurately gauge performance until the hole is filled. 

skip on 'void facing' polys will not cause problems, but it unnecessary from a technical standpoint. (some people do that because it's clearer to look at).
The reason is that the compiler completely removes all faces on the outside of the map before the skip removal process runs. 

That makes sense. I wasn't aware of the order of the steps that qbsp does things. I do know that with other "Special" textures that mixing some of them with others on the same brush can be a bad idea. I was just extrapolating from that. 

skip was actually added into the whole compilation process much later on. it's a separate utility that runs after qbsp. 

I've only messed with it once so I'm pretty clueless on using hint and skip outside of knowing what it does in a very basic sense. I was fiddling around with it and made a Quake shadow like you can see in e1m3 (I think) using nothing but a skip texture and func_detail. The func detail made the shadow and then the skip texture made the brushes that cast the shadow invisible.

The latest tools (Tyranns anyway) have skip support built into them so no need for a separate step. 

I'm at the point now where I'm making the level air-tight so I can start testing some stuff (it's not 100% yet but it IS around 99% complete in terms of geometry).

The compiling error I get is in the pastebin -

http://pastebin.com/ZdU0diLA

The only problem is when I look up the the co-ordinates of the error message it's actually pointing to a light entity and not a brush!?

Can lights cause leaks?? 

QBSP doesn't pinpoint the leak precisely, only the point entity closest to it. You can load the pointfile (.pts) in TB or put it in the maps dir and type pointfile in the console, both of which will display a line that leads from that entity to the leak (=where it goes outside the map).

Note that a "leak" doesn't always have to be a hole in the brushwork, it can also be caused by point ents that are placed on the outside. 

Well, I've got some wondrous screenshots here...

http://i48.tinypic.com/27ypkiq.jpg - showtris 0

http://i47.tinypic.com/28ksdns.jpg - showtris 1


I looked at the pointfile and I ran around the map looking for some clue, nothing. Then I typed r_showtris 1 and I found a massive line that is so far away from my actual map that when I try to fly towards it I get "teleported" back to where I started.

I thought maybe the entity was so far away that I would never find it, so I created a selection brush around the whole map and "locked" it, then did a ctrl + a & delete to see if I could delete it that way, no luck though...

Any ideas? 

Which lightmap/texture format was the problem and which one did you patch it to use? 

And I patched it to use GL_BGRA. GL_RGBA is fine, too. 

That's likely a microleak. It's a tiny rift between two brushes that only qbsp can see. This is a result of TB being shit - sorry. I'm working on a fix for such problems. 

Select the brushes where the line passes through and snap their vertices. That might fix the problem. Also note that you can import the point file into TB. See the docs.