BETA 4 :D
#20 posted by DaZ on 2015/07/22 21:56:09
* Spotlight angle renamed to Spotlight direction
* Spotlight angle (sets spotlight cone in degrees)
https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd
Sorry I had no idea I sucked so bad at this :P Hopefully this will be final version!
#21 posted by JneeraZ on 2015/07/22 22:38:58
Nah, you're a hero for making this thing. It'll make Jackhammer a lot more fun to use during this jam. You've got my vote, congressmen.
#22 posted by Breezeep_ on 2015/07/23 23:58:41
Does the -lightmapscale command only work in the dev builds?
Yeah
#23 posted by ericw on 2015/07/24 00:12:14
that got cut, I guess. See the comment about lit2 in the top post.
BETA 5 :)
#24 posted by DaZ on 2015/07/25 03:11:21
* Removed setting a default for Deviance as it actually forces the light to use deviance!
https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd
This can bring your light compile to a slow crawl so be sure to update if you are using this fgd!
Texture Surface Lighting Is A Pain In The Ass To Work With.
#25 posted by Breezeep_ on 2015/07/25 04:29:42
Any advice on how to prevent it from creating too much light and containing it at a small fade scale?
Yeah
#26 posted by ericw on 2015/07/25 05:00:40
I need to put some examples on the website for doing lava surfaces.
Here's one that uses two surface lights on the lava: http://i.imgur.com/FAmAZlM.png
delay 2, light 20 for the fill light
delay 0, light 200 for the direct glow
If you use "delay 2" make sure to use low light values or you'll end up with a fullbright room.
Pew Pew
#27 posted by DaZ on 2015/07/25 05:05:16
If you are using my fgd file, download the latest version of it as it causes a bug where all point lights will be deviance lights (each light is broken up into 16 lights!)
Make sure to remove any _samples key/values from any lights you have in your level, as they will be left over even after downloading the bug fixed fgd file.
If you haven't been using that fgd file, then can suggest some settings for your surface light for lava :
wait 3
delay 2
light 100
you can tweak "wait" to have the light be smaller/larger but I've found these settings to be quite nice.
Mind Blown
#28 posted by DaZ on 2015/07/25 05:07:04
Never actually considered that you can use two lights on the same surface :O
Other Stuff
#29 posted by ericw on 2015/07/25 05:16:06
How the surface lighting works exactly: if you look at the BSP surfaces in-engine with "r_drawflat 1", each surface with a matching texture will get a light copied in the centre of the surface, 2 units above it. However, if a surface is larger than 128x128, it's subdivided into sections no larger than 128x128, and the lights are placed above those sections. So, you can think of the lights as being tiled roughly on a 128x128 grid.
My lava screenshot above is ugly, so if anyone comes up with a good example scene for lava settings that you want to put on the tool website, that would be welcome!
Personally
#30 posted by - on 2015/07/25 05:28:50
What I've found works best for lava: use really low surface lights just to fill areas (if you find it necessary), and then hand place a couple really bright lights that will do the heavy lifting and cast your major shadows in the area.
and be sure to set "_dirt" "-1" on the lava lights, you don't want dirty corners next to your lava!
#31 posted by JneeraZ on 2015/07/25 11:23:51
"Never actually considered that you can use two lights on the same surface :O "
!! Same. No idea ... neat!
Oh Shit
#32 posted by DaZ on 2015/07/25 17:09:57
You could use a 2nd light with a high offset on the lava and make it a bounce fill light.
AWWWWW YYYYEAAAAHHHH
#33 posted by ma†echa on 2015/07/28 09:38:01
hey DaZ, when I try to load your .fgd (Beta 5) in TrenchBroom I get the following error:
"Parse error at line 26, column 39: Expected token type closing bracket, or word but got colon"
Personally I'm guessing it's TB's parser, not your .fgd
Hmm
#34 posted by DaZ on 2015/07/28 18:22:42
Looking at the row/col. It's the first line of added code in the file, so I'm guessing that the version of fgd the file is written in is incompatible with TB.
This fgd was written for Jackhammer / Valve Hammer and probably uses some things that are not compatible with Trenchbroom (the colour picker comes instantly to mind).
It's worth noting that you can still use all these new features that are exposed in this fgd, you just have to add the key/value pairs manually.
It's A Bug
TB doesn't like the comments after the second colon. This is an oversight by me, I didn't read the FGD spec carefully enough, and the FGD files I had used for TB didn't contain such comments. File a bug report and attach the file so that it gets fixed, please.
#36 posted by JneeraZ on 2015/07/28 19:31:21
So I guess a temp fix would be to just delete the comments. In case that wasn't obvious. :)
But
#37 posted by DaZ on 2015/07/28 19:57:40
the comments are useful as they show up in jackhammer/hammer help screen. That's why I added them in the first place :D
But yes, you could remove all the comments and it should work.
#38 posted by JneeraZ on 2015/07/28 20:19:12
Right, I get that. But it's either wait for someone to fix Trenchbroom OR start using the FGD now. So ... choose your path, fair user. :)
#39 posted by ericw on 2015/07/28 20:22:49
The fgd won't be useful in tb1 anyway, since tb1 doesn't display the key/values part of the fgd. Will be nice in tb2 though :-)
Func_group
#40 posted by necros on 2015/07/30 05:34:23
do func_groups get ignored or something? I have a map with a func_group in it with ~4k brushes in it, but qbsp finishes in 1 second with the following:
---- LoadMapFile ----
*** WARNING 06: No info_player_deathmatch entities in level
19190 faces
4766 brushes
4 entities
2 unique texnames
38380 texinfo
Opened WAD: ..\..\QE3\gfx\jam6\mapjam666.wad
Opened WAD: ..\..\QE3\gfx\jam6\lavacity1a.wad
Opened WAD: ..\..\QE3\gfx\sock_palc_supp.wad
Processing hull 0...
Processing hull 1...
Processing hull 2...
---- WriteBSPFile ----
0 planes 0
0 vertexes 0
0 nodes 0
6 texinfo 240
0 faces 0
0 clipnodes 0
1 leafs 44
0 marksurfaces 0
0 surfedges 0
1 edges 8
2 textures 391772
lightdata 0
visdata 0
entdata 293
0.152 seconds elapsed
Peak memory usage: 13694572 (13.1M)
looks like it's skipping it?
Weird..
#41 posted by ericw on 2015/07/30 05:48:23
one idea, make sure there's at least one ordinary brush in worldspawn that's not in a func_group/func_detail. There's a bug that happens if there are no regular brushes.
#42 posted by necros on 2015/07/30 05:54:42
haha yup! thanks!
and while you're here... currently in this qbsp, mixed face contents is a full error that halts compilation, while other compilers (aguirre's in my case) will just give you a warning and convert the brush to a solid.
any chance of doing the same here? mixed face contents really isn't a big deal, at least, not enough to warrant an error.
Nice :)
#43 posted by ericw on 2015/07/30 05:59:47
re: mixed face contents, sure, I'll look into how bjptools handles it
#44 posted by JneeraZ on 2015/08/02 12:44:02
One quick suggestion ... when the user doesn't specify "-threads" maybe set the value to "# of cores in this machine" - 1. That leaves one core available for working on the level or checking email or whatever.
I found when I set up my batch file to use one fewer core than I actually have, working on maps became a lot more fluid...
|