Minor Update
#287 posted by ericw on 2015/03/06 04:34:35
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.
Nice
I think I will end up using this a lot
#289 posted by arkngt on 2015/03/06 20:47:04
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.
Arkngt
#290 posted by mfx on 2015/03/06 21:14:02
#291 posted by arkngt on 2015/03/06 23:25:19
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.
#292 posted by arkngt on 2015/03/06 23:26:03
fun to experiment around rather (I must learn that you can't edit posts here...).
Ooh Cool!
#293 posted by Qmaster on 2015/03/09 00:07:06
About That Bug
#294 posted by Qmaster on 2015/03/09 00:13:03
"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)
Spike
#295 posted by Kinn on 2015/03/09 01:45:57
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?
Qmaster
#296 posted by ericw on 2015/03/09 01:52:17
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.
Ahh...nope
#297 posted by Qmaster on 2015/03/09 04:15:22
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?
Oh, Sorry
#298 posted by Qmaster on 2015/03/09 04:20:17
I guess this isn't really the right thread for it. ericw's light works ok btw.
Qbsp Subdividing Wierdness
#299 posted by Qmaster on 2015/03/09 05:18:21
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?
GOT IT!!!
#300 posted by Qmaster on 2015/03/09 06:06:57
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).
Tyrann's Qbsp
#301 posted by Qmaster on 2015/03/09 06:15:29
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.
Cool
#302 posted by ericw on 2015/03/09 09:31:13
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/
Test Map.
#303 posted by Qmaster on 2015/03/10 04:27:51
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.
BTW
#304 posted by Qmaster on 2015/03/10 04:33:27
Thanks
#305 posted by ericw on 2015/03/10 09:09:20
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 ----
..
#306 posted by Spirit on 2015/04/22 20:58:57
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
14599 leafs
2613 clusters
8492 portals
Loaded previous state. Resuming progress...
Calculating Full Vis:
0....1....2....3....4....5....6....7....8....9....
Expanding clusters...
************ ERROR ************
Vismap expansion overflow
-vv probably gives more info, but it outputs a lot
#307 posted by jakub on 2015/04/22 21:11:57
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...
#308 posted by JneeraZ on 2015/04/22 21:15:52
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...
#309 posted by jakub on 2015/04/22 21:25:12
no way.. it's too early to give up :-)
#310 posted by Spirit on 2015/04/22 21:28:50
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.
#311 posted by jakub on 2015/04/22 21:37:01
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.
|