Mankrip said maps like e1m4 don't compile with lit water. This was months ago, maybe that changed.

Until someone steps forward proving any of this stuff works and is polished ... I'm not sold.

I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler.

Man up?

Maybe find the courage to actually use the compiler option?

Maybe find the courage to load the map in DarkPlaces or existing engine that supports it? 

http://www.quaketastic.com/files/screen_shots/LITWater/e1m4_litwater.jpg

This, of course, is not compiled by any light tool. 

Do you light lava? Slime?

Should be up to the mapper.

Do you add a warp effect to lightmaps?

I wouldn't, but it depends on how you perceive the warping. Does it only represent horizontal movement of the substance, or does it also imitate vertical waves to a certain degree? Distorting the lightmap can help with the latter, I suppose.

Maybe we should decide that because light goes through translucent water it doesn't get lit.

Then it will glow on its own. 

So some of the HD backs from here: http://quakeone.com/forums/quake-mod-releases/works-progress/11588-hd-textures-sp-maps.html

fail with Only type 2 and 10 targas are supported message. I get thrown back to windows until I find the files and delete/rename.

Of course I had to extract them from the pk3s but even re-extracting doesn't help. Example is +1wall58.tga from arcanum HD textures. 

I'll look at having tga files that aren't type 2 or type 10 just do console prints instead of errors in the future (next updates likely in the spring).

Erroring out to windows seems like overkill.

Thanks for point this out. 

I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water. And yes, the turbs were split.

Man Up?
It wasn't/isn't an issue of "manning up", at least not from my perspective. I'm fine with turning on a compiler flag. I just like to be able to see the results.
Imagine compiling lighting for a map in general and never ever looking at it. Doesn't that seem like a daft idea? Perhaps you got the values all wrong, everything is too dark or too bright. But because you never look and see what the results are, you'll never know and your map will suck.

untold pain and suffering
Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?

The other way to handle that that I can think of right now would be to change the result based on whether there is ANY water with light data or not. If there is some, you could pretty safely assume that all water is supposed to be "lit", and so water surfaces without light data could be rendered black. If there is no light data for any water surface, then you could assume that it is not supposed to be lit. There may be a few edge cases there, but that would, I imagine, cover support for correct water rendering in 99% of maps, as well as allow for it in the rare pre-existing "lit water" map and all future ones.

Also, I'd be interested in finding out why some maps refuse to compile with lit water? I've never had any kind of lighting setup outright refuse to compile on me. 

@Pritchard try this map in DP: https://www.dropbox.com/s/p0ixun0h0ajr4zy/lightstest1.zip?dl=1

Here is what it looks like for me:
http://i.imgur.com/9rWWeR6.jpg 

I just like to be able to see the results. I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water.

Understood. ;-) I'd want to be able to see the results too. 

@ericw - that map works; the water is bright, and then it gets darker... and it's glorious. *hint hint, nudge nudge @Baker*

Now the question is why can't I get it working for my map? But that's something for your compiler tools thread, I imagine. 

Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?

What I'm actually talking about is the 20+ years of existing maps that have this behaviour. 

Yes, of course, but if you could look at a map and say "none of these water surfaces have any light data, I should not apply lighting effects to the water", that'd be fine, wouldn't it? 

Should water have fullbrights? The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.

Should water block light? It's possible for a surface to receive light but not block it - that's what doors & plats do. But if water blocks light it means scenes like the lava pit in start.bsp would be almost full dark - most of the light entities are inside the lava. 

I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting.

I don't think water should block light - it's unrealistic and would make extra work for mappers that they probably wouldn't see a point to doing.

Perhaps lava should have fullbrights though - it might look good for that. I also think the issue with lava looking bad if it's lit can be counteracted with surface lights, although it is something that would trip up noobs... 

The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.

I think the orange fullbright range is just the best color range for lava in the palette.

I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting.

It can be a problem with existing texture sets, since they were developed with an assumption that liquids are never lit (therefore there's a greater chance for bad fullbright distribution on liquid textures).

But what if someone actually wants fullbrights on liquids? 

I'm a big fan of the idea of lit water

http://i.imgur.com/9rWWeR6.jpg
That looks pretty good - although it's hard to tell from such a small blurry image, but I'm pretty sure it looks a ton better than regular water.

should light block water

The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea.

What about directional considerations?

In this shot, the water looks bad because light is coming up from below the surface, lighting the rocks, but the surface of the water doesn't receive it, so the water/rock transition looks bad: http://www.quaketastic.com/files/screen_shots/LITWater/e2m5_litwater.jpg

To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think?

Kinda like quake's window textures - if the light is coming from either side of the window, you'll expect to see light on the window surface. 

With tools like defullbright out there, it might not be such an issue with existing texture sets. Perhaps it would be best to render fullbrights for liquids. 

Water would definitely have to be lit differently to normal surfaces, like Kinn describes. Again, that's on the compiler, rather than the engine... 

was mentioned last time this topic came up, but the lightmap on water should probably get blurred a bit too - hard shadows would probably not look good. 

I thought everyone used -extra4 -soft ;) 

I'm not sure how much this is a consideration, but...

To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think?

...this reminds me that Q1 BSP actually stores each water surface twice. Once for the underwater view, once for the above-water view, and so visibility (not so important if you have translucent water) and backface culling (always important) work correctly. 

I don't use -soft, I'm not keen on that look nowadays.

On water though of course it's a different story. 

The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea.

Thinking about this it's probably not too bad. I'm not ericw, but I think when you do a raycast you can note the point when the ray hit a water surface and take that into account when lighting geometry under the water. I have raised this to "probably would want it" because consider an outdoor pool/lake - you have sunlight lighting all the geometry outside, but you want to dive into that pool and see the sunlight penetrates the water to light objects just below the surface, but as you go deeper, the sunlight fades to black... 

meanwhile all the fish at the surface are pitch black because they get their light from the floor trolololoool 

Nothin' wrong with black fish. Some of my best fish friends are black. 

I decided to stop talking and start doing.

http://www.quaketastic.com/files/screen_shots/LITWater/GPU_Lightmaps_Lightmapped_Water.jpg