[Engine Standard] Water Alpha

[mh]

[leileilol]

[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]

[mh]

[Spike]

[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 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]

[Sajt]

[goldenboy]

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