@mh
Just thread it? 

Nice idea for software but in GL it all happens in glTexSubImage2D. 

Sorry for noob question, but I saw some comments in the Beyond Belief in one map thread that made me wonder if I can add AO to maps by recompiling them with TyrLite? I saw some AO screenshots and it looked really nice. In short, can I recompile the vanilla game's bsp's (and other ones as well of course) and get those nifty effects - or is it more involved than that? 

Nope, it really is that easy. Extract bsp from pak, relight with -dirtwhatever, play and ogle.

Should distribute a batch file that does all the stock maps. end.bsp might even look half decent. 

When you have a chance to play with it, curious how the _sunlight2 in the latest build compares to what you were doing!
The actual sun positionong I took from the "skylight" feature in q3map2 

i redid the quake maps but found dirt mapping isn't as awesome in those as you would think.

the real benefit comes from outdoor areas that use the modern _sunlight method because that yields completely flat light on its own, and the dirt mapping comes in and makes it awesome.

id had done all their lighting with point lights which already gives a bit of a dirt mapping look.

so yeah, dirt mapping does improve the lighting in oldschool lit maps, but the real benefits will be maps that relied a little too much on minlight or had big outdoor _sunlight areas. 

eric, will test, recovering form hard drive replacement 

eric, will test, recovering form hard drive replacement minor surgery. 

Get well soon! :-) 

Cool, thanks! 

I may be talking out of my arse here, because I don't know the tools code very well, but I was thinking....

You know how face splits due to fiddly details (thin bars, steps, walltorch holders etc.) can often cut across lots of geometry, and it sucks?

I was wondering - if it was possible to influence the order in which faces get split, could it improve the situation?

To wit - imagine a key which you could put on a func_detail (or func_group) - i.e. "_split_priority" or something - then bsp uses this to order the way faces get split so you can constrain fiddly details to splitting just the immediately adjacent faces by making them func_ and giving them a lower split priority. You could even have more than one func_ butting into each other, and use different _split_priority on them to really micro-manage the order of splitting.

Caveat - just the rumblings of someone who doesn't know much about quake's BSP algorithm, but does any of this sound interesting / make sense? 

faces do not define leafs, thus in theory, it should be possible to just omit the splits entirely (maybe revert to the original surface if it got split in too many ways without being disjointed, but still clip it to any outer-edge planes of the fragments).
this would result in more overdraw (without randomly spewing into walls too much), but software rendering is supposed to be zero-overdraw anyway, while hardware renderers should be fast enough to not care.
the catch is that it would take more edges, but at least you wouldn't feel like you had to spend all your time building the bsp tree by hand only for it to mess up again when you change something. 

Sorry for another noob question, but how do I actually run TyrLite? I've used PAK Explorer to extract a bsp, but then I'm stumped. Well, I guess I must run a command line, telling it to execute light.exe and then adding lines pointing to the bsp and detailing what to do, but I don't find any info in the readmes on how to do it. And it didn't help much to google command line utilities either. In short, is there "run a command line utility for dummies" or some such guide? 

Sure, just put light.exe and the map you want to light (say e1m1.bsp) in a folder like c:\\mapping.
Launch the windows command prompt, cmd. (iirc, start->run, then enter cmd.exe, or search for "cmd" at the windows 8 start screen)
Type:

cd c:\\mapping
light.exe -dirt e1m1.bsp
 

those double slashes should just be one slash 

cd:\\\\\\\\\mapping\\\\\light.exe \\\\\ 

to relight all maps this way:
- make a folder: c:/maps
- extract all the maps into this folder
- put light.exe into this folder
- open notepad and paste this into it:
for %%A in (*.bsp) do light -threads 4 -extra4 -dirty -dirtmode 1 -dirtdepth 160 -dirtscale 2.1 -dirtgain 0.7 %%A
- save text file as run.bat

double click run.bat

also try fiddling with the numbers like -dirtdepth and -dirtscale. i think they are set really high because I was testing stuff. now my maps are really dark and I'm too lazy to try to fix it. 

uh, put run.bat in the same folder, btw 

woooooooo.... made a folder called "dirty" with all the dirty stuff added. 

osx win src

Only one change, key/value "_dirt" "-1" is supported on brush model entities (func_door, etc), this disables dirtmapping on that bmodel. Useful in combination with bmodel-specific "_minlight" if you have a door that touches or sticks into the world, and you want to prevent those parts from turning black from the AO. 

I think I will end up using this a lot 

Thanks, guys. When running the run.bat as described in necros' post, light.log says:

Unknown option "-dirty"

I tried with -dirt as well but then I get:

Unknown option "-dirt"

Otherwise, it seems to run and the .bsp's get resaved. I'll check it out ingame. 

http://celephais.net/board/view_thread.php?id=60967&start=287&end=287

try these. 

Thanks, mfx, I misunderstood the post previously. Yes, now it works and it's a noticeable difference as well. And I agree with necros - it's a bit too dark IMO. But it will be fun experiment around with the settings now that I got it running. 

fun to experiment around rather (I must learn that you can't edit posts here...).