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. 

Here's a more complex one --- fullbright colors in water texture + software renderer

That didn't even occur to me, but yeah - a GL/D3D engine can just not draw a fullbright, but software doesn't even have the option.

Rather than remapping I think if it was me I'd probably do an extra colormap.

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

Not a problem. Most of the work is actually changing various cases of "if (surf->flags & SURF_DRAWTURB)" to "if ((surf->flags & SURF_DRAWTURB) && !litwater)" at runtime, so load time is fine.

Would be very helpful if ericw could mark the .bsp as having transparent water somehow to avoid the "don't know" scenario you outlined.

I think the don't know case was me being nitpicky more than anything else. It is possible but the probabiility is so low that I don't think you'd ever actually see it.

What would be more worrying is bad tools setting surf->samples for a drawturb surface in a map that shouldn't have lightmapped water, because that's really the only way you have of checking, but I don't know if such bad tools even exist. Either way, providing an r_lightmappedwater cvar that the user can set to 0 can help with that. 

Water with garbage fullbright pixels is a texture pack problem, as it always was with garbage fullbright pixels. I don't think it should be solved engine-side. That would only complicate things. 

Although not an official texture, *tele teleporter textures should probably be fullbright (not lit). Both Mark V and Quakespasm treat *tele textures differently.

dwere: Water with garbage fullbright pixels is a texture pack problem ... I don't think it should be solved engine-side

Sounds logical. 

tell the mapper to put liquid brushes in a func_group and then set all the different liquid lighting options on the func_group. 

Personally, I've had enough of having to do that with _phong 1 on all my func_details... 

The idea isn't to annoy the mapper by making him manually set the rules up on each func_group - I assume there would be default liquid lighting settings that are used if nothing is specified, but...if you want custom light behaviour on a certain liquid body then you can func_group the liquid and set some options...

Beats having hardcoded arbitrary rules for teleport textures and whatnot imo. 

Do it like surface lights - have an entity whose sole purpose is to specify the light properties (aka override the defaults) of a particular texture, which then applies to all instances of that texture in the map. No need to use func_groups.

I only thought of this because with custom liquid textures used for random things like teleporters or energy fields, the texture names can be unpredictable (I think Knave has a *starfluid texture or something) 

I think the special entity could work, although I don't think it's ever been done before - with surface lights, it's a single key that specifies that the light it's on should be duplicated and spread across all instances of that texture. It's not specifically a custom entity that does anything different to a normal light.

This is quite offtopic, anyway... 

I'm slightly tempted to add an (optional) auto-jump feature where a player at an edge will automatically jump *only* if they can make the jump at the current speed *and* they are running.

If they can't make the jump and are running, the option would work like "edgefriction 999999" (if you don't know what it is, you might try it) and make it very difficult to fall off an edge.

And perhaps have the option have an "automatic jump up" if forward progress requires a upwards jump that can be made.

(Because pressing "jump" seems to be an annoying burden if you aren't using a mouse + keyboard). 

But is it similar to quake 3's awesome stair clipping. I hate q1's momentum loss around short floor variances 

I can understand that this might seem attractive on accessibility grounds, but (and unless I'm seriously missing something) wouldn't it totally fuck with your game if you were playing with "always run" enabled? 

rebind the jump button to +run 

I don't fully get it, but it sounds like a terrible idea.

Why don't you just make it a full bot so the player doesn't have to press "attack" in addition to not having to press "jump?" Because "aiming" is an annoying burden if you aren't using mouse + keyboard... or, you know, if you just suck at Quake :p heh. I know you're probably thinking about Gamepad controls, but still, meh.


mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]). 

I know you're probably thinking about Gamepad controls, but still, meh.

I think he's talking about things like phones and tablets. Gamepad users don't have a problem with jumping.