Thanks very much, that all makes sense. 

1) If I want to upgrade to the latest tyrutils-ericw (v0.15.9) on Linux 64 bit, can I just download the Linux64.zip archive, extract it and immediately use it? That's what I tried, and qbsp seems to work ok, but light gives me the error message
error while loading shared libraries: libembree.so.2: cannot open shared object file: No such file or directory.
There is a file called "libembree.so.2" in "tyrutils-ericw-v0.15.9-Linux/bin/", though, so I'm confused.

2) When using running light, does it matter in which order I type in the command-line options? E.g. is there a difference between
light -bounce -extra4 -dirt
and
light -dirt -bounce -extra4?
Are they both correct? Or both wrong? Do I need to give "bounce" a value? (I've tried various variations, but I find it hard to know when/if I'm doing things correctly, as I'm not sure what the in-game results are supposed to be).

3) This is not a huge problem (yet), but one brush face in a map I've been working on suddenly stopped being lit, both when running light normally and with "-dirtdebug" (which should light all faces evenly, right? That's what it's always done before when I used it). Is there a known reason for this kind of thing? Is there anything one can do to avoid it, or is it one of those mysterious things that just sometimes happens?

This is using tyrutils-ericw 0.15.8 and an outdated version of TB2 beta (the reason being that when I last tried to upgrade TB2, I seemingly had to first upgrade my then freshly installed OS, or fiddle around with repository settings to get the necessary dependencies updated to the versions required for updating TB2 -- and I didn't have the time or patience to do so. At some point I will update both). I just mention this in case this might be an issue related to the editor rather than the light tool (in which case I'll just have to live with it until I update my OS and editor). Oh, and my engine is QuakeSpasm 0.92.0. 

1. Looks like I messed up packaging the linux binary.
If you don't mind running light manually from the terminal, try "cd"-ing into the "bin" directory and run:
LD_LIBRARY_PATH=$(pwd) ./light {options here}
Otherwise, I'll fix it in the next release.

2. Order doesn't matter, except the map has to come last. There is no parameter for -bounce (there are separate flags like -bouncescale X though). Only a few commands take optional parameters (-soft can take a number like "-soft 2"). The tool should be strict if there are mistakes in the command line options, and refuse to run. For now the manual is the best reference: here, or the website front page.

3. It would just be a bug in "light". Things that have caused black faces in the past:
- bmodels (func_wall, etc.) that intersect the world
- regular world faces with an obstruction near the center of the face, within 1 unit of the surface.
I *think* I fixed all of these for the next version, I should put up a beta or release soon. Feel free to send me your map/bsp if you want me to check it out though. 

1. I didn't know there was an alternative to running it manually from terminal; that's what I always do. :) Anyway, I tested typing that arcane string of characters and it works, thanks! That'll tide me over till the next release.

2. Order doesn't matter
Thanks for clearing that up! :)

There is no parameter for -bounce
the manual is the best reference
I had already read through the manual and the stuff on the front page a few times, but was still a little confused.

The example of the front page is
-bounce -bouncescale 2
which made me think that it doesn't take any parameters.

But the manual made it seem to me as if do need to specify a value ("n"):

bounce n

Enables 1 bounce, 0=disable even if set in worldspawn. Available as a worldspawn key.

I guess I'm misinterpreting something?

3. Thanks for all of this info. The brush with the unlit face is just a regular unobstructed worldbrush, but it's good to know these things for future reference.

Thank you very much for offering to look at the map. If the problem persists, I might take you up on the offer, but a lot is bound to change in the map, so the problem might resolve itself in the mean time. Plus, the file is a huge mess of provisional brushwork, newbie mistakes, textures that have not been properly aligned yet, etc., and though I know no-one but me cares, I'm still too embarrassed to share it in its current state. 

Hi,
I noticed that color lights have different intensity than the neutral ones. https://flic.kr/p/SQKPAU In the picture all the lights have the "light" key of 150, but the attenuation and the intensity is very different.
If that's "a feature", what can I do to make them look more uniform? 

That looks like a custom engine screw-up. What engine are you using? 

When you change the color, it reduces the intensity of the colors that you don't want. If a white light has RGB color of 1, 1, 1 and you make it pure blue, the color becomes 0, 0, 1.

You could reduce the brightness 1/2 by making the color 0.5, 0.5, 0.5

I don't think the light program compensates for this and maybe it's what you are seeing. 

That's not the problem at all here. Look at the image - that's an engine thing. The light program just can't blow the lightmap brightness up like that. 

Okay, you're probably right. The picture was so dark I couldn't really see anything other than the white and blue blobs, and I was too lazy to turn the gamma up. 

White and colored lights shouldn't have vastly different intensity / falloff, and if anything white will be brighter than colored as Rick was saying.. so something is wrong here.

Is the "_color" key set on the white lights (the dim ones on the right)?

The engine's brightness/contrast controls are blowing out the colors so it's hard to tell what's going on. Also assuming that is Darkplaces, you can view the lightmap only by entering "gl_lightmaps 1" in the console. 

It's clearly amplifying the light instead of reducing.

Somehow, it seems to be adding the color to the light instead of multiplying. 

It's Darkplaces. Only the color lights have "_color" key. I'm at work right now but AFAIR I didn't use any "_deviance".

If anyone wants to check it, I could take more screenshots with higher brightness or should I mess with any other parameters?

I'll check the same settings in FitzQuake and will let you know. 

Use floats, ie values between 0 and 1.
Values greater than 1 will either oversaturate or be divided by 255, depending on implementation (welcome to the wild west).

The lighting in that screenshot actually has nothing to do with tyrlight[-ericw], because the engine you're using is basically ignoring its output and making up its own thing based on the map entities.
set r_shadow_realtime_world 0 to get it to behave properly. This'll also boost framerates significantly, so a double win...


ericw, how about a feature to ignore/strip certain lights so you can more easily set up rtlights without damaging static lights? maybe 

Loathe as I am to suggest continually adding fudges to support all the different implementations custom engines expect - on the compile side, would it make sense to always normalise 0-255 values into 0-1 values when saved to the bsp? 

I've updated my FGD file for version v0.15.9 of Ericw tools so you can now set phong on brush models and projected textures on lights.

https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd

Tested with J.A.C.K steam release 

Spike, ah, rtlights explains it. Hmm maybe a key to omit an entity from the bsp could be handy, although in this case the mapper could just use colors values in 0-1.

I kind of hate to add hacks like scaling the "_color" values in the bsp to 0-1, although I suppose it improves compatibility with darkplaces "auto-rtlights" and should be pretty safe. 

Thank you Spike! As soon as I changed the values into floats, the light got rendered nicely.

Also, when I turned off rtworld, as suggested by EricW, the rendering was pretty close to how FitzQuake does it. Although, I do have to admit it, it's a bit bland this way.

If anyone wanted to check a poor presentation of the above, go to https://flic.kr/s/aHskVVmHss. 

Got this error when working on my map, after I made a brush that was way too finely curved for its own good. Is there any solution other than just having rough edges? :( 

Csg Split it into several smaller brushes? 

More than 64 verts will crash most Quake engines, since engines also contain code that assumes that the max verts in a face is 64. Example: https://github.com/id-Software/Quake/blob/master/WinQuake/gl_warp.c#L148

So you definitely want to keep the tools error and correct your brush instead. 

Can't the BSP compiler split such brushes automatically? 

New beta:
https://github.com/ericwa/tyrutils-ericw/releases/tag/ericw-v0.15.10-beta1

Has the .map conversion feature in qbsp, so you can do:
qbsp.exe -convert valve mymap.map
and it will write out a copy of the map in Valve 220 format to mymap-valve.map. It can also convert to "quake", "quake2", "bp" (quake 3 brush primitives).

I labelled it "beta" because it's not tested enough, light has a large change to how sample points are positioned. (so unexpected black faces should never happen any more, e.g. this) 

so unexpected black faces should never happen any more  

at least one of the causes is gone. 

I think you may have added in a cause:
0.15.9
0.15.10

Also, would it be possible to turn off the bouncing for styled lights with an option? It's causing a lot of "too many lightstyles" warnings on my map.

In more positive news, converting my map seems to have gone off without a hitch! :D