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...). 

 

"It also fixes a pretty critical bug Lunaran noticed"
Is it possible that has anythi g to do with shadows forming along face splits in the floor, e.g. along diagonals? I've been getting wierd lighting ever since I started to have to use bsp2. (map got too big) 

re: #279

Ok, I am officially intrigued.

I am also not entirely sure now what the real downsides are with the current ugly splitting, other than it just looking nasty to someone used to nice clean meshes. Would we see potential performance benefits to changing the procedure so it splits less or avoids splits entirely, as you describe? 

do you still get those artifacts with my builds, e.g. the one in #287?

There shouldn't be artifacts from using bsp2, but you never know. If it's still happening with the last build I can take a look at the map if you want. 

It's not a bug with light, it's a bug with tyrann's bsp.exe Here's 3 pictures showing the difference between tyrann's latest qbsp and good ol txqbsp:

https://dl.dropboxusercontent.com/u/20160676/tyrann_lightingerror1.jpg

Lines drawn to highlight ugly areas:
https://dl.dropboxusercontent.com/u/20160676/tyrann_lightingerror2.jpg

https://dl.dropboxusercontent.com/u/20160676/txqbsp_beautiful.jpg

Please note that tyrann's looks the same regardless of whether I use bsp2 (all vis groups visible) or normal bsp (a couple visgroups turned off).
The txqbsp has to have the visgroups turned off since it doesn't compile for bsp2.

Any idea what's going on? 

I guess this isn't really the right thread for it. ericw's light works ok btw. 

Okay, it appears to have something to do with subdivide face. In tyrann's qbsp I'm fiddling with adjusting the -subdivide ## parameter and getting different results, usually crashes such as Alloc fails or Failed to Subdivide Face. Hopefully I can figure out what is going on and why it would differ from txqbsp's implementation. FYI, the textures in my scene are scaled at 0.50 on every wall, floor and ceiling. I wonder if that has something to do with it? 

Figured it out. Jackhammer editor breaks world texture alignment when flipping brushes with Texture Lock turned on. I found that more than half of the textures in the room in the screenshots above had their World check box unticked. Ticked them (which caused them to flip negatively on the x-axis), flipped their X-axis so they were aligned correctly again, and BAM - - perfect lighting!

Editor problem.

User problem (not understanding my editor). 

So...in conclusion, Tyrann's qbsp for some reason doesn't handle undefined face alignment (neither World nor Face checked) very well and causes poor lighting along the edges on those faces that aren't World or Face aligned when created in Jackhammer. Txqbsp handles these okay so there must be some fundamental difference in handling of Subdivide Face between the two.

Just a heads up to anyone else who has this issue when they are using Jackhammer. 

glad you narrowed it down Qmaster.
Could you post part of the .map file (or even just that one brush that gets the black stripe) just for reference? I might be able to fix qbsp if it's an each change.

Btw, rebb's modifed txqbsp is worth checking out, it's probably the best qbsp right now (handles bsp2, detail brushes): http://www.voidspark.net/projects/bjptools_xt/ 

Here you go, I copied and pasted out a small portion of my main map to create a small test map. It's pretty ugly, I retextured it with all the same texture to save time and so that you could open it in standard quake (I'm using a different palette for my game).

.MAP File:
https://dl.dropboxusercontent.com/u/20160676/lighttest.map

.BSP File (Looks awful! and I don't mean just the texturing):
https://dl.dropboxusercontent.com/u/20160676/lighttest.bsp

Compile Log:
https://dl.dropboxusercontent.com/u/20160676/lighttest_log.txt

P.S. The percentages have a newline for every % or something, FYI. 

Also, when I say undefined face alignment, I mean arbitrarily aligned: https://developer.valvesoftware.com/wiki/Texture_alignment#Arbitrary_Alignment 

I tried compiling the map, looks whatever the problem was is already fixed in my modded tyrutils, as I don't get the weird patterns that are in the bsp you posted. (The qbsp.exe in my packs has a couple of fixes from Tyrann newer than his last 0.15 release).

Could you try with both the qbsp.exe and light.exe from here? http://celephais.net/board/view_thread.php?id=60967&start=287&end=287

Excerpt from my compile log:
$ ~/dev/tyrutils/bin/qbsp -bsp2 lighttest_tyr.map
---- qbsp / TyrUtils v0.15-17-g84caccd ----
..
$ ~/dev/tyrutils/bin/light lighttest_tyr.bsp
---- light / TyrUtils v0.15-17-g84caccd ----
..