Fully Automatic Transparent Water

[Baker]

[Baker]

[mh]

[Baker]

Looks like that could trim down the implementation quite a bit. I don't like how my check spans over a few different functions.

[mh]

[Baker]

[mh]

[Cobalt]

While you guys are talking about water, what are your thoughts about an "underwater sound" system?

I have messed with it a little via ssqc, but probbaly much well working engine side I suppose.

Boils down to :

1) Declaring what ents can make underwater sounds IE: Player, missile, some doors / secret doors (e2m1 for ex)
2) Findradius to locate clients within a paramater near the sound (I selected about 1000 quake units as a start) and are waterlevel > 2.
NOTE: Trick with No. 2 is determining if they are in the same "body" of water as the ent making the sound.
3) Pitching the sound / selecting proper sounds for the event. Also the normal Quake Attenutaion scales seem to be ok in my tests, but real sound physics for underwater are different - sounds seem to travel at a linear fixed attenuation no matter the distance to the event.

4) Related to No. 3 , the issue attenuation has now is it does not take account for passing through water , so the attenuation level basicly is the same as if it occured out of water or in it.


In my crude tests, I also was able to scale the attenuation_exponent cvar (client side) in the engine so the deeper in water the client is, the lower they get as water depth increases. Apparently this cvar does not effect ambient sounds, but the method has its drawbacks such as on a map like e1m4 where there are pockets the client can resurface into, and sounds in that area most likely would not be heard at all unless present in that same pocket.

As a possible solution I thought of spawning large trigger fields over the water brushes that match their dimensions, but it seems to boil down to stuff engine side in the end that may be done alot better by someone with the skills, so thought I would mention it.

[r00k]

[Baker]

[metlslime]

explanation of "nearwaterportal"

This part is from glquake:

if camera is close to a waterplane, something called "FatPVS" is used to combine the PVS from a cube of 8 sample points. This is to compensate for the water plane being clipped by the near clipping plane in openGL (resulting in a view that includes both sides of the water surface.) With regular PVS you've have HOM on part of the screen. With software rendered the water surface isn't clipped (and the camera is always 1/16th a unit off grid to prevent it being coplanar with the water.)

This part was added in fitzquake:

I cache the PVS whenever possible, for example as long as you stay in the same leaf. The problem is, that with FatPVS, the vis data could change even while you stay in the leaf. So i disable caching if "nearwaterportal" is true.

[mankrip]

[mh]

[mankrip]

Sure, but maps that already exists should still be supported.