Many of my maps have taken double that (like 20 mins) in the past.

Plumbers Dont Wear Ties is a detailed map, but not too detailed, but also its not really that big. Its a realistic scale, and its condensed, but its not very big compared to say the Warp maps or Marcher Fortress. Load Bengts engine and load the Plumbers map and type into the console "lightmaps" and try it with your own map too. Lightmaps are if you like "X amount of texture worth of light info", so the bigger the map (so long as the texture scale is 1:1) the more lightmaps.
Also if you have plenty detail in your map that wont help the speed (but it will make the map look sexier :).

I wouldnt worry about it too much! 

I probably should have mentioned I used a Core2Duo e6850 (2x 3.0 GHz) with 2 GB RAM.

I wasn't worried really, it just seemed like 25 secs was way low for a map like that. I ran id's e3m1 this morning with the same settings as I used for my map and it took 2 mins 14 secs.

Anyway, I'm still curious how other people light their maps. 

this is my understanding of the issue...

When you have multiple lights with inverse falloffs hitting the same surfaces over a long distance, the light time tends to go up. With inverse and inverse square falloffs, the light level never completely hits zero, so if a light using those formulas is in a wide open area, all the surfaces within line of sight of that light have to be calculated, even if the light level only increases infitesimally.

APSP2 was a fairly narrow and cramped map, so while it was detailed, none of the lights had to cast very far.

The extra 4x4 sampling and soft stuff increases the time as well. But thankfully, light calculation time is not painfully exponential like vis, it seems to increase fairly linearly. 

Rick: are you sure Than didn't say 25 minutes? to me, that would seem more realistic for a map of that size with the amount of lights present. but maybe he just has a monster machine...

grahf: aguirRe and i had a discussion about this kind of phenomenon with inverse square lights. mostly it was regarding how using that delay type with switchable lights could quickly run up to the max lightstyles on a face warning.
he implemented the 'fade gate' command line. essentially, it will cut the light off once it's light level has been attenuated below a cutoff point.

setting -gate 1 on aguirRe's light util will cut down on lighting times by a large margin because it's disregarding a lot of lighting that wouldn't even be seen.

back to Rick: as for light utils and settings, for preview compiles, i use:
light -gate 1.0 -fast -soft
and final compiles is:
light -gate 1.0 -soft -extra
i don't use extra4 though, because that is just insane and will take millennia to compile. aguirRe recommends -fast -soft -extra4, but i haven't tried that yet.
it's really worth your time to look through all the info aguirRe has on how to use his tools: http://user.tninet.se/~xir870k/readmevis.txt the lighting tool has a huge amount of options in there. 

Yeah, extra4 basically takes about 10x as long on my maps, so for a quick look I don't use it, with just -soft it'll light in about one minute.

I did read through all that documentation and it was very helpful, I've been experimenting with a lot of the new stuff.

I wasn't real clear on the Gate thing, but now I think I understand it. I'm also not certain exactly how the -softdist is supposed to be used, but it seems like I get a lot fewer of those abnormally dark faces when I use that option. The documentation (I think)indicated using small numbers like 3 or 4, but I've been using -softdist 16 

i guess it's impossible to change the player model's angle without having to use fixangle = 1 (thus changing the angle the player is looking?

it seems i will have to replace the player with an invisible sprite and then make a dummy model that follows the player's position in order for me to get the results i want? 

but you probably need to use an .mdl, otherwise there might be engine issues (i know the weaponmodel expects to be a mdl, not sure about playermodel) 

i got it working with a sprite so seems everything's ok.

btw, your chase camera is kind of wonky and is prone to being shaky at times. it seems to pick up on stairs and angled floors in front of the player, where the crosshair is pointing or something. just fyi :)
i've also noticed a bug with the camera where, if you are looking down, and the camera is higher than the player, and you enter into a tunnel where the ceiling is lower than where your camera is, the camera goes psycho and starts moving in huge arcs outside the map. (this is with chase_up set at 32, which is higher than the default) 

yeah, it kind of sucks. I sort of stopped trying to fix it once i realized it's pretty much a gimmick and Quake is better in first-person mode anyway :) 

Cannot compile in GTKRadiant 1.5 for Quake. Anyone know how to fix this for GTKRadiant 1.5? 

Try the "search on this page" option while vieuwing all posts of this thread upwards with the word GTKRadiant. 

but helpfull. 

just looking around at the quake sources.......

how the fuck did they get any of that to even compile? o.0 

I know it's easy to point and laugh at the original Quake maps but those guys built some pretty cool levels with technology that was changing on a daily basis. That's tough to do. 

Not to mention the primitive tools. QuakeEd was ... pretty rough. 

i'm not laughing. i'm serious. the original qbsp was incredibly finicky which is what taught me to map with incredible precision making sure everything lined up properly etc etc.
looking at maps like e2m2, it's almost like divine luck or arcane power that would have allowed it to compile without exploding. 

But when you look at it you can see that they're at the minimum level of compilability.

Which means each of those maps must have undergone loads of iterations to reach that level, probably starting with something resembling Escher vomit.

Like Willem says, after ten years of trial and error with bsp it's impossible to make a comparison. 

I constructed a terrain map with triangles.
After fitting all polyhedrons well tight the light seem to cast all kind of rare shadows.

Is there a way to avoid this odd behaviour? 

depends.

if you're using aguirRe's light
i found -soft will make these shadows a lot. even if the faces are perfectly connected. obviously, not using -soft is a solution, but not a good one. if this is a preview compile, and you have -soft and -fast, usually not doing -fast will reduce it.

it's always there though, afaik. smooth transitions of angles like terrain don't seem to go over well with any of the quake tools. :P 

one thing, you can try using _anglesense 0.1 on lights hitting the terrain (and _anglesense on your worldspawn for sunlight). setting angle sensitivity way down like that will make light not attenuate much on different angles. this makes it look very shitty and weird (faces not really facing the light will still be bright as if they are directly facing it) though, so it may not be a viable solution (i haven't tried it) 

I made a polyhedron from a cube and cut of a pyramide on top.
After some punctual accurasy it can be used for terrain maps.
Point is that after placing it on grid and changing the topangles also replaces the cube foot after forcing it to grid.
So if I don't force to grid the lightning looks well.
After forcing it to grid the slopes cause black shadows.

I will try your light options. 

anglesense either, but according to AguirRe it will give a softer, more diffuse lighting effect.

shadows on triangle geometry are always a problem - AFAIK they cannot be solved 100% - but I've never had the problem. So far. 

My map compiles with no issues, but when i goto open it with my client i get an error of "too many static entities" any ideas of what this means? 

Not to state the obvious, but you've gone over the static entity limit for Quake. You'll either have to reduce the number of static entities in the map or play it on an engine that has a higher limit... 

whats the limit then? I'm running ezQuake as a client... I've looked around and most sources said its a limit of 128 is that true? then i noticed a post by rick earlier and by reading his post it said that he has 625 light in his map... how is this possible i think mine is 172 if im not mistaken...