Okay, so it's possible to have multiple different style lights per texture name in addition to many light emitting textures. This is pretty cool.

Just as an experiment I lit up a rock formation inside a cave with a func_wall then removed the brush using killtarget on a trigger when the map loaded. Worked fine.

I like that the color of the light is controllable. The Quake 2 surface light color was taken from the texture which probably contributed to its reputation for garishly colored lighting. 

yeah, what happens is the surface lights are already spawning arrays of lights, then each of those lights gets another array of lights. I ran into the same thing, but when you think about it, deviance on surface lights is only necessary if it is a single light (eg: a small wall texture), but not in the case of lava.

i wonder if you could track how many lights have been spawned as part of the surface lighting and if it is over a threshold, do not apply deviance lighting. just some internal tracking, nothing added to the actual map or anything.

because you would want to use deviance lights for small 32x32 lights, for example. 

That would be nice to have. Maybe I was premature to disable combining _deviance + _surface; I could just make it print a warning. 

ericw,

I had to switch to a faster computer for building the bsp because light was getting pretty slow on my editing computer. I now get those jitterning messages I asked about in the mapping thread. First time I've seen them. Not just a few, but screen after screen of it, but it doesn't take very long to get to the progress indication and the resulting bsp is fine, I just thought you might like to know. 

from http://ericwa.github.io/tyrutils-ericw/ 

Stupid me. There's a copy of the 7/13/2015 zip sitting right there in the maps folder. I guess I downloaded the newer version but forgot to extract it, because the exe in that folder (the one I'm using) is dated 5/15/2015. 

is there a problem with reading .wads from symlinks? I can only use a single .wad file, if i try to add more than one, it will only read one of them.

although... maybe it's not related to symlinks as it happens if it is absolute or relative paths. 

So I've downloaded and extracted the tgz archive, but I don't know where to go from here (can't remember how I got the original tyrutils up and running, and I'm sure I didn't do it in the most elegant way).

Also, I'm not sure if downloading the archive was the best first step, as I'd ideally like to set it up so as to be directly update-able from github (the way I've got TB2 set up -- but I needed a hell of a lot of help in getting that up and running too, and understood virtually nothing of what I was doing!).

Could someone give me some noob-friendly instructions, or tell me where I can find them? 

I should add these to the readme. Assuming you start in your home directory,

git clone https://github.com/ericwa/tyrutils-ericw.git
cd tyrutils-ericw
make

If there are no errors this will generate ~/tyrutils-ericw/bin/qbsp, etc.

To update:

cd tyrutils-ericw
git pull
make clean
make 

That was painless :)

Am I correct that the actual programmes are now in tyrutils-ericw/bin? Do I need to cd into that directory every time I wish to compile, light, etc.?

Also, do I need to have the files I want to use (e.g. the .map file from which I want to create a .bsp) inside the tyrutils-ericw/bin directory? I ask because that was the only way I could ever get the original tyrutils to work, but I suspect there might be another way... 

the actual programmes are now in tyrutils-ericw/bin
Yup.

You can run the from another directory by using the full path to the tool, like this, if you had maps in ~/maps:
cd maps
~/tyrutils-ericw/bin/qbsp test.map

--

What I actually do is use this build script:
https://gist.github.com/ericwa/360f35c92a0139961f35

If you want to try that, save it as build.sh, update the UTILSPATH and DEST variables to match your tyrutils bin path and quake/id1/maps path, run chmod +x build.sh to make it executable, and copy it to your mapping directory.

Now you can do:
./build.sh test.map
and it will compile and copy the resulting bsp/lit to your quake/id1/maps folder. 

the actual programmes are now in tyrutils-ericw/bin
Yup.

You can run the from another directory by using the full path to the tool, like this, if you had maps in ~/maps:
cd maps
~/tyrutils-ericw/bin/qbsp test.map

--

What I actually do is use this build script:
https://gist.github.com/ericwa/360f35c92a0139961f35

If you want to try that, save it as build.sh, update the UTILSPATH and DEST variables to match your tyrutils bin path and quake/id1/maps path, run chmod +x build.sh to make it executable, and copy it to your mapping directory.

Now you can do:
./build.sh test.map
and it will compile and copy the resulting bsp/lit to your quake/id1/maps folder. 

What distribution are you on? If it's Archlinux, I could make a package for easy and system-wide installation. 

Thanks very much for the extensive response, ericw! I'll give that a shot.

Spirit, no, I'm on Mint -- but thank you for offering. 

download

Changes since 0.15.1:

* qbsp: make "mixed face contents" and "degenerate edge" non-fatal, from txqbsp-xt
* qbsp: make "-oldaxis" the default. new "-nooldaxis" flag to get the previous behaviour.
* light: add "-surflight_subdivide" flag to control amount of surface lights created
* light, vis: use below normal process priority on Windows
* light: allow negative surface light offset
* light: ensure light values in the bsp equal the average of the lit file color components. This fixes "dark" colors (where all components are < 1), on some engines (such as MarkV), which require the bsp lightmap brightness to match the .lit brightness as a cheat prevention mechanism.
* light: fix lighting of hipnotic rotating entities.
* light: fix crash in "Bad texture axes on face:"

Thanks to everyone for testing & reporting bugs :D 

 

I've run my lava map through this new lighting program about 20 times this morning and I'd have to say that the sub_divide switch has definitely helped.

There is one room with a large rectangular area of lave (320x2048) which does not get lit (well, it does but very dim). In game, r_drawflat shows this lave as one single color. I think adding some structure to break the lava surface up more will fix the problem.

I still have problems getting enough light near the lava without having it light up the entire cave, but I've got it pretty close. I'm up to wait 18 and my puny little 200 value delay 5 lava surface light still lights the the ceiling 1200 units above, but not a lot. 

The negative offset is very useful. You can sink the lava lights down below the surface and eliminate much of the spotty appearance, doesn't help much with default delay lights though. Those just basically paint the walls/shores up to a point then stop, which looks pretty bad, I've decided default delay is mostly useless for lava lights. 

I'm working on a map for Jam 6, like so many others, and in experimenting with surface lighting using the beta Tyrutils posted earlier, I've run into a problem.

As far as I can tell, 'samples' on a light entity is being used whether 'deviance' is set or not. Even in a simple box test map, making one light and setting its texture name to the floor texture, with the deviance key either unset or set to 0, I get a certain number of total lights reported. Lowering the samples value down from its default 16 to 1 reduces the total count. With the total light count being a new addition, I can't confirm whether this is new behavior or not.

I've had one other problem, where light exits with no errors after reporting "X entities, Y are lights" but before actually computing any lightmaps, but I'm still trying to find a minimal repro for that one. The deviance/samples thing is either more pressing, or just me being an idiot, so I thought I should speak up now. Am I just misunderstanding how to use these features? 

If you are using that fgd I created for JH I strongly suggest getting the latest version at https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd as an old version set _samples 16 (which is default, but doesn't need to be set by the fgd) which caused some lights to use deviance automatically.

With the new fgd this doesn't happen (but you will still need to remove the _samples key from any lights that had it assigned before you got the new fgd).

And err, if you aren't using that fgd, then ignore all of this post. YAY! 

Yes, I was indeed using an outdated version of your FGD. The new one fixes it, thanks! If I may, I'd humbly suggest the tool docs and FGD be updated to clarify the _samples description, which says "Default 16 (only used if "_deviance" is set)." I didn't understand that any value of _samples activates the feature regardless of the _deviance value.

Thanks, Wiiki! (Can you guess where my username comes from? :P)

Now I just need to figure out why the beta tools are producing maps missing some textures. I'm using ID1, lavacity1a, and mapjam666 wads, and a few textures from each are missing. Others load just fine. Switch back to 0.15.1 with no other changes and all the textures show up. Any ideas? 

...as soon as I post I realize the problem isn't exactly as I describe. It looks like the texture thing I mentioned isn't spotty, I mistook a few textures as belonging to a different set. The problem looks like two of the three wads aren't being loaded at all, with only mapjam666 (the last one listed in worldspawn's 'wad' string) being used. 

The _samples thing iirc was a bug in the tools, the description was copied directly from Eric's site! It may already be fixed in his latest version of the tools.

Making that fgd has certainly upped my appreciation for programmers, and how they make stuff compatible across different apps/versions! What a pain in the arse :D 

http://i.imgur.com/jUcJ0Jn.png

I'm not really sure why the Lighting FGD just adds these unnecessary entity keys to all the light entities in my map, and It's just tedious to remove all of these different keys. 

Are they actually in the .map file when you save it?