I've confirmed that the problem with not all water surfaces being lit is a tools bug.

The light tool will only generate lightmaps for the liquid surfaces that gets hit by a light entity's beam. If no beams hit a liquid surface, no lightmaps will be generated for it. I couldn't figure out a simple way to fix this yet.

I'm compiling the maps with qbsp -splitspecial enabled. 

I see, normally face->lightofs == -1 means the lightmap is black, but for liquids you need to treat -1 as "not compiled with lightmapped water, so render fullbright", is that right?

It should be easy enough to always save lightmaps for liquid faces, even if solid black. But I don't think I added lightmapped liquids support to tyrutils-ericw, do you have the code for it already? I am happy to add a command line flag for it, just don't want to waste time reimplementing it if you already coded it. 

that would be my fault. I added -lightwater etc args in that smoothnstuff branch, but didn't actually get around to testing it at all.
(release early, release often, right?)
it should be simple enough to tweak WriteLightmaps to just write a lightofs of 0 instead of -1 when texinfo->flags&TEX_SPECIAL, with all styles still set to 255, I guess.
I assume engines will be able to cope with that, but I've not checked. 

Wasn't there a concern due to the way that most engines render water by using a deforming mesh? 

@Spike ah, cool. Still meaning to merge in your smoothnstuff branch, just lazy right now :)
@Fifth hm good point, this will need to be tested. Also thanks for the idea about using "smooth" prefix on texture names to enable phong shading, that could be good. 

re: unmerged branch
I wouldn't worry too much, I've been too lazy to fix any niggles since I uploaded it. :s

re: smooth prefix
I disagree in the long term on account of that making multiple smoothing groups too awkward to use effectively.
supporting q2 .map files for their surface flags would be good. tyr's qbsp can already parse them, so we just need editors that support q2 .map with wad files, and to actually implement smoothing groups with it.

re: lit water
yes, lit water would generally imply that the lit water surfaces should also be subdivided by the qbsp in the same way that regular walls are (this means the qbsp needs to be aware of it too, and not just the light tool).
engine-based turb subdivision isn't really a concern, as it doesn't affect the lightmap. there are already occasions where surfaces are overly pointy. if anything, having the qbsp subdivide turb surfaces too would reduce this
the 'real' concern is that very few engines actually support lit turb surfaces

re: nstuff
I kinda want to build func_illusionaries and brushes with alpha-masked textures into the world too. conceptually this would be easy (assuming it doesn't have any fields set), they can just be treated like some water contents with water vising stuff, and be converted to the appropriate contents type just before qbsp outputs the unvised bsp.
this should improve engine batching and stuff (and be consistent with what hlbsp support already requires from engines).
there's some other things that need tweeking, but I forgot much of it. :s 

Yes, I've fixed something else in the light tool for the lights to display properly on liquids, but by default you just need to compile the BSP with qbsp -splitspecial. This will make water surfaces be subdivided, and with the TEX_SPECIAL flag not set. In theory, this should have made them be treated exactly like regular surfaces by the light compiler, so this bug with fully dark liquids is puzzling me� 

I've managed to fix it tonight. It should be bug-free, but it would be better to attribute a dummy lightstyle for fully dark liquids, to avoid potential "too many light styles on face" warnings.

Posted at InsideQC:
http://forums.insideqc.com/viewtopic.php?f=12&t=5769 

That wasn't your fault. I've implemented this code way before you released your smooth shading code.

My code still uses an old version of TyrUtils, by the way. I haven't ported it to the current releases. 

Lit fluids and smooth shaded surfaces... come on guys XMAS is over already and yet your still making these lovely gifts for the mapping community? :) Please continue. I do look forward to a final version with all these new toys included.

BTW the Website showing showing all the various options has been a great help getting the concepts across when it came to the dirt and sunlight options. 

I use light v0.15.3-7-g05de1ad and it crashes when I combine -extra4 and -soft options. While these options work fine if I use them separately.

Also I can't find if there's per entity minlight support. Adding minglight key to bmodel entities doesn't seem to work and documentation does have information about it. 

I think the -extra4 and -soft crash is fixed in v0.15.4: http://ericwa.github.io/tyrutils-ericw/

The per-entity minlight key is: "_minlight". There's a section of the light manual "Model Entity Keys" but it's easy to miss! 

That crash is really fixed in 0.15.4.
And thanks for pointing me at _minlight key, I really managed to miss it. 

Is it possible to make something similar to the shadow brush in hl2? It's a brush covered with texture with a special name (like skip) and doesn't have collision but casts shadows like it was a visible brush.

That would allow to manually create shadows for models (AD trees come to mind) or some new lighting effects.

If something like this already exists in quake you can point me at it. 

 

 

Set _shadow 1, or is it _shadows 1? 

What mfx said 

you patched still in these new versions or was that a separate branch you gave me? 

maybe a func_wall which is kill targeted immediately with a fence texture of leaf shadows???? 

(I thought about posting that necros, but that's cheesy.) 

dumptruck_ds: Yeah, the fixes for DP are in the main branch v0.15.4 which is what I recommend using: http://ericwa.github.io/tyrutils-ericw/

I think Spike has a better fix for the problem in qbsp in his patch, I want to test it a bit; I hope to return to working on this soon and merge his stuff and mankrip's patch :-) 

It would be possible to make the light raytracer trace through mdl's so they cast proper shadows. If an entity has "_shadow" "1" set and "mdl" or "model", try to load that mdl? there would need to be -basedir / -game flags to light so it can find your mdl's.

The thing that would mess it up, though, is this would likely make the mdl's black in game, since they would usually cast a shadow over where the engine samples the lightmap. So it might not be worth the effort 

More or less as amusement ideas.

1) WAD3 support. Screeshot More fun with more colors. Sample halflife.bsp download which Mark V can load both in the Open GL renderer (and also in the software renderer too!) Adding Half-Life map BSP 30 type of support is rather easy in the engine.

2) Rotation. You thought about it last summer.

3) Mirrors visibility support.

/Like people haven't posted enough ideas in this thread! 

Following on from what ericw said about shadows from mdls, there's a problem obviously in how the engine lights the mdls in game.

Imagine also lighting the models properly - i.e. the light tool writes a new type of lit file that saves lightmap information for specifically flagged mdl entities - then custom engines can read these new lightmaps and if one exists for a model it uses that rather than using the default way of mdl lighting...