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.
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...).
About That Bug
"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)
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:
Lines drawn to highlight ugly areas:
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.
Qbsp Subdividing Wierdness
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!
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).
.BSP File (Looks awful! and I don't mean just the texturing):
P.S. The percentages have a newline for every % or something, FYI.
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 ----
Tried to compile willem's jam5 map with tyrutils, got this:
$ vis MapJam5_Warren
---- vis / TyrUtils v0.15-5-g5111c54 ----
running with 4 threads
testlevel = 4
BSP is version 29
Loaded previous state. Resuming progress...
Calculating Full Vis:
************ ERROR ************
Vismap expansion overflow
-vv probably gives more info, but it outputs a lot
how long did it take you to get there?
i used h2map to create prt file from the already compiled bsp and then vis.exe to re-vis the map. it is working so far, but it's extremely slow. at this rate it will beat castle of the dark ages vis world record...
We might want to accept that it's a terrible BSP and move on. :) I would do many things differently if I started that thing over...
no way.. it's too early to give up :-)
not long, i interrupted it often, total i would guess an hour or two. i5-3470. I went from the .map, not the existing files.
i'm at 20% after 15 hours. it reminds me recompiling travail levels for transparent water support. of course, back then i had crappy single core cpu and no multi-thread vis tool.
I'm curious as to how vis can be broken like that if - as you say in another thread - detail brushes were used extensively.