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 

If that makes it into a release somewhere, anywhere, I'll be a very happy chappy. 

Spring update anyone? 

I think Baker's gonna need to make the judgement call on whether or not MarkV gets it, because it's pretty much all renderer front-end work. I'm 99% certain that the current back-end will support it without modification, but I'm willing to commit to any modifications that may be required should Baker decide to go for it. 

Just various random thoughts

1. Mark V has optional stain maps (defaults on), like FTE, which uses the lightmaps.

2. I'm sure you already have this one taken into account, rotated and moved brushes.

3. Here's a more complex one --- fullbright colors in water texture + software renderer :( This isn't necessarily as annoying as it sounds and in-engine conversion of a water texture's pixels from fullbright blue to non-fullbright blue at map load is likely an option. I guess I'll need to look at the textures/palette, I hope there isn't a fullbright blue without a non-fullbright equivalent.

4. Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage.

5. Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined. One thought is inserting a worldspawn key "litwater" "1" (is this the best way to mark the maps? I'm not saying it is. But if lit water maps can be loaded in standard engines, at least this method does not require a new map format. But there could be a better way and this is just one thought, but avoids MH's "don't know" scenario.). 

Did a quick palette conversion test of the traditional blue water to a non-fullbright palette. It's fine. Non-obstacle.

Lava will have to be fullbright because the software renderer doesn't have a choice except to use the Quake palette, and there are no non-fullbright versions of bright red. 

I don't really have an opinion on lit water.
I guess it looks ok in those screenshots.

What I really wanna see is reflective water!
But r_texprefix_mirror doesn't seem to do anything when set to a water texture.... 

About corner cases:

- Winquake.exe seems to be fine with the example lit water map I posted.. it doesn't have a problem with liquid faces missing TEX_SPECIAL.

- The qbsp options "-splitturb" (and "-splitspecial" which is older) unset TEX_SPECIAL on the affected faces.

The main problematic case I can see is a face with:

- texture = "*water"
- lightofs = -1
- styles = {255, 255, 255, 255}
- TEX_SPECIAL is unset in the texinfo

Do you render that fullbright or solid black in an engine with lit water? I think it needs to be rendered fullbright; faces with those settings will exist in the wild if anyone ever used the "-splitspecial" qbsp option. It would be worth checking how Darkplaces handles this corner case since it's the first released implementation afaik.

So to fix this case, the light tool just needs to avoid writing those "implicitly black" faces for lit liquids. IIRC, mankrip requested that a while ago but it looks like I didn't implement it yet in my light tool. I think if I do that, we don't need any other kind flag to mark the map as using lit water. (presumably the engine should support mixing lit water and non-lightmapped lava)

- Other rendering stuff: imo fullbrights should be rendered normally (for fitz engines, respecting the gl_fullbrights cvar), the lightmap should not warp (I'm imagining it as a shadow cast on floating leaves that are swirling around; the shadow shouldn't swirl).

- Light tool stuff: there is already some handling in my tool that mankrip contributed; lit water faces can receive light from either above or below, and they don't cast shadows. This part I'm not so concerned about, it's easy to tweak with features as they are needed.