Both options can provide a pretty significantly different look. Bounce lighting is one that I personally see as almost always desirable, with the exception that it makes it quite difficult to have stark contrasts in your lighting (which you may or may not want to have depending on specific situations) due to the fact that light will, well, bounce! I can't think of a situation where it's made a map look bad, but by no means is it necessary to use if you want your map to look good.

Dirtmapping, in my mind, is a bit more subjective. It certainly helps to add a "look" to your map, although depending on how you tweak the values that can either be very intense or very minor. It's certainly not appropriate for all situations, but taken in moderation I think that it's generally useful.

I think the same really goes for a lot of the modification's ericw has made; yes, they do have a distinct look that changes how the final product uses, but it's generally a tasteful, inoffensive change that most people would take as being an improvement. I mean, compared to coloured lighting (especially when ported back into older maps i.e. the original game) it's pretty harmless, and we've learned to live with the existence of that technology...

Anyway, I'm not exactly prolific enough to have a "default" for my maps, since I have about... 3 to my name, none released, but so far I've always used bounce and dirt with varying settings in my creations. 

I haven't tested it in a while but I believe you can use lights with negative brightness to combat the horrors of bounce lighting (even though it saves time putting in fill lights). 

ericw: would it be possible to compensate for lightmap seams as described in this paper?

One of those "would be nice" features. 

I tried 0.15.8 a bit tonight. There seems to be problems with lights inside sky brushes or something. Or maybe a problem with very low values for light?

Here's one that seems to have just disappeared.

BJ/MH Light

http://quaketastic.com/files/screen_shots/wish13_i.jpg

0.15.8 Light

http://quaketastic.com/files/screen_shots/wish13_i_2.jpg

That light shining through the window is in a sky brush, but just barely. It's almost in the void. The values are light 75 delay 5 wait .02 and the range is set to 1.0 on the command line.

I saw other differences, but that's the most obvious. 

Thanks; I didn't realize regular light entities were supposed to pass though sky faces. Should be an easy fix. 

The thing is, most of them still did. The only one I noticed that didn't was the one in those screenshots. That's why it stood out. Is it possible it got "nudged" into the void?

On the good side, about 10 of the 30 or so lights it found "in solid" actually were old misplaced lights.

Also to note, there was no reduction in marksurfaces using -forcegoodtree. The number actually went up a bit. Using txqbsp_xt always gives a drop of around 1200 or so. 

Download here

Changes:

- light: fix black fringes on bmodels that are touching against the world
- light: light passing through glass lights up the back side
- light: bmodels with "_alpha" < 1 and "_shadow" "1" set cast tinted shadows
- qbsp: support Quake 3 "Brush Primitives" .MAP format
- qbsp: save "_mincolor" for func_detail/group to the .texinfo file, now used by light
- qbsp: performance improvements


To elaborate on the "fix black fringes on bmodels" thing, v0.15.8 had a pretty severe bug where every func_door (or any bmodel) would have black edges wherever it touched the world, like an ugly/broken looking version of AO.

The reason I broke that in v0.15.8 was, I was trying to fix another bug, where bmodels (func_wall, etc.) that intersect the world, or have a face touching the world, would have broken lighting (usually all-black faces). Typical case where this would happen would be a large func_wall window that has a world brush slicing through it (or just touching the front).

So, that bug is back, because the "fix" I tried was much worse (black fringes on all bmodels). If you have a func_wall with black faces / broken lighting, the fix is to manually clip it against the world so it doesn't stick into the world anywhere. I'll see if I can come up with a better fix next version 

That's great to hear, I encountered the black fringe issue before and it is good to know it may be fixed on this release! 

Would it be possible to hit both bugs by having the compiler test if the bmodel intersects or not? Or would that require multiple passes or something like that? (Assuming extra passes would suck, which when it comes to speed they probably would :/) 

Performance improvements - intrigued, my latest maps have been bottlenecked by Qbsp which is wierd since vis always took the longest until recent improved versions. Curious what improvements you've made. 

@Qmaster - performance improvements are from undoing some mistakes I made when C++-izing bits of qbsp (unnecessary std::map lookups). Qbsp could be made a lot faster, though. e.g. Quake 2's is multithreaded.

Pritchard, I'm not sure if knowing if the bmodel intersected the world would help. I think I need to do something like: test whether each sample point is in the void or not, and just not use the ones that are in the void. 

How do you do lit liquids? I tried the commandline flags people are talking about here (-litturb etc.) and it just gives an error and doesn't run light. Was it removed or something? 

-splitturb option for qbsp.exe should do it; light.exe will automatically detect this and save lightmaps for the water. Looks like that option is missing from the docs.

Engine support is fairly rare (?) - I don't know what supports it, off hand. 

So I can "bake" lightmap on the water and it will be still fullbright in some engines, or what?

Yes. There is that one software render engine that mankrip is doing that supports it I think. That's the only one I am aware of.

However, give other engine authors a slap and a tickle in the right place and I'm sure this feature can be adopted elsewhere (it bloomin well should be because it's coolbeans) 

I just checked my Jam 7 map to be sure I was remembering correctly, and Darkplaces supports lit water too, at least version 15:49:13 May 13 2014. Incidentally, I discovered the final version of my map is apparently broken in that engine for a different reason, which is just fantastic, but the lit water works as expected. It's easier to see the effect with r_wateralpha 1, of course. 

All this talk of lightstyles in the AD thread got me thinking...

Say you had a moving object with start and end positions in radically different lighting conditions.

Imagine you could tell the light tool to light this object in position 1, assigning all light on it to lightstyle "x", and then light it again in position 2, assigning the light to style "y".

Then in the QuakeC you could fade lightstyles x and y in and out as the object moved.

Just an idea, but it struck me as interesting that this sort of cheap dynamic light effect boils down to being a compiler thing + a bit of QC.

You could even go nuts and leverage the fact you can have up to 4 lightstyles on the object, so can specify up to 4 different positions to light it in, allowing much more accuracy in the blending as the object moves around.

I may be missing a few "gotchas" but, does the theory sound basically correct? 

there are only 64 lightstyles total, and 32 of them are used by light.exe for switchable lights, the other 32 for "styled" lights (flickering/pulsing) -- of which about 11 are actually used in id1 progs. So I think this would work if you were willing to dedicate 2-4 styles just for that one moving object, and write a quakec modification as necessary to do the proper fading. 

I guess it would be something that could become an attractive idea when you have situations like in Hrimfaxi's rrp map, where there is a large section of a big room that moves up through several floors.

Wouldn't be worth it for run-of-the-mill platforms and what not, but for big setpiece movers I can see it having the potential to look quite sexy. 

There are 64 lightstyles, but Quake's BSP format only supports 4 different styles per surface.

IMHO, a more practical solution would be to use the "Lit BSP models" feature from the Makaqu engine 1.6 (used to adjust the brightness of the ammo boxes to the ambient lighting) and add an option to make it also work on internal BSP submodels. 

I only suggest the idea because it struck me as interesting that it doesn't need a custom engine.

I'd be happy to use up a handful of lightstyles on a moving room setpiece.

How is the "ambient lighting" determined in Makaqu? 

I think the challenge is working out a standard between the mapper, light.exe, and the QC. light needs to have a copy of the logic for the func_door/train or whatever is moving. Func_door would be pretty easy, func_train would be trickier (unless the mapper marks which path_corner's to calculate lighting at, up to 4 per train?).

Also, things like making sunlight/sunlight2 use a lightstyle other than the default of 0 are certainly possible without too much work in the light tool. Easiest way might be for the mapper to specify a lightstyle number with a worldpawn key like "_sunlight_style" - light would then use that for the sunlight, and know not to assign that style number for a switchable light. 

I guess one implementation could be...

I would suggest light.exe should not need to know how the object moves - it only needs to know the positions to light it at - these could be specified in the map with "info_lightmodel" entities - they would mark the various positions (mins?) of the brushmodel. The info_lightmodel would target the brushmodel (to let light.exe know what to light, obviously), and also specify the "style" number to use. 

your sunlight suggestion is cool.

Question: what happens with bounce light coming off a surface with styled lights? Is there a bounce for each style? 

Mmm - yes the info_lightmodel sounds good.

Currently styled lights don't bounce at all, this was something I limited to make the first version of the code simpler, but I want to support it eventually.