High Definition Pack Video With More Realistic Shadows:

Watch Video

1) r_shadows 3
2) r_waterripple 3
3) QMB on, obviously
4) With HD Pack and Transparent Water .Vis/.Lits Pack

For illustration purposes. 

dumptruck_ds: Thanks I am no Gunter tho.

Hey, you're doing extensive testing and detailed reports to help squash obscure bugs AND getting mh miffed, so you're well on your way! 

Cool shadows. Any chance for lit liquids in the future? 

I can't remember if mh wrote a full fledged prototype or not and if the one or two small but important barriers were solved (i.e. detecting lit water and maybe something else).

I think if he did, it would eventually happen. 

I've solved the detection and posted the solution in some thread here or at InsideQC a long time ago.

The other problem was to compile the maps properly, but EricW solved that. 

Wasn't there an issue with the surface warping making it look really bad? 

Not in my engine.

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders. 

Detection: http://forums.insideqc.com/viewtopic.php?f=12&t=5835

And in hardware-accelerated engines it should be easy to combine warped textures with non-warped lighting through shaders.

This doesn't need shaders; hardware-accelerated Quake already uses two separate sets of texture coords for difuse and lightmap, so just warp the diffuse coords only but don't warp the lightmap coords.

The issue is that whatever way you slice it, it looks bad.

I do understand where the desire to do this comes from. You've built a map, you have a large water surface in it, the surrounding geometry is nicely lit and shadowed, and the fullbright water looks bad. And you're right, the fullbright water does look bad, but lit water actually looks worse.

The two big problems are (1) when the lighting on the water is sufficiently dark you can't see the warp effect at all i it just looks like a big dark spot, and (2) with translucent water enabled the water just disappears.

This is an example of taking a special case and wanting a general case solution for it, but not properly considering how that general case solution may or may not work outside of the original special case.

"Can I have lit water?" seems a reasonable request, but you also need to be thinking about lit laval, lit slime, lit teleports, how it interacts with translucent water, etc. 

I've already considered all of that years ago and Retroquad has individual cvars for each texture type. I usually keep r_portal_lit and r_lava_lit disabled in Retroquad, because the textures I'm using for them doesn't have glowmaps. But the slime texture I'm using does.

Your mistake is to think that you're the only one who thought about all that. No, you're not, you haven't even thought about liquid textures with glowmaps (QRP has them!), and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience.

Lit water does look fucking good. The Unreal engine already has lit water since 1998, and nobody ever complained about it because its maps were created with lit water in mind. Lit liquids in Quake is for NEW MAPS ONLY because the maps need a full recompile from the .map sources for this to work and the mapper must deliberately opt-in to enable it in the compiler.

Your issue is that you don't want mappers to have a chance. You don't want them to experiment and learn how to tweak the lighting in their maps to make lit liquids look good. You don't want them to have artistic freedom.

The "it looks bad" argument is not a technical argument, it's merely an uninformed opinion.

You are not a mapper. 

...and the worst thing is that you're speculating from a purely theoretical standpoint while I'm speaking from experience

I am actually also speaking from experience because I have also written this code and have also seen what lit water looks like.

Here's the Quaktastic folder where I uploaded a bunch of screenshots: http://www.quaketastic.com/?dir=files/screen_shots/LITWater

Check the date on them - over a year and a half ago.

Check some examples of exactly what I mean:

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

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

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

Your entire premise is based on the assumption that I don't know what I'm talking about, whereas I actually do. When I say "lit water actually looks worse" you had two options and you instantly reached for the negative one - yayy community. 

I am actually also speaking from experience because I have also written this code

No, you are speaking from MAPPING experience.

I've never made a full map but I often practice mapping to test and learn how new features like this could be used. 

* not speaking 

Not only you used screenshots from other people's maps that were NOT designed for lit water, your E1M2 screenshot shows that you probably didn't recompile them using the latest versions of EricW's compilers, which properly lits the liquids from both sides. The lighting at the edges of the water should be similar to the lighting of the walls that crosses them. 

All your screenshots looks like they didn't use EricW's compilers. Completely missing backside lighting.

I'm on mobile and not at home now, but asap I'll post some screenshots of those maps properly recompiled. 

To me all three of those screenshots you chose mh look quite promising and easy to work around to get pretty lit water with some effort from the mapper (and yeah some compiler magic would obviously help).
Would be curious to see with some high alpha values, as you seem to say it looks ugly, but plenty of other games have lightmaped transparents that look fine. 

OK, I am going to put my money where my mouth is.

http://www.quaketastic.com/files/misc/Q1LitWater.zip

This package contains:

(1) A version of GLQuake modified to support lightmapped water.

(2) Source code for it.

(3) A version of e2m5 compiled, using EricW's tools, for lightmapped water.

So now everyone can see it. 

Finally. We should let the mappers decide. Thanks for listening.

And to finish settling this, here are the comparison screenshots:

mh E1M2
Retroquad E1M2 (opaque)
Retroquad E1M2 (translucid)


mh E1M5
Retroquad E1M5 (opaque)
Retroquad E1M5 (translucid)


mh E2M5
Retroquad E2M5 (opaque)
Retroquad E2M5 (translucid)

My recompiled E1M5 and E2M5 maps used an older version of EricW's compilers that added improper dirtmapping to liquids, IIRC (which is why their water is a little darker on the edges). But my recompiled E1M2 map used a later version that fixed all issues. Anyway, see how different all of them are from yours. 

Since mh wrote a prototype for it (using GLQuake makes it essentially a tutorial for any engine developer), it rather likely that some future date it will added to Mark V.

Especially since ericw (and Spike too?) invested the time to make lit water in the ericw compile tools.

I don't have an opinion of lit water. It is the time investment by other developers which would be the reason to have interest in adding it from my point of view. 

Here's a screenshot of my recompiled E1M2 running in mh's GLQuake with opaque lit water support. 

I noticed that Poorchop mentioned mouseclicks not registering. I'm seeing that myself at the moment with a fresh Mark V install on latest Windows 10... sometimes it's the +mouse1 that doesn't register (and so it doesn't fire), sometimes the -mouse1 (and so it doesn't stop firing).

Happens with both mark_v and mark_v_winquake. Doesn't happen with latest quakespasm.

Anyway, just some corroboration. Let me know if I should test/try something. 

Hmmm.

1. Does the SDL alternate build do this as well? SDL build

This would tell me if it were something about the pure Windows code or the all operating systems code.

2. Also: What do you have mouse1 bound to? Attack? Jump? 

1. Not nearly as often. I was hoping I could say "never", but I do think it missed a couple of mousedowns during a map playthrough. (While in comparison, it would not be unusual for mark_v.exe to miss a mouse event in the course of even an individual fight.)

2. +attack 

One probably-irrelevant difference I noticed: the mark_v.exe FPS display is pegged at 72 (my host_maxfps), while the FPS display in the SDL build wandered between 67 and 70 on the same map. 

Yeah, the probably irrelevant difference is just that. The DX9 is better at hitting exactly the 72 because it is faster.

re: mouse - Looks like more to do with Windows 10. I'm glad you are able to replicate the issue PoorChop experienced, increases odds of conclusively solving it. 

I'm glad too, good to know that I'm not the only one experiencing this.