sorry, the download link was owned by caps... this is why you do things when you are awake and paying attention....

http://scampie.net/privfiles/DM2_lite_052215.zip


warren: yeah, sorry... my monitor apparently doesn't look like anyone else's and my screenshots always come out too dark :| 

If we are going down the road of .lit2 + special engine support...

Could we introduce lightmaps on liquid surfaces as part of lit2's features?

Quake's ugly fullbright water is one of the big immersion-breaking things imo, and it would be cool to update that a bit :} 

Thanks Scampie. DM2 looks a million times better. I recently ported DM2 over to Quake 3 and give it a similar treatment.
http://i1187.photobucket.com/albums/z382/AndehGX/quake3/axq1dm2.jpg

Also, does anyone still have Gypsy's .ent and virtuoso pack for Quake 1? I lost it in a format, and his links are dead :/ 

Could we introduce lightmaps on liquid surfaces as part of lit2's features?

Yes plz! (need to have some way to make lava fullbright though!)

--

I calibrated my monitor (brightness was way too high) and adjusted levels on my screenshots in post #435 and reuploaded them, hopefully they aren't super dark anymore? Think the map itself is actually lit too dark, but it's not terrible. 

Hah, the same request came up in the inside3d thread. I think it can be done in a way that's backwards compatible, without needing special support in lit2. It'd probably be a "-litwater" flag for qbsp and light; qbsp would use it to chop liquids on the 256 grid (they aren't normally chopped), light would generate lightmaps instead of not. Pretty sure engines not supporting lit water will just ignore the lightmaps (but need to verify this.)

According to LH, DarkPlaces will already render them. 

Could we introduce lightmaps on liquid surfaces as part of lit2's features?

This doesn't actually need LIT2 at all. You could do it with a regular light tool and some engine modifications.

It would also need QBSP modifications because by default liquid surfaces aren't subdivided as much as solid ones.

But you probably don't want this at all, because in most cases it actually looks worse than fullbright water. 

yeah, you can't light water without going into a whole consideration of how light interacts with water. eventually you'll put a fancy portal2 water shader alongside 300-poly monsters and you get this silliness:
http://quakeone.com/~files/ss_e2m1_FN3.jpg 

mmm yeah, you're right... in Lun's example pic, that water would just be standard Quake water, except tinted bright yellow by the bright yellow lights. 

I don't have the game right now to check, but didn't Quake 3 just have lightmaps on top of simple Quake-esque water?

Coupled with transparency, it didn't look too bad if I recall? 

http://scampie.net/etc/q3_water.jpg

think q3dm10 is the only place it's used in stock q3?

It does look reasonable, but might only work because there's like 3 layers of mostly transparent water textures blended with the light. 

I reckon vertex-lit water would be reasonable, with a single vertex colour for the entire water plane. Of course the mapper would need to be careful about the placement of lights relative to water so that we don't get weirdness like water surfaces half-in and half-out of a really bright area. But it would solve what I guess is the primary problem here, which is a fullbright water surface in an otherwise uniformly dark area.

Much of that also goes away with translucent water, where the water surface blends with the underlying geometry. You almost certainly don't want to add lightmaps there - light is supposed to shine through water, after all.

Another problem with lightmapped water is that the lightmap can obscure the turbulent warp effect. Under certain conditions it just looks like a regular solid surface (until you walk into it).

Shadows being cast on water surfaces also looks wrong.

To be honest, and having implemented this in the past (but with realtime light rather than lightmaps), fullbright water is really just the lesser evil. Lightmapped water falls apart real quick once you move away from just wanting it and graduate to actually thinking about how it would look. 

Shadows being cast on water surfaces also looks wrong

http://i.imgur.com/5GU8rQi.jpg
http://i.imgur.com/f10kgnE.jpg 

Looks wrong somehow. 

Vertex-lit water like mh suggests could actually be good, just avoiding super-bright water when you're putting it in dark areas likely would be enough.

Tricky part might bebackwards compatiblity and lava which should be fullbright no matter what. But it sounds like a reasonable approach to try 

http://i.imgur.com/5GU8rQi.jpg
http://i.imgur.com/f10kgnE.jpg

The first one looks OK because you can still see the water effect through the shadow.

The second one looks like concrete.

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

Tricky part might be ... lava which should be fullbright no matter what

QBSP identifies lava by the presence of the word "lava" in the texture name, so the light tool and the engine could do the same and just skip lighting/draw without lightmaps. A modified QBSP could of course identify lava by something else.

I'm of the opinion that teleports should also be fullbright, and slime should at least have some light of it's own too. QBSP also identifies "slime" like it does "lava", but doesn't identify teleports. 

You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 

You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 

You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 

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. 

-setting a low r_wateralpha
-using dark water textures
-use a darker .tga for the water texture, to avoid quake palette limitations 

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. :)