Why? Surely there is some way to fix this. I don't mean light mapped, just some way to turn the brightness down. I made a custom water texture using only the darkest colors available and it still looks too bright in places. The only thing that seems to help is wateralpha, but transparent water doesn't look right in Quake. 

 

Use wateralpha, and put a very thin (2 units) func_illusionary right under the surface, and then put an all black texture on the top face and skip on the bottom face. 

Use wateralpha, and put a very thin (2 units) func_illusionary right under the surface, and then put an all black texture on the top face and skip on the bottom face.
I have done this with teleporters, lava and water, works a treat! I usually make the lava illusionary brush red and the water one similar base colour to the top texture. 

Interesting idea. Might look funny if the player uses a very transparent wateralpha setting. I don't have any models left and I'm real close to the marksurfaces limit. I might just have to add a little more light to this particular area (it's not a very big part of the map).

On the other hand, I'm beginning to see less and less reason to keep deathmatch stuff and that would free up a number of models. I intend to finish this thing by the end of the year, if not sooner. I'm tired of working on it.

Still, it would be nice if this could be added as an engine feature, kind of like fog. 

That's an engine issue, not a mapping issue. You need to use an engine (like GLQuake, I think) that ignores fullbrights altogether. Personally I think that unless it's *Lava a little transparency can be a good thing in a visual sense. Of course it may also "Break" a map because, for example,in E1M4 (The Grisly Grotto), you can avoid the Skraggs by simply diving in and due to how the old vis worked you would disappear from their view and thus not get shot at from above or perhaps you can see a secret that you missed before. 

You need to use an engine (like GLQuake, I think) that ignores fullbrights altogether.

That won't work. 

I'm pretty sure liquids (including the sky) are treated differently from normal textures. Maybe that's why there is no brightness setting for them, because it would affect all of them equally? 

in terms of allowing the texture to be lit.

He said it wasn't possible, which is a shame because it would be great. I dunno if it is possible in dark places, probably is.

Fullbright water sucks :( 

Requires changes to both the tools and engine. Possible an updated bsp format too, though we could probably work around that. 

I can see why shadows on water (light mapped water) would be a problem, but what about some way to darken the water texture down from full bright? Just the ability to choose 75, 50, 25% brightness or something like that would be a big improvement. Actual shadows are not really needed, though I'm sure some people would think it's great.

A full bright sky is not much of a problem, most people use a skybox anyway, lava seems like it ought to be bright most of the time, but water being full bright often just looks bad. 

how about using an external TGA texture that is really dark? 

I was going by memory. I could swear that there was an engine out there that didn't fullbright liquids... Maybe an early version of TXQuake (OpenGL based) or something else from that era (early 2000's a year or two after the GL source was released) I recall that it looked washed out in general. Then again I might have been thinking of a totally different game altogether, maybe Q2.

It (fullbright liquids) can screw up the look of a level in some places because it stands out so much if you want to go dark and gloomy with a secret area that you need to dive into in order to get to the goodies. There are ways around that with creative brush work but it's still a bit of a pain to light in order to explain away the bright liquid.

Ideally only *Lava(xx) (all versions) would be fullbright with the *water(xx) never fullbright, *04water(xx) always fullbright, *01slime(xx) being never fullbright and *04slime(xx) being fullbright, or some other similar naming convention.

I get why they did it back in the day and it made sense from a hardware point of view but today it can limit options in some small cases. 

If you're already willing to change the look of default Quake, then using DP/FTE and GLSL water isn't a stretch. Pretty sure you can set some parms to the GLSL that would give you less transparent water, such as fog, tint and fresnel. You could try not using normalmaps with the glsl water either, or really flat ones to prevent the water bumping itself...


or write your own glsl water shader for vanilla looking water just slightly transparent but still not able to see much beyond the surface. Fresnel etc.

Real water's transparency depends on depth and the colour of the ground etc, so the dm3 pool shouldn't be fully transparent indeed.

glsl is your friend. 

Something i've done is to use the transparent illusionary trick above and to use a non-liquid version of the liquid texture (ie without the *) and stretched to maybe 4x4 scale.
If your liquid is placed below the illusionary by 1 pixel, you can set the illusionary to have alpha about 0.5 and water to be about 0.3~ i think and this makes the water look like it has a lightmap on it.
doesn't work with all kinds of waters, but most of the stock water textures look fine. 

Maybe I haven't been paying attention. I can set the alpha of a func_illusionary and water in a Quake map? This is a plain old bsp file type map running in Fitzquake. 

Almost all engines today support alpha transparency on water, it was introduced with glquake, the official 3d accelerated engine, and so any engine not based on software quake has it. The support is limited though: critically it's controlled by a cvar, not directly in the map, so you need some kind of mod to ensure that the value is set to transparent. Otherwise you're relying on the user to set it correctly for your map.

Most source ports of quake support the addition of the alpha field for entities, making them appear transparent. It's one of the few extended features to be implemented consistently across so many engines that it can almost be treated as standard (skyboxes would be another, fog almost so). In engines that don't support alpha, the entity renders fully opaque instead.

Fitzquake supports both of these features, so it would work fine in that engine(minus the proviso about needing to set the cvar). I'd recommend a slight tweak to the setup necros suggests to provide better fallbacks in less functional engines. If you put the func_illusionary slightly below the waterline then:

* In software quake you get opaque water that's not lightmapped but animates (which is probably better than lightmapped-but-not-animated water). No worse than usual.

* In engines without "alpha" key support, you get animated, lightmapped water which is opaque - an interesting trade-off you'd probably opt for if this lightmap idea is important to your map.

* In engines with both you'd get the full effect. 

I was aware of r_wateralpha.

The support is limited though: critically it's controlled by a cvar, not directly in the map, so you need some kind of mod to ensure that the value is set to transparent. Otherwise you're relying on the user to set it correctly for your map.

That's what I was thinking which is why I asked about setting it in the map.


Most source ports of quake support the addition of the alpha field for entities, making them appear transparent.

That's something I didn't know. I'd seen this effect , but I guess I just figured it was done with custom code, though now that I think about it, I remember at least one map where it was used that was just a normal bsp.

Thanks guys, for all the info and ideas.

Most of the too bright water in my map was fixed by using a super dark water texture. There are a couple of places where pitch black walls are adjacent to lit water that don't look so good, but I can probably live with it.

I tend to spend days fixing trying to fix small things like this, that most people will never notice. If I keep doing this, the map will never be done. 

But if I notice even one instance where I know the author took time to get a tiny detail right, I enjoy the map that much more. 

trying to fix small things like this, that most people will never notice.

but they will notice if it's not fixed. :P 

The details are everything.

If there's one misaligned texture, people will think you're sloppy. If there's one overlapping-brush-2-brush-flicker, they'll think less of the map as it ruins the Sustainment of Disbelief.

Even the smallest detail (to chamfer or not to chamfer) can make a big difference in the overall fluidity and coherence of that area.

The details are everything. 

It's easy to get obsessive and waste a lot of time getting everything perfect.

A good release stands on its own, warts and all. 

It's easy to get obsessive and waste a lot of time getting everything perfect.

I'm trying for not too many warts.
It's getting closer. 

Do I just put the brushes in an empty map, run bsp and light and then place it in a different map using info_notnull or something like that? 

Do I just put the brushes in an empty map, run bsp and light and then place it in a different map

yes, be sure to place the bsp in your progs folder.

using info_notnull or something like that?

i use the Quoth mapobject_custom entity, has mangle and such.

At least thats what i do, not sure if vanilla progs handles this so easy..