If crisp shadows look bad on water, maybe lower-res lightmaps on water are an option?

I think the main goal is to just get darker water in dimly lit areas of the map - not to make super realistic looking water.

this is the kind of thing that would really need to be tweakable. there are many different effects someone might want to try for. Say your water is muddy, then a harder shadow makes sense. But it might be clean lake water, so a much softer (or no) shadow may be called for. thing is, none of that can be inferred from the texture name (*water) unless you get into fancy stuff like (*waterHazy vs *waterHard) or some such but it would be better to just have a .txt file with some values in it that is read by the compiler in that case. 

Both are completely irrelevant because we're talking about Quake water here.

I wouldn't say they're completely irrelevant. After all, they're photos of what water looks like in the real world and given that Quake is designed to render the real world with as much accuracy as possible (to the extent possible in 1996 and to whatever extent we judge now to be in keeping with its original fidelity/style), getting water that's as accurate as possible within those constraints should be worth attempting.

Obviously no one's suggesting we start pursuing a proper simulation of how light interacts with water, including refraction, reflection and so on, but a simple approximation of real water might be to say that clear and/or shallow water ignores shadows and instead lets them cast on whatever's below it, whereas murky and/or deep water allows shadows to be cast on its surface.

Ideally that might be done like the new texture lighting is done, with each texture being assigned a certain level of transparency. If it's flagged as, say, anything below 0.7, it doesn't allow shadowing on its surface, if it's above 0.7 it does. So you might might specify *water0 (used in the stream at the start of e1m1) as 0.5 transparency because you intend to use it for shallow, clear water, whereas you might want *04water1 from the start of e1m2 to be used for filthy, murky water and thus you assign it a transparency of 1.

Obviously you'd want any map that uses this to disregard whatever value the player has set for any r_*alpha settings.

Not sure how technically feasible all that would be, but it would make water look better, while staying true to Quake's modest looks and allow mappers to configure it in a fairly intuitive way. 

kinn's examples aren't shadows on water, they're shadows on the dense silt suspended in the water. water is transparent:
https://mw2.google.com/mw-panoramio/photos/medium/18556818.jpg
and lightmaps on clear or partly transparent water are what look strange, because they're not coupled with a volumetric fog component to explain the shadow to the eye.
https://developer.valvesoftware.com/w/images/8/88/L4d2_flowmap_user.jpg 

Its only the specular term of the water surface that is visible - its reflections (also, those little white specs you get on the tips of waves that are annoying to model correctly, resulting in most games having far too shallow waves).
Obviously there needs to be some sort of fog effect when the water contains impurities that reflect light, and this can have shadows cast upon it. good luck getting that realistic though.
Following on from that thought, any water fogging needs to know the surface plane of the water - and on maps like dm3, there is no singular plane, and that just makes any sane waterfogging logic go crazy.
If the water surface is reflecting light then this of course means that there should be a darkening of the surfaces below the water line. Also, any water impurities should cause the lights to have a higher attenuation for the parts of the ray that travel through the fog, relative to the amount that gets reflected up and away from the water volume before it can reach the surfaces below.
Also, lights shallow angles will reflect some light from the surface of the water rather than through the water (fresnel effect), increasing with how close to the water plane the light is - and of course, if you have waves then the closeness varies...
This is all very interesting if you're writing some glsl (yay for cubemap refraction and screen-space difraction), but if you're writing a static tool then you're basically doomed. DOOMED I SAY! Okay, melodrama over, but imho the best you can do is just use a single light value for the entire water surface (which of course might need to consider the intensity of the water texture too, which iirc is typically a little darker due to not expecting any lighting ever).

It might be interesting to generate really low res lightmaps for water, and by really low res, I mean one lightmap sample for every 1024qu or something. However, with that sort of scale, I expect you'll have a whole load of issues with vertexes inside walls and other sorts of issues. calculate at 1/16 and average it something like -extra4 already does? 

FFS, it's Quake ... what could possibly look worse than the fullbright water surfaces we have now? Just try something. Anything. :) 

Hmmm - well, it's possible to set things up so that water recieves light but doesn't occlude it - which actually looks mostly OK!

http://i.imgur.com/lDKcJs7.jpg 

Warren speaks the truth. Let's not get sperged down by details of physically realistic water.

I reckon:

ability to specify lightmap resolution on liquids - as discussed, lower resolutions than usual will probably look better.

0-1 float value to define liquid lightmap "influence" - 0 = fullbright surface as before, 1 = full lightmap, as if it's a solid opaque surface.

For lava, I'm sure you'd want 0 always, but for slime and water, I reckon there's a happy medium somwhere. 

 

And then normalize the color maybe?
Just thinking out loud here...

float Alpha = magnitude(lightmap.rgb)
float3 LightColor = normalize(lightmap.rgb)
float3 Color = texture.rgb * LightColor
output float4(Color, Alpha)

Haven't written any shaders in years, can't remember how it's actually done.

Maybe skip the color and just use intensity
Maybe this would look completely weird... 

the reason why we dont have lightmapping on water was because the water texture warps around and moves, and the lightmap would move and distort with it? 

Not necessarily. It's possible to warp the water texture but not warp the lightmap. 

I do hope this is something that gets implemented then, fullbright water is crap. 

Is gorgeous, lets just do that ;)

Theres no clean water in quake anyway! Shub-n-word-erath and his buddies have been jizzing in it for aeons, we all know that. Does no one even read the back story? 

https://www.shadertoy.com/view/MtB3DK
Click and drag around to mess with the alpha values! I'm sorry I suck at this! 

I'm not quite sure I see the appeal of what's going on in that czg...thing - but let's stick with the czg theme for a bit and just remind ourselves about this sort of thing:

http://i.imgur.com/htecdQb.jpg

We've been using those crummy "waterfall" textures for years, and they get lightmapped, and I don't think anyone's complained (about the lightmaps on them). I think they look alright don't they? I still don't get what's so terrible about just trying that on the proper liquids. 

Well... that's something we can test right now with the tools given to us. Here's a crummy waterfall made of func_illusionarys with "alpha" "0.65"

http://scampie.net/etc/transwater_1.jpg
http://scampie.net/etc/transwater_2.jpg

It looks okish when viewed from above, but once you get to about chest deep in the water, you realize it's just a plane of animated texture and it starts to look fake. It's not the worst thing in the world, but certainly not convincing.

here's the .bsp and .map and all that. requires an engine that supports "alpha" key on brush models (fitzquake engines)... if you want to compile the .map so you can fool with the alpha values and such, you'll want ericw's tyrlite becuase it's mostly lit with sunlight and sunlight2
http://scampie.net/etc/transwatertest.zip 

"It's not the worst thing in the world, but certainly not convincing. "

This implies that it was convincing before. 

Well, what I meant is it looks odder where you have a lightmap on the transparent water because you lose a sense of it having any volume. The bright spots on the surface of the water call attention to the fact that there should be lighting on some volume inside the water as well, so it ends up just looking like a flat plane suspended in the air. In a modern engine, people would be putting volumetric effects and fog in the water to hide exactly this.

http://scampie.net/etc/transwater_3.jpg
Uniform brightness of the water surface, despite being too bright here, seems to sell volume better. Without the added transparency of the shadowed areas revealing that the light isn't hitting any particles in the water, your mind fills in that the water must be dense. I think if this were simply vertex lit to end up being closer to average brightness of the area it would look fine. 

I for one love it. And just leave it up to the math authors to support it or not. This on muddy swamp water would look great. This could work nicely when used on fake ground fog as well. 

Just started with corridor for the level introduction. I'm not even sure if that matches the theme in anyway, also I wasn't using any level editor for like 7 years, so it is just a quick sketch to remember basic things:

http://imgur.com/a/rGJIz 

Quick fix for geometry, small changes for light and texturing:

http://imgur.com/8GSFG88 

I think you're in the wrong thread. :)