_wateralpha and other worldspawn keys proposal

[ericw]

[Baker]

Ah, I knew this day would come.

And I'm not sure what to say.

This kind of discussion came up a couple of years ago and the main thought is that it could lead to infinite worldspawn keys.

[When possibly the real problem is that engines can't detect if the map are vised for transparent water or not.]

I'm not really sure what to think, the problem is real. Doesn't fix this for any of the thousands of existing maps

[leileilol]

All 3 are also possible to implement in Engoo (software renderer engine). I would have to change the water drawing code to point to different calculated translation tables (generated on map load) depending on content. Skyfog is even doable very easily by applying a color blend to the sky texture itself on load without any additional rendering code.

[Spike]

> If the player changes the “r_wateralpha” cvar while the map is running, the engine should switch to using that value until the map is reloaded. This allows for interactive tweaking by a mapper, or lets the player override the value if they don't like the mapper's choice.

the way you implemented that makes me uneasy.
it depends upon other engines having callbacks for when a cvar was modified. it seems clumsy.
its also lots of extra functions. I don't like lots of extra functions, even if they're just one line long. seems messy.

> specifying 0 for the _lavaalpha/_telealpha/_slimealpha worldspawn keys doesn't actually cause the alpha to be set to 0 for those textures, but means "fall back to the wateralpha value".

this is dangerous. use -1 to flag it as unspecified if needed. you may even want to avoid using a float to flag it active/inactive. a bitfield instead or something.


one question: what about 'pretty water' stuff, with a global enable that enables both reflection and refraction (the warpy transparenty view). in this case you don't want to be drawing some ugly water surface over the top, ruining the effect.
which feature wins? :s


needs a test-case, because I'm too lazy to make maps myself.



@baker
.ent files.
detecting watervis won't help you if the water is meant to be 20% visible on one map and 60% on annother, nor if the use has the cvar set to 1 because vanilla water was never meant to be transparent (and they can't be arsed to delete their vis patches).
of course, you can't have one brush with one translucency and another with a different setting with this, unless of course if you make one slime and another a teleporter, but that just gets really messy.
but you know someone is going to do it anyway... :s

[Baker]

[mankrip]

[leileilol]

It would suck if you die in a level, reload, and see the water get opaque and the fog disappear


Also I believe _keys should override the cvar when available, and not actually change the cvar itself.

[qbism]

Per texture in a vanilla-compatible texture name... Somehow...
*water-hey-I-am-35-percent
*water-some-other-muddy-water-yo-70-percent

[leileilol]

or you could shoehorn in a hexadecimal at the end followed by some symbol.

[ericw]

[ericw]

[ericw]

[Baker]

[mankrip]

[qbism]

per-texture exceptions in worldspawn-
wateralpha 0.33
slimealpha 0.50
lavaalpha 1.00
texalpha *watermud 0.66