Water - lighting - transparency

[ajay]

A couple of questions that I've spent a while looking into but not getting/finding the answer I was expecting.

1) Water in Quake emits light, well appears to anyway. For instance I have a canal, which 'disappears' into a tunnel which is unlit. However, the water remains 'bright' rather than disappearing into darkness. Is there a way round this?

2) As part of trying to solve this I was also looking into transparency in water (mainly because the 'pretty water' I was using with Darkplaces didn't appear to be lit or emit light, but now I'm firmly BSP2 only DP is out) now there's the VisPatch for transparent water, but I was convinced there was a way to do that with newer Vis's when compiling the map, but can't find the option?? 3hrs of google and/or searching inside3d usually solves such things...

As usual, you're gents, ladies and scholars for indulging me

[negke]

Liquids don't emit light, but they are always fullbright ingame. The only way I could think of to make a normally lit water surface is to use a non-asteriks water texture on a func_illusionary above the surface of the water volume or on a custom progs func_water entity. Of course it won't be animated then. Maybe a custom flow animation made from the original water texture would work in the tunnel? Otherwise you'll have to work around the problem, for example by making the tunnel go around a corner.

[goldenboy]

TxQBSP2 does transparent water by default. r_wateralpha 0.5 in the console to enable it.

You can use an info_command if your progs supports it to stuffcmd that when the map is loaded. Evil, but works.

As negke says, can't do much about the fullbright water except hide it where needed, hack the light tool, use some other trick, or use transparency.

[mh]

Translucent water should really be set via worldspawn and picked up by the engine on map load. info_command is nice for sure, but it doesn't survive a save/quit/reload transition; the worldspawn method is 100% robust.

[goldenboy]

Yeah, the worldspawn method would be better.

Even better would be to set transpareny on every individual body of water, I guess. Plus teleporters shouldn't really be transparent.

[leileilol]

Somehow could maybe work modulated / multiply blending on it instead. You can do this in Darkplaces by having a q3 shader script for that, and engoo (SORRY ABOUT THIS SELF PROMOTION ) also has an option for multiply water, which gets along better in dark areas at certain water alphas. Quake 3 used multiply water a lot BTW, mostly without lightmaps as well even though water can have lightmaps in that game.

from the beginning water can't have lightmaps because their surface was always rendered with turbulence which uses different span code, it doesn't even have mipmaps

[ajay]

Thanks all. So the water textures are displayed as fullbright by the engine, so could an engine mod change that, or would it be likely to bork something else? Transparency isn't really fixing it, though the DP pretty water did - but thats no longer an option. It was a long shot really. Why is it fullbright anyway; doesn't make meaningful sense to me *sulks*

[mankrip]

Lightmapping information is stored into the surface caches, but the software renderer doesn't use a surface cache for drawing turbulent spans; it renders the water texture directly as a tile instead. Maybe the hardware-accelerated ports also does this.

Some of the reasons why it doesn't use the surface caches for drawing turbulent surfaces are that the surface cache for those surfaces would have to be enlarged to make the turbulent effect not run out of the texture space in the edges of the surface, and also because if you apply turbulence to a lightmapped surface cache, the lighting will also become turbulent.

The first way I can think of lighting turbulent surfaces is to create a different kind of surface cache containing the lighting level (instead of the color index) for each pixel and rendering it to a separated buffer, so when rendering the turbulent surfaces we can use that lighting buffer in conjunction with the color indexes of the turbulent surfaces as an index on the color shading map to get the final colors, but that could have been really slow in the 486 days. Hardware-accelerated engines could probably do something similar to this.

[mh]

With hardware acceleration you don't need to do anything special. Just warp the diffuse texcoords, don't warp the lightmap texcoords, and the end result comes out.

As well as water surfaces being displayed fullbright by the engine there are two other things that I don't think have been made clear yet.

The BSP does not contain any light data for water surfaces.
The Light tool does not generate any light data for water surfaces.

So we're not looking at just an engine mod here; we're looking at tool changes too (I don't think it needs a BSP format change).

Also - Quake has no surface flags so you can't specify things like "I want lava to be fullbright but regular water to be lit and slime to be half-and-half". As a fairly general rule of thumb lava textures are generally called a name beginning with "*lava", but they don't have to be so you can't rely on it. The whole setup would also break where a mapper may have used scrolling textures for a "waterfall" effect.

The only real way I can think of to get this done would be something like using a sequence of animating textures for the warp, place them in a func_illusionary at the correct part of the map, set .alpha on your func_illusionary so that engines supporting it will pick it up, put in correct water brushes in the main model so that the leafs will get their contents set properly, and use a skip tool to remove these brushes from the final BSP. Nasty and it would probably look ugly, but it would work and with no weird edge cases.

[frag.machine]

[mh]

They're set by QBSP and do use a convention (*lava and *slime) but there's no reason why someone couldn't mod QBSP to change the names or add additional ones. The point is that engine-side you can't rely on it because it's something that has already been done and is outside of your control.

[Knightmare]

If you intend to modify the engine (hardware accelerated) but not the map tools, you can do vertex lighting. This still requires subdivision of water faces to have enough vertices for it to look right. Quake2Max did this first I believe, and KMQuake2 has improved on it. There will be differences between GLQuake and Quake2, but the overall approach should be the same.

First, trace downward on map load for each water/warp surface vertex, and get a lightpoint value. You can poke around 1 unit in each direction to get a better sample (keep the brightest value) to avoid dark vertices from sampling in corners. Then store that lightpoint value for each vertex sample (requires adding a light value to the vertex struct). Finally, render with that light value for the vertex color instead of the identity (1,1,1).

Also, using vertex arrays and batching water surfaces with the same texture can greatly speed things up in maps with lots of water/warp faces visible at once (such as areas with a large or many func_waters in Quake2).

[leileilol]

I think an old MHQuake used to do that but I could be wrong.

[ajay]

Damn. I was hoping for "If texture = water then fullbright = no" level of simplicity. (Yes, even I know that's not proper code)

[revelator]