As a workaround, creating a duplicate of the texture with a different name, along with a new surface light, might be the best option.

That's similar to what I did for my Jam 6 map. I used TexMex to make a custom jam666.wad specifically for that map. I had textures that were the same but with different names. One with surface light and one without. 

Heya, yeah... That workaround... It feels like I'd be adding bloat to the map (not that it's an issue with such small textures or modern machines).

I spent the last few hours looking through the code... It's a bit beyond my skills to modify it. But I think I'm slowly getting a handle on it.

At the moment the program cycles through all entities searching for the key value "_surface", not just light entities. So it's possible to play around with lights on other entities, but there is no light drop-off with these.

I suspect that this has something to do with geometry detecting as worldspawn? because the output: "Creating surface lights for texture "DOPEFISH" from template at ()" omits the origin.

I thought that I might be able to modify the function to use a name key rather than a texture name for "_surface". Or modify it to read the colour and intensity keys from the geometry (as func_detail) rather than the light entity itself.

Either way, I need sleep. I might come back to this later and have another crack at it. 

Yeah, it's true duplicating textures adds some bloat.

At the moment the program cycles through all entities searching for the key value "_surface", not just light entities
I think that's an accident.. I'm currently reworking the entity handling code (on the master branch on github) to have a clear distinction between lights, bmodel entities, and other entities.

"Creating surface lights for texture "DOPEFISH" from template at ()" omits the origin.
Hmm, that is a bug.

I thought that I might be able to modify the function to use a name key rather than a texture name for "_surface". Or modify it to read the colour and intensity keys from the geometry (as func_detail) rather than the light entity itself.
The main problem with doing anything with func_detail/group in light.exe is the information about which faces correspond to the entity doesn't exist in the .bsp. I hacked something together for supporting a few keys on func_detail/group (_minlight, _phong, _dirt) but it was pretty awkward; the keys are parsed by qbsp, values packed into an integer so they can flow through qbsp's processing and are then dumped into an auxiliary file (.texinfo) which is then parsed by light.exe.

My hunch is it's not worth jumping through all those hoops for this feature, but it could be done.

btw, another workaround worth mentioning.. there is a "-surflight_dump" flag, which writes the generated lights to a file. so you can use "_surface" lights to generate a first draft version of the map lighting, dump the generated lights to a file, delete the "_surface" lights and paste in the generated lights, and then tweak them individually. 

The bounce feature looks badarse. I have a question though - how are the bounce lights attenuated? Does the attenuation of bounce lights depend on the attenuation of the source lights? 

The bounce lighting is hardcoded to use 1/(distance^2) for now, regardless of what the source lights used.

What happens is there's a regular lighting pass, then the average light brightness / color received by each face is calculated, which is used to create lights for the bounce lighting pass.

So this means a delay 0 (linear) light uses linear falloff for its direct light, but the reflected light acts more like delay 2. Hopefully this makes sense! 

Sounds good!

Another question - I understand a single "bounce light" is generated for each face.

This sounds similar to the surface lights features. The issue I found with that was the intensity of light created depends on the density of faces on the surface - this is a problem I found particularly noticeable with large surfaces like liquids that get split in unpredictable ways.

Is the intensity of bounce lighting affected in the same way? Or are the bounce lights created taking the face area into account? 

Ah, yeah, I ran into that problem with surface lights as well, where lava was noticeably brighter around rocks that caused the face to be split up. Bounce lights shouldn't have that problem; they are scaled by face area, so the overall scene brightness should remain constant if faces are split up.

I also found hotspots (where you could see the individual lights) were a problem with "_surface" lights - especially when used on things like lava.

The bounce lighting has a hack to work around hotspots: there's a distance threshold of 128 units, where bounce lights have the same brightness within that distance. 

Ace biscuits :)

Are you planning to use those bounce light ideas to improve surface lights in that regard? 

Yeah, it's something I wanted to do! 

Been playing around with bounce and it's super cool.

Different topic...for me it seems _shadows 1 is broken now...

Link to bsps and map files:
https://drive.google.com/open?id=0B74rZcw0hvZpcmdUbnd1dndLckE

Test case is a simple func_illusionary torch holder, with _shadows 1...

temp01a.bsp, lit with tyrutils-ericw-v0.15.4-win32:
http://i.imgur.com/aFzI3HK.png

temp10b.bsp, lit with tyrutils-ericw-v0.15.5-win32:
http://i.imgur.com/nGvFizl.png

(ignore the fact that one shot has coloured light, and not the other - that was just me accidently invalidating the lit file when renaming the bsps) 

Note - it's not like shadows are disabled, in some cases, shadows are cast, but they are glitchy looking (e.g. the torch holder is actually shadowing the bit of floor at the base of the pillar, but the vertical sides of the pillar are ignored) 

will fix this..

It's related to how sample points are positioned on a face, by tracing from the face midpoint to the desired position and stopping at any obstruction. I made _shadow models obstruct this trace, which was a mistake, so it ends up sampling the light value above the torch holder for the samples that should be located under it. 

nice one :) 

Is it possible to flip / rotate the texture that a light projects? 

The 3rd param of "_project_mangle" should be the "roll" value that controls rotation.

btw re-posting from the jam thread:
I think "_project_mangle" is buggy, the docs say it expects "yaw pitch roll" like a spotlight mangle, but I think it actually wants "pitch yaw roll".
I'll fix that in the next light release to be consistent with spotlights, so it's experimental/unstable only for now.

Also I think I fixed the bmodel shadow issue, hoping to make a new release soon! 

Sorry, I'm a tard - roll totally works :} I guess I was just following the description of mangle in the readme (which said roll does nothing, so I didn't bother trying it)

However, a way of flipping the image would also be real nice (for those asymmetric stained glass window textures). 

oh and awesome news re: the shadow issue - cheers :) 

Mapping Help, Post #15623:
@dumptruck_ds I got a hack for qbsp that seems to fix the DP lighting issues in your map. Here is a test build: http://quakespasm.ericwa.com/job/tyrutils-ericw/

(I just added rounding for the bsp texture vectors, the same algorithm that is used for points - if a value is within 0.0001 of an integer, round it to that integer. It's not a proper fix but it seems to work decently well.)

Ericw, I can't find where I downloaded this test build, do you still have this?

Also, I found possibly a bug...maybe with JACK(hammer). When I compile I get a string of warnings:
line 11: Unrecognised string escape - U
line 11: Unrecognised string escape - J
line 11: Unrecognised string escape - D
line 11: Unrecognised string escape - Q

These correspond to letters in the directory path after slashes in the .map file JACK generates. For instance: "C:/Users/Josiah/Dropbox/QUAKE..." Compiler thinks they are escape characters like newline n<q/> for instance. The map still compiles, it's just annoying to have warnings. 

re: Darkplaces Lighting Fix: that stuff is in the most recent release (v0.15.5) at: http://ericwa.github.io/tyrutils-ericw/

Are you still having corrupt lightmaps in DP with this version? In my experience it only happens occasionally on faces with weird texture alignment (e.g. sheared texture). e.g. a few faces in ad_crucial.bsp from Arcane Dimensions have corrupt lightmaps in DP.

about the escape sequences warning, yeah, it's confusing... I should probably just suppress the warning for the "wad" key of worldspawn. 

there's nothing wrong with "c:/foo/bar/naff.wad".
there IS a problem with "c:\foo\bar\naff.wad" because that contains a new line and two dodgy chars.
"c:\\foo\\bar\\naff.wad" is fine of course, just ugly and specific to windows.
there's an even bigger problem with "c:\foo\bar\" because that string isn't even terminated properly. And yes, I have seen that in maps, and yes it does screw things over, and yes I hate the idea of getting the engine to do special things just because of the name of the field.
Its common enough that a terser and more specific warning would make sense, but I'd personally prefer if everyone just started using string markup consistently instead of varying depending on arbitrary field names.
Idealism can suck sometimes. 

I had a quick look at the winquake source.. these are my 2 cents:

- Double-quote characters can't be escaped, whatsoever (COM_Parse). Winquake, DP, FTE all fail with parse errors if a trigger_once's "message" string is "foo\"bar"

- The only escape sequence recognized by vanilla is \n, which gets converted to a newline character. (ED_NewString). Otherwise, the backslash and next character are left as-is.


Writing paths like "wad" "c:\foo\bar\naff.wad" would only be dodgy if the engine/gamecode needed to use them. Everyone uses forward-slashes for paths meant to be read by the engine/QC though ("noise" "sounds/nnnn.wav", etc.)

"wad" "c:\foo\" is not a problem because double quotes can't be escaped. A trigger_once with "message" "foo\" works fine in winquake, DP, and FTE (though FTE centerprints foo" instead of foo\ )

What would be a real problem is a wad path with double quotes in the directory/filename.. apparently that is forbidden on Windows, but OS X seems to permit it. Anyway, if anyone tries that, qbsp would fail to parse the .map file. 

How about making the compiler replace the backslash character with a forward slash, in the "wad" field only? 

I always wondered why it couldn't just check the relative Quake path for any wads or just require that the wads be located in a specific folder. 

enginewise, the biggest issue is that saved games and maps share parsing code. So double-quotes, new lines, carrage returns, and double-backslashes need to be saved, and thus also need to be reloaded. Otherwise mods will break - or at least mods designed for engines that can actually do string manipulation, anyway.

Whether that's consistent with winquake is somewhat irrelevant from my perspective - as you say, the only place backslashes would ever really be used in a map is in the wad key, or before an 'n'.
I'm personally okay with FTE breaking compat from winquake to ensure saved games work, so long as embedded chars are rare and don't corrupt other strings.

small correction:
FTE's entity parsing is actually performed by qclib's misleadingly named QCC_COM_Parse - which includes consistent escapes and a special hack for "c:\foo\"<NEWLINE> in an attempt to prevent the map from being unusable.
This is why you get foo" instead of foo\ - because FTE saw an escaped double-quote.

The wad field *IS* parsed by engines in the case of halflife bsps, where named wad files may be required for external textures. The paths are ignored (absolute paths are a definite no in something that has been shipped/released), but if they arn't escaped properly then wads starting with an n will still get messed up (clients with download mechanisms might also attempt to download such wads from servers). Additionally, fte can load .maps directly, although wad handling there is curently kinda screwed up thanks to replacement images overriding things and confusing sizes.

@mankrip, really its the editors that should be doing that, especially for relative paths which would allow such maps to still be compiled/loaded on linux/mac as well as windows.
Obviously absolute paths are problematic regardless.

@Rick, some -basedir argument for qbsp?.. and probably -game too... 

@mankrip, really its the editors that should be doing that

I agree that fixing this in the editors would help for when creating new maps, but for compiling old maps it wouldn't, specially if the user wants to compile some old maps directly from the commandline.

The Quaddicted database has tons of maps with source available, and sometimes it's useful to recompile them without modifications, when all the user wants is to compile them in a different way (e.g. enabling translucent liquids or lit water).

So, an ideal solution would be to fix this both in the editors and in the compiler - fixed editors would ensure that the maps can be compiled by any compiler, and fixed compilers would accept maps from any editor.