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

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

you can use progs/map.bsp or maps/map.bsp and both will work for the model path. only sounds are hardcoded to be in sound/xxxxx 

in fact, it's generally good practice to put any external bsps in a subfolder so you can keep things clean. unless you want to use a pak file in which case it matters less. 

Okay, thanks. Now, how do I place the external bsp into my map? 

how is the newest remake going? 

Trying to open some .map files saved with WC in Radiant but keep getting.

parse error at '[': expected '#number'

The maps are also BSP2 sized.
GB, you have experience with this? 

WC uses a different .map format from Radiant.

I don't know if WC has other limits that could possibly be BSP2 related; the only thing I think I have heard is that it can't properly display maps that are bigger than 8192x8192.

There is a converter program by a person called Scrama, I believe, you might have some luck using the quakeone.com forum search. It is somewhat obscure though. You will also have to convert the texture wads between WC and Radiant. :-s

If it only needs to be done once, using some converter is acceptable, but daily WC <-> Radiant conversion in any halfway productive environment, eg in a team setting, isn't very good for the workflow. I have lovely memories of this problem from RMQ.