It works flawlessly, way better than my implementation.

I've noticed -fence was removed, but that's not a big problem for me.

I'll try out making some smooth shaded lit liquids now. 

glad the lit water works :-)

-fence I removed because it was done in a hacky way. I understand the trace code better now so can re-add it if anyone wants it. 

 

Those screenshots are gorgeous! 

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

New features:

- light: added a better options summary with the -help flag
- light: added -bounce option, "_phong", "_project_texture" key
- light: use vis data to accelerate lighting
- light: "_minlight_exclude" key to exclude a texture from receiving minlight
- light: add "_sun2" "_sun2_color" "_sun2_mangle" which creates a second sun
(unrelated to "_sunlight2" which is the sky dome light)
- vis: support .prt files written by bjptools-xt
- qbsp: add -objexport flag

Bugfixes:

- vis: fix ambient sounds when using func_detail, broken in tyrutils-ericw-v0.15.3 

Hi, I hope I don't come across as an idiot for asking this, but what exactly am I doing wrong to get this result?

http://puu.sh/pvLvr/f08175b526.jpg

Ignore the missing textures, but how do I fix my strange lighting on the map? I'm not running with any command line options, just the map bsp.

Thanks for any help! 

it's hard to tell from that shot if it's a corrupt file, or something else.
Check for any stale .lit files and delete them.

Might be easiest to just post the .map+.bsp. 

Thanks for the suggestion about the .lit file, I found one and deleted it and now everything is working fine! :D 

I tried the latest compiler tyrutils-ericw-v0.15.5-win32, but it glitches off.

I'm just an old time user, winxp etc but version
tyrutils-ericw-v0.15.4-win32 goes great.

No bad word here for the harworking improvements,
more a shout from an old map compiler. 

This is an easy check engine-side and mismatches like this will never happen. Just check if com_filesize is equal to (l->filelen * 3) + 8; if so the LIT file is good, if not it's invalid and you can display a developer warning. 

I changed compilers, will look into it. What is your CPU btw? 

yes good point! engines should really detect + print warnings + refuse to load invalid lit's. 

I think I fixed the problem, mind checking if this build works for you on XP? 

I checked a rather big map I converted from Sin.

When I use the TreeqQbsp v2.03 it compiles.
The newer version compile faster, but end up with a leak after bsp compiling.

Of course it can be my lame '06. 

Use TreeQbsp if that works, or I'd recommend using rebb's version of BJP qbsp/vis: http://www.voidspark.net/projects/bjptools_xt/

The main thing in my tools is light.exe which has lots of new options. 

Hey EricW,

Forgive me if this functionality already exists, but I thought of something that would help with lighting control.

Is it possible that a func_wall, func_detail or func_group be given a surface light flag for individual surface light control?

The current setup (using the light entity) lights up each instance of the "_surface" defined texture, however there are times that I don't want every instance of that texture lit or times that I want different colours or intensities on said textures.

Cheers. 

Hmm.. I can see that would be useful, but I'm not sure if can be done easily.

The surface light template (the light entity with "_surface" "xxx") can use any keys allowed on lights, so it would be messy to read those light keys from a func_detail/group/wall entity.

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

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?