[Engine Standard] Water Alpha

[mh]

Here we go again...

Right now there are two ways of setting water alpha: either via the r_wateralpha cvar or by including water surfs in a brush model entity with .alpha set on it. It makes sense that if .alpha is set on an entity it overrides the value of r_wateralpha, but here's one that's come up during the course of RMQ discussion.

What about adding another worldspawn key/value pair allowing the mapper to set a global override for r_wateralpha? This wouldn't affect older maps as they wouldn't have it, but any new maps could specify it if the mapper wanted. The advantages are that the mapper can be certain that the map is run as intended, and the player could get translucent water on maps that support it without needing to be constantly changing the value of r_wateralpha.

The only disadvantage I can see is that it would break the r_novis/r_wateralpha combination, but I'm not certain if breaking that is worth losing sleep over.

And another question that springs to mind here: what about lava, slime and teleports? Should they be handled this way too?

[leileilol]

How does Hexen II do it?

[mh]

Hard-coded texture names in the engine. Surfs with textures beginning with *rtex078 or *lowlight get r_wateralpha, the rest don't.

I would hope nobody suggests taking that up as a standard...

[dreadlorde]

Lava is not transparent. Slime and teleporters could be transparent, depends on the mapper.

[Baker]

Lava, slime and teleporters ideally shouldn't be transparent. But, well, they are!

r_wateralpha shouldn't ideally have settings. It should be on or off. And something like the automatic water transparency code should be used to detect if it exists. Then again, it does have settings.

I personally don't think r_shadows should have settings, either they are on or they are off. And some particular setting should be "the one".

I guess what I am saying is that Quake is going to be Quake, but a mod or total conversion can make whatever rules it wants.

Adding to the mix: fog in deathmatch maps = no ... unless you are going to do it in software too, otherwise you are putting GL users at an unfair disadvantage. That being said, everyone is probably going to turn fog off --- plus bots do not see fog.

Complicated post, yes? Valid concerns? yes. Kurok doesn't use alpha entities but rather Tomaz alpha textures. Which are superior --- just try to make a door that is glass with a solid metal non-alpha texture for the metal parts of the door = you can't = alpha is all or nothing, either the entity is alpha'd or not. But using Tomaz alpha textures, you can.

A big tangled ball of a mess.

Part of my message above: unless the map compiler is enforcing that lava is not transparent, an engine that takes advantage of the compiler making it transparent isn't guilty of a crime. This can matter in multiplayer.

[leileilol]

Hard-coded texture names in the engine. Surfs with textures beginning with *rtex078 or *lowlight get r_wateralpha, the rest don't.

Thanks!

[mh]

unless the map compiler is enforcing that lava is not transparent, an engine that takes advantage of the compiler making it transparent isn't guilty of a crime. This can matter in multiplayer.

Yeah, that would be my thinking too. The thought of multiplayer and cheating or advantages/disadvantages did cross my mind, but I don't really want to get into the realm of client-side cheat protection, which I believe to be utterly bogus (the same applies to maps, btw - the determined cheater could just recompile a map to remove "inconvenient" walls, and add translucent textures everywhere - but that's all an aside).

Part of the problem here is that Quake offloads a lot (too much?) of decision making to the player. In one way that's cool, but in another it's not as (a) players need to know that an option exists before they can even use that option (c'mon, hands up who knows what all the r_really_long_cvar_name_in_darkplaces cvars in DarkPlaces do? Thought not), and (b) players may select a bunch of options that don't work well (or don't work at all) with a given map or mod.

The objective here is to propose a way to put some of that control back into the hands of content makers. If a mapper says "I want you to run my map with r_wateralpha 0.666" then you should probably run that map with r_wateralpha 0.666, but should you have to explicitly set it or should it automatically happen for you.

Note that I'm accepting for now that current maps are beyond redemption; done is done, we're talking about the future here. Mistakes were made in the past, sure, so let's accept that they're there, accomodate them as painlessly as possible, but build something more solid for moving forward with.

[Spike]

r_wateralpha should be the level of transparency for such transparent surfaces. You shouldn't be overriding that value at any point (other than maybe forcing it to 1 to prevent cheating when sw renderers may be involved).
There really is no choice but to choose transparency based upon name, but there's no reason that the names must be hardcoded.
Someone make a matcher that matches *lava04 to #lava* in order to make all lava textures opaque. Make it the standard that textures matching those names present in a cvar/worldspawn key/watervis checks are opaque. Leave r_wateralpha itself alone.
Then you can do r_wateropaque "#lava* #teleport* #slime*"
and then those textures are opaque.

Why must the mod be required to set all of these different settings?


Or just detect watervis on a per-texture basis, and just use that.

[mankrip]

There are mods that sets the r_wateralpha cvar based on the value of a "wateralpha" or "r_wateralpha" field in the worldspawn entity.

IIRC, I've added engine-side support for this in Makaqu, so it will work for any maps that contains either of these fields, even if the progs.dat doesn't support them.

Also, I've made it to read these fields as strings, to make sure that a value of zero is possible, since "0" != "". If the string is null, the cvar is left unchanged.

IIRC, I've also added the same kind of support for setting sv_gravity.

Now, some fun facts. Usually, "water alpha" is simply weighted-mean color blending, but there are a lot of different color blending algorithms out there. In Makaqu, I've just implemented a more dynamic algorithm that reduces the loss of color fidelity when compared to the weighted-mean alphamap.lmp included in its latest releases, by dinamically calculating the weight of the alpha blending for each color combination, based on the tone of each color. So, no single alpha blending for the whole surface here.

Things like these makes me have the opinion that alpha blending should be defined first by its mode (which is given by the algorithm) and then by its intensity (which in some cases may be scaled by the r_wateralpha cvar, or by something else, such as entity fields). And then, there's also thickness-based alpha blending, which could (and probably should) replace r_wateralpha in engines that supports it.

Lava should definitely be opaque.

Slime in Quake is actually an undefined kind of toxic waste, which, specially in custom maps, may be meant to be either opaque or translucent. However, it's somewhat safe to agree that it's more dense than water, and therefore should be at least less translucent than it.

Quake's default portals shouldn't be translucent, but there are a number of custom maps that uses different textures for their portals. Anyway, making all of them opaque is a safer bet, since some custom maps doesn't have any geometry behind their portal surfaces.

[r00k]

For me water transparency is set with a minimum of r_wateralpha, then based on the distance of the pov to water surface determines the opaqueness.
Same with shadows, further away the less pronounced they get. But this is just my independent standpoint. r_wateralpha should only affect SURF_DRAWTURB, if someone wants to make an entity that looks like water then let .alpha determine it's level of transparency.

[mankrip]

based on the distance of the pov to water surface determines the opaqueness.

To me, this is depth-based. Thickness should be based on the distance from the translucent surface to the surface behind it.

[Sajt]

The fresnel effect for water is well-defined, but it requires a fragment shader. There are probably a thousand tutorials about it. The opacity is based on the angle you are looking at a point on the water's surface. Anyway..

[goldenboy]

The mapper HAS a way of making damn sure something is not transparent:

create a bmodel with *water textures and set alpha=1.

Honestly, I think the worldspawn thing is overkill. I personally wouldn't use it (I use trigger_command or info_command, which are available both in Quoth and in RMQ and are a lot more flexible).

Also, the player can easily change fog and sky, for example. More worldspawn keys to disallow that as well? What if the player removes the skybox or the engine doesn't support fog?

r_wateralpha should have settings, because players may prefer more or less transparent water. I don't see why this control has to be transferred to the mapper.

The engine or the map compiler should NOT control how lava etc. are rendered - it should be up to the mapper. If I want transparent teleporters, I should be allowed to have them.

I don't know, man. I just don't see how this is needed at all.

Let both mappers and players have their freedom, it doesn't bug me in the slightest if the player wants to use their own wateralpha, fog or skybox settings.

EDIT: How about keeping players from running my map with realtime world lighting or certain replacement textures (_RYGEL_NO = 1)?

[mankrip]

I think this discussion is not about forcing (the lack of) certain features on anyone, but about establishing sane defaults for those certain features.

[edit] Yeah, there's the multiplayer cheating aspect of it...

[Spike]

QuakeWorld has a serverinfo key which acts as a wateralpha cap. By default (missing) it means fully opaque. As a result, noone uses wateralpha, because they can't. At least its fair for the software users, but I don't know of anyone that still uses sw rendering.
Something that bypasses that default would be nice to QuakeWorld players, at least.